ACC Documento tesis - CENIDET · 2020. 7. 7. · facilitado el manejo y procesamiento de...

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

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.

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.

i

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 ........................................................................................... 3

1.1 Antecedentes .......................................................................................................... 3

1.2 Planteamiento del problema.................................................................................... 4

1.3 Objetivo.................................................................................................................. 5

1.4 Justificación y beneficios ........................................................................................ 5

1.6. Alcances y limitaciones.......................................................................................... 6

1.7. Metodología de solución......................................................................................... 7

Capítulo 2. Marco teórico........................................................................................... 9

2.1 Proceso de negocio.................................................................................................. 9

2.2 Workflow ...............................................................................................................10

2.3 Sistema de workflow..............................................................................................10

2.3.1 Modelo de referencia ....................................................................................10

2.3.1.1 Herramienta de definición de procesos...................................................11

2.3.1.2 Motor de workflow.................................................................................11

2.3.1.3 Servicio de representación de workflow..................................................11

2.3.1.4 Interfaz de programación de aplicaciones de workflow (WAPI) ................11

2.4 Lenguaje de Definición de Procesos XML (XPDL) ...................................................11

2.5 Sistema de Información Geográfica (GIS)................................................................12

2.6 Servidor de Mapas .................................................................................................13

2.6.1 Funcionalidad de los servidores de mapas....................................................13

2.7 GeoServer..............................................................................................................14

2.7.1 Estándares OGC soportados por GeoServer..................................................14

2.8 OpenLayers ...........................................................................................................16

2.9 API JDOM .............................................................................................................16

Capítulo 3. Estado del arte........................................................................................18

3.1 Sistemas comerciales.............................................................................................19

3.2 Sistemas de código abierto.....................................................................................20

3.3 Análisis comparativo..............................................................................................22

Capítulo 4. Análisis del problema y solución propuesta ..........................................25

4.1 Funcionamiento general del sistema ......................................................................26

4.2 Ingeniería inversa del sistema Bonita .....................................................................26

4.2.1 Motor de workflow .......................................................................................26

4.2.2 Consola de administración de procesos jiapAdmin........................................29

4.2.3 Editor de procesos de negocio ProEd ............................................................31

4.2.3.1 Editor de formularios xformeditor...........................................................34

ii

4.2.3.2 Notación para atributos ........................................................................ 35

4.3 Modelo de solución ............................................................................................... 36

Capítulo 5. Diseño e implementación del sistema .................................................. 39

5.1 Diseño de las modificaciones para el editor ProEd ................................................. 40

5.1.1 Casos de uso del editor ProEd ..................................................................... 40

5.2 Implementación de modificaciones sobre ProEd..................................................... 45

5.3 Cuantificación de las modificaciones de ProEd ...................................................... 54

5.4 Diseño de las modificaciones para xformeditor....................................................... 55

5.4.1 Casos de uso del editor de formularios xformeditor ...................................... 55

5.5 Implementación de modificaciones sobre xformeditor............................................. 58

5.6 Cuantificación de las modificaciones de xformeditor .............................................. 63

5.7 Diseño de las modificaciones para la consola jiapAdmin ........................................ 63

5.8 Implementación de las modificaciones sobre la consola jiapAdmin......................... 64

Capítulo 6. Pruebas................................................................................................... 65

6.1 Hipótesis .............................................................................................................. 66

6.2 Convención de nombres........................................................................................ 66

6.3 Plan de pruebas.................................................................................................... 66

6.4 Casos de pruebas ................................................................................................. 71

6.5 Resultados de pruebas.......................................................................................... 73

6.6 Análisis de los resultados...................................................................................... 91

Capítulo 7. Conclusiones .......................................................................................... 93

7.1 Conclusiones ........................................................................................................ 94

7.2 Aportaciones......................................................................................................... 95

7.3 Trabajos futuros ................................................................................................... 95

7.4 Publicaciones y reconocimientos ........................................................................... 96

Anexo A. Diagramas de clases del editor ProEd....................................................... 97

Anexo B. Escenarios de los casos de uso del editor ProEd y xformeditor ............ 101

Anexo C. Descripción de los casos de prueba ........................................................ 114

Referencias............................................................................................................... 123

iii

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

iv

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.................................................................... 82

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 ................................................................. 85

Figura 6.22 Visor de mapas con zoom out aplicado............................................................... 1

Figura 6.26 Capa de lagos activada .................................................................................... 86

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 ........................................................................... 87

Figura 6.28 Almacenamiento de punto de interés ............................................................... 88

Figura 6.29 Recuperación de punto de interés.................................................................... 88

Figura 6.30 Código del proceso existente............................................................................ 89

Figura 6.31 Selección de archivo XPDL a abrir ................................................................... 90

Figura 6.32 Reconocimiento del atributo Map Viewer ......................................................... 90

Figura 6.33 Propiedades del atributo Map Viewer reconocido ............................................. 91

Lista de tablas

Tabla 1.1 Comparativa de trabajos relacionados comerciales.............................................. 23

Tabla 1.2 Comparativa de trabajos relacionados de código abierto...................................... 24

Tabla 5.2 Métodos de la inner clase CheckBoxItem.............................................................. 47

Tabla 5.3 Métodos de la clase CheckBoxRenderer ............................................................... 47

Tabla 5.4 Métodos creados en la clase Buttons ................................................................... 48

Tabla 5.5 Métodos modificados de la clase ValidateDatafield .............................................. 49

Tabla 5.6 Métodos creados de la clase ConnectionMapServer .............................................. 50

Tabla 5.7 Métodos modificados de la clase XformProperty ................................................... 50

Tabla 5.8 Métodos modificados de la clase XPDLDatafield .................................................. 51

Tabla 5.9 Métodos modificados de la clase Application........................................................ 58

Tabla 5.10 Métodos agregados a la clase XComponent ........................................................ 59

Tabla 5.11 Métodos de la clase XTr..................................................................................... 61

Tabla 5.12 Métodos modificados de la clase UserTreeBuilder .............................................. 64

Tabla 6.1 Descripción de las tareas de prueba.................................................................... 69

Tabla 6.2 Herramientas de hardware.................................................................................. 70

Tabla 6.3 Herramientas de software. .................................................................................. 70

Tabla 6.4 Resultados del caso de prueba GEOPROED-01-01.............................................. 73






Tabla 6.10 Resultados del caso de prueba GEOPROED-02-02............................................ 80

Tabla 6.11 Resultados del caso de prueba GEOPROED-03 ................................................. 82







v

Tabla 6.18 Resultados del caso de prueba GEOPROED-05-02 ............................................88

Tabla 6.19 Resultados del caso de prueba GEOPROED-06..................................................89

vi

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 (Business Process Modeling Notation) Es un estándar que

proporciona una notación gráfica para representar procesos de negocio.

BPEL (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.

BSD (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.

CORBA (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.

Dato espacial 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.

EJB (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.

vii

ESRI (Environmental Systems Research Institute) Es una empresa dedicada al desarrollo y comercialización de Sistemas de Información Geográfica.

GIS (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 (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.

HSQLDB (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.

JAAS (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.

JDBC (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.

JDOM (Java Document Object Model) API para leer, crear y manipular

documentos XML en Java. JMS (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.

JOnAS (Java Open Application Server) Es un servidor de aplicaciones

J2EE de código abierto implementado en Java. J2EE (Java 2 Enterprise Edition) Define un estándar para el desarrollo

de aplicaciones empresariales multicapa diseñado por Sun Microsystems.

viii

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 (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.

POI (Points Of Interest) Un Punto de Interés es una ubicación sobre

un mapa donde se encuentra un elemento de especial relevancia.

SLD (Styled Layer Descriptor) Es un lenguaje estándar propuesto por

el OGC para describir el conjunto de capas dentro de un GIS. URL (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.

WCS (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.

WfMC (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.

WFS (Web Feature Service) Especificación que define un protocolo de

intercambio de información vectorial. WMS (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.

XHTML (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

ix

Web Consortium de lograr una Web semántica, donde la información y la forma de presentarla estén claramente separadas.

XML (eXtensible Markup Language) El Lenguaje de Marcado

eXtensible es un metalenguaje de etiquetas desarrollado por el World Wide Web Consortium (W3C).

XPDL (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.

Introducción

1

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.

Introducción

2

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.

Capítulo 1. Antecedentes

3

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.


4

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


5

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.


6

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.

1.6. 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:


7

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.

1.7. 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.


8

• 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 829-1998 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

Implementación modificaciones

Pruebas Diseño de

modificaciones

Figura 1.1 Metodología de solución

Capitulo 2. Marco teórico

9

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].

Capítulo 2. Marco teórico

10

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.

2.3.1 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:


11

2.3.1.1 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]. 2.3.1.2 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]. 2.3.1.3 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. 2.3.1.4 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]


12

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.


13

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.

2.6.1 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.


14

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].

2.7.1 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.


15

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].


16

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,


17

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.

Capítulo 3. Estado del arte

18

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.


19

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


20

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,


21

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


22

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.


23

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

form

ularios

Lenguaje

definición

procesos

Inform

ació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.


24

Tabla 3.2 Comparativa de trabajos relacionados de código abierto

Sistema

Cliente web

Modelado

Web

Editor

form

ularios

Lenguaje

definición

procesos

Inform

ació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

Capítulo 4. Análisis del problema y solución propuesta

25

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.


26

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

4.2.1 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.


27

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 EJBs1:

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.


28

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.


29

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.

4.2.2 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 struts2, 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.


30

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 strust-config.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).


31

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).

4.2.3 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.


32

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.

El diagrama de clases de este paquete se encuentra en el anexo A de esta

tesis. 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.

El diagrama de clases de este paquete se encuentra en el anexo A de esta

tesis.


33

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).


34

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.

4.2.3.1 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.


35

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

4.2.3.2 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:


36

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.


37

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


38

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.

Capítulo 5. Diseño e implementación del sistema

39


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.


40

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 editados3 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.

5.1.1 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.


41

Diseñador

CU_1. Crear proceso

CU_4. Definir atributos

CU_2. Modificar proceso

CU_3 Definir actividades

CU_5. Modificar actividades

CU_6. Modificar atributos

<<include>>

<<include>>

<<extend>>

<<extend>>

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_4. Definir atributos

CU_7. Definir atributo cadena

CU_8. Definir atributos decisión

CU_9. Definir atributo espacial

<<extend>>

<<extend>>

<<extend>>

CU_10. Editar formulario

<<include>>

Figura 5.2 Diagrama de casos de uso de CU_4 definir atributos


42

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.

CU_9. Definir atributo espacial CU_11. Procesar catálogo del servidor de mapas

<<include>>

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.


43

Definir atributo espacial

Definir dirección servidor de mapas

Seleccionar mapas

Seleccionar mapa base

Editar formulario

Guardar cambios

Realizar cambios

Mostrar panel de propiedades

Conectarse al servidor de mapas

Obtener catálogo

Procesar catálogo

Desplegar lista de mapas disponibles

Crear atributo

Invocar xformeditor

Desplegar editor de formulario

Guardar formulario

xformeditorProEdDiseñador

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.


44

: DiseñadorProEd xformeditor

1: Define atributo

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

22: Guarda proceso

23: Almacena proceso en formato XPDL

24: Despliega mensaje de proceso

guardado

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

Figura 5.5 Diagrama de secuencia de creación de un atributo espacial


45

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 SVN4, las instrucciones y ligas para realizar la conexión y descarga se encuentran en la siguiente liga: http://forge.objectweb.org/ 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.


46

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 Crea el panel a utilizar para definir las características del atributo Map Viewer.

Agregado

getMapServer Obtiene la dirección del servidor de mapas introducida en el panel.

Agregado

setMapServer Fija el valor de la dirección del servidor de mapas, en el panel Map Viewer.

Agregado

unpackLayersProperties Empaqueta las propiedades de cada mapa seleccionado.

Agregado

topackLayersProperties Desempaqueta las propiedades de los mapas seleccionados.

Agregado

buildCheckBoxItems Crea una lista de checkboxes para asociar al catálogo de mapas disponibles en el servidor de mapas.

Agregado

createPanelGeneral

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.

Modificado

getType Obtiene el tipo de dato del atributo a crear. Se incorporaron acciones para reconocer el atributo Map Viewer.

Modificado

checkFields

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.

Modificado

setType

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.

Modificado

setData

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.

Modificado


47

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 Descripción

CheckBoxItem Fija el valor de la variable isChecked a falso.

isChecked Retorna el valor de la variable isChecked

setChecked 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


CheckBoxRenderer Constructor que configura los colores para la lista de las casillas de verificación

getListCellRendererComponent Retorna el elemento de la lista que ha sido seleccionado

El diagrama de la clase DatafieldDialog se aprecia en la figura (5.6).


48

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


createButtonConnect Crea el botón Connect utilizado en la ventana de definición del atributo Map Viewer.

createButtonSaveLayers Crea el botón SaveLayers utilizado en la ventana de definición del atributo Map Viewer.


49

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


actionPerformed 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


50

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


connection Recibe la URL del servidor de mapas y termina de construir la petición para obtener el catálogo de mapas.

obtainLayers 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).

arrange 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


XFormProperty Este constructor fue modificado para considerar como un atributo al tipo Map Viewer dentro del archivo XPDL.


51

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.

Los métodos modificados a la clase XPDLDatafield se describen en la tabla

(5.8). Tabla 5.8 Métodos modificados de la clase XPDLDatafield


XPDLDatafield Este constructor fue modificado, de forma que el tipo de dato Map Viewer sea reconocido y almacenado dentro de la estructura del árbol.

toModel

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.


52

Elemento DataFields

Elemento DataField

Elemento DataField

Elemento DataField

Elemento DataField

Atributo Id

Atributo Id

Atributo Id Atributo

Id

Atributo Name

Atributo Nombre

Atributo Nombre Atributo

Nombre

Elemento DataType

Elemento BasicType

Atributo Type

Elemento DataType

Elemento EnumerationType

Atributo Name

Elemento EnumerationValue

Elemento InitialValue

Elemento DataType

Elemento EnumerationType

Atributo Name

Elemento EnumerationValue


Elemento ExtendedAttributes

Elemento ExtendedAttribute

Atributo Name

Elemento DataType

Elemento MapType

Atributo Name

Elemento MapValue


Figura 5.11 Árbol XML de los atributos


53

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.


54

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 (LOC5) [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

(a) (b)

(c)

(d) (e)

( f ) (g)

(h)

(i)


55

Los valores de los indicadores para el editor de procesos ProEd se presentan a continuación: LOC (B): 49185 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 = 487 + 1 = 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 = 49185 - 0 + 488 + 0 = 49673 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.

5.4.1 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.


56

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.

CU_10. Editar formulario

CU_12. Generar código del visor de mapas

CU_13. Guardar formulario

<<include>>

<<include>>

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).

Editar formuario

Realizar cambios

Guardar cambios

Mandar atributos

Generar script visor de mapas

Crear elementos HTML

Desplegar editor

Guardar formulario en motor de workflow

xformeditorProEdDiseñador

Figura 5.15 Diagrama de actividades de xformeditor


57

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ñadorProEd xformeditor

1: Selecciona editar formulario

2: Envía atributos

4: Genera código formulario

6: Despliega formulario

8: Selecciona guardar

7: Reubica atributos

9: Establece conexión con el

motor de workflow

10: Guarda formulario

11: Despliega mensaje de formulario almacenado

3: Genera código del script

del visor de mapas

5: Agrega elementos HTML

dentro de un árbol XML

Figura 5.16 Diagrama de secuencias de xformeditor


58

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


createDocuments

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.

Modificado

createScript

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.

Agregado

createStyle Crea el contenido del tag de estilo HTML <style>, el cual define las reglas de estilo a utilizar por el visor de mapas

Agregado

tokenize Separa los atributos de los mapas: nombre, sistema de referencia espacial (SRS) y BoundingBox (MinX, MinY, MaxX, MaxY).

Agregado


59

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


getCaptionMapViewer Obtiene el valor del título del componente, es decir, su nombre.


60

El diagrama de la clase XComponent se muestra en la siguiente figura (ver fig. 5.18)

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.


61

Tabla 5.11 Métodos de la clase XTr


XTr() Constructor por defecto, requerido por la clase XComponent, el cual crea una instancia.

XTr(String label) Constructor que define una instancia, con un elemento label.

configure() 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.


62

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

Atributo Map Viewer

(a)


63

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 = 301 + 0 = 488

LOC Total = 9554 - 0 + 301 + 10 = 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.


64

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


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

Capítulo 6. Pruebas

65

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 829-1998 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.


66

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 829-1998 [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,


67

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.


68

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-01-01 Definición del atributo Map Viewer GEOPROED-01-02 Procesamiento del catálogo de mapas. GEOPROED-01-03 Modificación del atributo Map Viewer GEOPROED-01-04 Eliminación del atributo Map Viewer GEOPROED-01-05 Propagación del atributo Map Viewer

GEOPROED-02 Generación de formulario

GEOPROED-02-01 Generación del código para el atributo Map Viewer GEOPROED-02-02 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-04-01 Realizar zoom in sobre el mapa GEOPROED-04-02 Realizar zoom out sobre mapa GEOPROED-04-03 Paneo sobre el mapa GEOPROED-04-04 Manipulación de capas GEOPROED-04-05 Inserción de puntos de interés (POIs) GEOPROED-05 Almacén de puntos de interés (POIs)

GEOPROED-05-01 Inserción de puntos de interés GEOPROED-05-02 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.


69

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

Tarea 3

Conocimiento de: • Lenguaje de programación Java.

• Ambiente de desarrollo integrado.

• Servidores de mapas. • Uso de la biblioteca OpenLayers.

Autora de tesis

5. Evaluación de resultados

Tarea 2 y 3

Conocimiento del objetivo, alcances, limitaciones e hipótesis de prueba de la investigación de esta tesis.

Autora de tesis


70

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 Características

PC de escritorio (Servidor)

• Procesador Pentium 4 Core Duo • 1 GB de memoria en RAM • 150 GB de capacidad en disco duro • Tarjeta de red Ethernet 10/100Mbps

PC de escritorio o laptop (Cliente)

• 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 Descripción

PC de escritorio (Servidor)

• Sistema Operativo Suse 10.2 / Windows XP • Java 2 Standard Edition Development Kit (J2SE) 1.5.0.13 • Servidor de aplicaciones JOnAS 4.8.5 con apache Ant. • Sistema de workflow Bonita v 3.0 • Navegador Web Mozilla 2.0 o superior • Servidor de mapas GeoServer • Biblioteca OpenLayers

PC de escritorio o laptop (cliente)

• Java 2 Standard Edition Development Kit (J2SE) 1.5.0.13 • 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.


71

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-01-01 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-01-02 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-01-03 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-01-04 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-01-05 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-02-01 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.


72

GEOPROED-02-02 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-04-01 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-04-02 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-04-03 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-04-04 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-04-05 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-05-01 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-05-02 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.


73

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-01-01

Caso de prueba: GEOPROED-01-01 Definición del atributo Map Viewer

Resultado: OK

Se definió un atributo del tipo Map Viewer llamado Ubicacion_solicitud (ver fig. 6.1).

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 http://192.168.0.11:8080

Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora

Figura 6.2 Pestaña de atributos Figura 6.1 Definición de atributo Map Viewer


74

Tabla 6.5 Resultados del caso de prueba GEOPROED-01-02

Caso de prueba: GEOPROED-01-02 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). 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



Caso de prueba: GEOPROED-01-03 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).

Figura 6.3 Especificación del servidor de mapas

Figura 6.4 Despliegue de catálogo procesado


75

El editor guardó los nuevos valores establecidos, lo cual se aprecia en la figura (6.7).

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-01-01


Figura 6.6 Modificación del atributo Map Viewer

Figura 6.7 Atributo modificado

Figura 6.5 Pestaña de atributos del proceso


76


Caso de prueba: GEOPROED-01-04 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).

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.8 Mensaje de advertencia al eliminar atributo

Figura 6.9 Mensaje de confirmación para eliminar atributo


77

El atributo fue eliminado como se aprecia en la figura (6.10).

Observaciones:

El atributo eliminado corresponde al creado en el caso de prueba GEOPROED-01-01 y modificado en la prueba GEOPROED-01-03



Caso de prueba: GEOPROED-01-05 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).

Figura 6.10 Atributo eliminado


78

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:

El atributo corresponde al creado en el caso de prueba GEOPROED-01-01 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


Figura 6.12 Formulario con atributos inherentes


79


Caso de prueba: GEOPROED-02-01 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). 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.13 Mensaje de sincronización

Figura 6.14 Formulario a guardar


80

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-01-01. 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.



Caso de prueba: GEOPROED-02-02 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).


81

Por último el atributo fue movido al final del formulario como se muestra en la figura (6.18).

Observaciones:

El formulario presentado es el creado a nivel de proceso en el caso de prueba GEOPROED-01-01

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.


Figura 6.16 Posición original del atributo

Figura 6.17 Atributo desplazado

Figura 6.18 Atributo cambiado de posición


82

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.



Caso de prueba: GEOPROED-04-01 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.


83

Al aplicarse el zoom in (acercamiento) el mapa fue visualizado a mayor escala, lo cual correspondió al resultado esperado (ver fig. 6.21).

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


Figura 6.20 Escala por defecto del visor de mapas

Figura 6.21 Visor de mapas con zoom in


84


Caso de prueba: GEOPROED-04-02 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).

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-04-03

Caso de prueba: GEOPROED-04-03 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.

Figura 6.22 Visor de mapas con zoom out aplicado


85

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.



Caso de prueba: GEOPROED-04-04 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


86

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. 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.


Figura 6.25 Vista de la capa carreteras


87


Caso de prueba: GEOPROED-04-05 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.



Caso de prueba: GEOPROED-05-01 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.


88

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.



Caso de prueba: GEOPROED-05-02 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


89

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.


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.


90

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-01-03.


91

Figura 6.33 Propiedades del atributo Map Viewer reconocido

Observaciones:

El proceso fue modelado previamente con la herramienta modificada en este proyecto.


6.6 Análisis de los resultados Al analizar y ejecutar el código generado tras la definición de los atributos espaciales (Map Viewer) se verificó que éste correspondía con las propiedades asignadas durante el modelado, lo cual indicó que se realizó de forma correcta.

Durante la aplicación del plan de pruebas de los casos que evaluaron el funcionamiento de la aplicación Web generada, se presentaron los siguientes errores:

Caso GEOPROED-04-05. Este presentó conflictos de funcionamiento cuando

se definieron dos o más mapas, lo cual fue ocasionado por error en el manejo de los identificadores para los visores de mapas.

Caso GEOPROED-03. Este caso presenta error cuando se crea un atributo

con un identificador que contiene guiones altos o acentos, como se explica en


92

la prueba. Por tanto el diseñador se debe sujetar a estas restricciones para obtener el correcto funcionamiento de la aplicación Web generada.

Una vez identificados los problemas anteriores se procedió a la corrección del

código que provocaba estos errores, compilación y construcción de la herramienta. Con lo cual se obtuvo el funcionamiento deseado.

El tiempo que tarda el visor de mapas en ser cargado varía de acuerdo al número de capas desplegadas, así como el tráfico de la red. Este tiempo disminuye de forma dramática una vez cargado el visor, debido a que la información es almacenada en la caché del navegador Web.

Al finalizar la aplicación del plan de pruebas se pudo comprobar que mediante la modificación de la herramienta para la definición de procesos de negocio, fue posible integrar el uso de información espacial.

Capítulo 7. Conclusiones

93

Capítulo 7. Conclusiones En este capítulo se presentan las conclusiones obtenidas a través de la investigación y desarrollo de este trabajo de tesis, las aportaciones que con ella se dejan, los trabajos futuros que se pueden implementar para mejorar y complementar la herramienta modificada y las publicaciones y reconocimientos obtenidos durante su desarrollo.


94

7.1 Conclusiones El uso de información geográfica se ha acrecentado en la actualidad, con la aparición de los sistemas de información geográfica y los servidores de mapas Web, permitiendo presentar la información con un mayor grado de detalle. Es por eso que esta tesis ha tenido como objetivo modelar procesos de negocio que involucren el uso de información espacial y que la aplicación Web generada por estos sea capaz de manipularla. Lo anterior tiene como fin aprovechar los servicios y beneficios que el uso de este tipo de información ofrece.

Para alcanzar el objetivo planteado se realizó un estudio comparativo entre sistemas de workflow de código abierto que poseen características consideradas como deseables para este proyecto, de entre los cuales se eligió a Bonita workflow. A este sistema se le realizó un análisis funcional, a partir del cual se identificaron los componentes a modificar para integrar el manejo de información georeferencial. Tras este análisis se desarrolló un modelo de solución, el cual consistió en realizar un proceso de ingeniería inversa al editor de procesos ProEd para realizar las modificaciones pertinentes y se utilizó el servidor de mapas GeoServer para brindar los servicios geoespaciales.

La funcionalidad del editor de procesos modificado fue evaluada en base a un plan de pruebas sobre funcionalidad de software, en esta etapa se realizaron una serie de pruebas, las cuales exhibieron aspectos no contemplados durante el diseño e implementación que provocaban funcionamiento no deseable, éstos fueron identificados y corregidos. Al analizar los resultados arrojados por las pruebas realizadas se probó la hipótesis planteada y se demostró que mediante la modificación de la herramienta para la definición de procesos es posible modelar procesos que involucren el uso de información georeferencial.

El sistema muestra las siguientes ventajas con respecto a los sistemas de workflow de código abierto estudiados durante el estado de arte presentado en el primer capítulo: el editor de procesos utiliza un lenguaje estandarizado y regulado por el consorcio WfMC como lo es XPDL; el editor es una herramienta Web para modelado de procesos de negocio, lo cual permite ser utilizada sin tener que instalar un software específico en cada máquina; se permite la interacción en tiempo real con los servidores de mapas, presentándole al diseñador el catálogo de los mapas disponibles en estos simplificando el proceso de selección de los mapas; y la aplicación Web generada establece comunicación con el servidor de mapas en tiempo real en un entorno distribuido.

Con respecto a los productos comerciales las ventajas que se tienen son: los procesos que permite modelar no se restringen a un área en específico; la herramienta al utilizar un lenguaje estandarizado es interoperable y puede extender sus funcionalidades con otras herramientas; por último se evitan los altos costos de pagos por adquisición y licencias de uso.


95

El editor de procesos utiliza parte de la notación BPMN para el modelado gráfico de los procesos, lo que facilita el modelado al ser una notación ampliamente conocida y utilizada. De acuerdo con los desarrolladores originales de la herramienta las versiones siguientes adoptan por completo esta notación, de aquí la relevancia de que en trabajos futuros las modificaciones realizadas a éste se migren a las nuevas versiones.

Sin embargo, aún con las ventajas mencionadas anteriormente, el producto obtenido en esta tesis es un prototipo, es por esto que se recomienda implementar los puntos presentados en trabajos futuros para colocarlo como una herramienta competitiva. Este proyecto tiene un gran nicho de oportunidad, ya que, si bien no es una tecnología reciente, los sistemas de workflow siguen siendo una tecnología ampliamente utilizada en las pequeñas y mediadas empresas, además del sector gubernamental. Este último en la actualidad busca soluciones de código abierto para minimizar gastos eliminando el costo de las licencias de uso, necesidad que esta herramienta satisface por completo.

7.2 Aportaciones Este trabajo de tesis deja como aportación principal la herramienta de edición de procesos ProEd modificada, la cual permite modelar procesos que involucren el uso de información georeferencial, cuyas ventajas se han descrito en la sección anterior. Entre otras aportaciones se encuentran:

La incorporación de información georeferencial dentro de los procesos de negocio, utilizando un visor de mapas (Map Viewer).

Se probó la viabilidad de modificar un producto de código abierto para incorporarle características para el manejo de información geoespacial.

Se proporcionaron los medios necesarios al editor de procesos para lograr la

interconexión con un servidor de mapas libre.

Con el análisis realizado al sistema de workflow, en el cual se ha identificado su funcionamiento y para los editores las clases que involucran el manejo de los atributos, se dejan las bases para agregar nuevas funcionalidades a la herramienta.

7.3 Trabajos futuros Como resultado de este trabajo de investigación se han detectado oportunidades que pueden ayudar a complementar y mejorar el trabajo presentado en esta tesis, los cuales se describen a continuación:


96

Modificar las funciones desarrolladas en este trabajo de tesis, para lograr la interacción con otros servidores de mapas aparte de GeoServer. Lo cual es factible debido a que la biblioteca OpenLayers utilizada para establecer comunicación con el servidor de mapas desde la aplicación Web permite manejar diversas fuentes de datos.

Implementar la funcionalidad de manejo de adjunción de archivos (documentos) al sistema de workflow, y que esta funcionalidad se maneje desde el modelado del proceso a través de la herramienta ProEd.

Migrar los cambios a las nuevas versiones del editor de procesos ProEd y del editor de formularios xformeditor distribuidas por el equipo desarrollador de Bonita workflow, con el fin de aprovechar las mejoras que se han realizado sobre estos.

Implementar el segundo escenario de creación de formularios utilizado por formgenerator, el cual consiste en la creación de los formularios en tiempo real. Se recuerda que este escenario ocurre cuando no se han guardado los formularios desde la herramienta de definición de procesos (ver sección 4.2 de esta tesis).

7.4 Publicaciones y reconocimientos Este tema de tesis ha permitido tener las siguientes publicaciones, cuyos objetivos fueron mostrar la idea de los beneficios que puede aportar un sistema como el desarrollado en esta tesis en las organizaciones gubernamentales, así como la propuesta misma respectivamente.

“Spatial Data Integration for e-Government Workflow Processes”. Research in Computing Science, Advances in Computer Science. Encuentro Nacional de Computación. Mexicali, Baja California, México. ISBN: 1870-4069.

“Definición de procesos con datos espaciales mediante flujos de trabajo”. Jornadas de Sistemas de Telecomunicaciones (JST’08). Quito Ecuador. Mayo 2008 (withdraw).

Se participó en XIII Concurso Nacional de Creatividad en Computación en su

fase local celebrado en el Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet), en junio del 2008 obteniendo el primer lugar, dentro del área de Computación.

Anexo A. Diagramas de clases del editor ProEd

97

Anexo A.

Diagramas de clases del editor ProEd En el presente anexo se muestran los diagramas de clases de los paquetes: org.objectweb.proed.actions; org.objectweb.proed.chi.panels y org.objectweb. proed.graphModel, los cuales se encuentran descritos en el capítulo 4 de esta tesis.


98

Diagrama de clases del paquete org.objectweb.proed.actions

Anexo A. Diagramas de clases de ProEd

99

Diagrama de clases del paquete org.objectweb.proed.chi.panels


100

Diagrama de clases del paquete org.objectweb.proed.graphModel

Anexo B. Escenarios de los casos de uso del editor ProEd y xformeditor

101

Anexo B.

Escenarios de los casos de uso del editor ProEd y

xformeditor En este anexo se describen los escenarios de los casos de uso del editor de procesos ProEd y el editor de formularios xformeditor presentados en el capítulo 4 de esta tesis.

Los casos de uso presentados son: CU_1.Crear proceso de negocio; CU_2.Modificar proceso de negocio; CU_3.Definir actividades; CU_4.Definir atributos; CU_5.Modificar actividades; CU_6.Modificar atributos; CU_7.Definir atributo cadena; CU_8.Definir atributo de decisión; CU_9.Definir atributo espacial; CU_10.Editar formulario; CU_11.Procesar catálogo del servidor de mapas; CU_12.Seleccionar mapas a utilizar; CU_13. Generar código del visor de mapas y CU_14.Guardar formulario.


102

ID: CU_1

Nombre del caso de uso:

Crear proceso de negocio

Creador: Catalina Aranda Castillo

Ultima modificación:

Catalina Aranda Castillo

Fecha de creación:

15/10/2007 Fecha de última

modificación: 11/04/2008

Actores: Diseñador de procesos

Descripción: El editor de procesos permite que el diseñador cree un proceso de negocio.

Precondiciones: 1. El editor de procesos debe haber sido cargado desde la

consola de administración de procesos.

Poscondiciones: 1. Se crea un área de trabajo para modelar el proceso

Escenario de éxito:

1. El diseñador introduce las propiedades para el proceso 2. El editor de procesos crea el proceso especificado 3. Se despliega el área de trabajo para modelar el proceso

Escenario de fracaso (1):

1. El diseñador introduce las propiedades para el proceso 2. Ocurre un error interno 3. Se despliega un mensaje de error 4. Se cierra la aplicación


1. El diseñador introduce un valor con sintaxis errónea 2. Se despliega un mensaje indicando el error 3. Se pide el nuevo valor

Includes: CU_3. Definir actividades CU_4. Definir atributos

Suposiciones:

1. Se supone que el editor de procesos se ha autentificado con la consola de administración de procesos

2. Se supone que el editor mantiene conexión con la consola de administración.

ID: CU_2


Modificar proceso de negocio




Fecha de creación:





103

Descripción: El editor de procesos permite que el diseñador modifique un proceso de negocio creado con anterioridad.

Precondiciones: 1. El editor de procesos debe haber sido cargado desde la

consola de administración de procesos. 2. Debe existir un proceso

Poscondiciones: 1. Se cargan los elementos que conforman el proceso 2. Se despliegan el área de trabajo con los elementos para su

modificación


1. El diseñador selecciona el proceso a modificar 2. El editor de procesos carga los elementos del proceso 3. Se despliega el área de trabajo para modificar el proceso

Escenario de fracaso:

1. El diseñador selecciona el proceso a modificar 2. El editor no carga todos los elementos 3. Se despliega un mensaje de error 4. Se despliega el área de trabajo con los elementos cargados

Includes:

Suposiciones: 1. Se supone que el proceso ha sido creado con la

herramienta modificada

ID: CU_3


Definir actividades




Fecha de creación:




Descripción: Permite que el diseñador cree actividades y asigne sus propiedades.

Precondiciones: 1. El proceso del caso de uso CU_1 debe haber concluido

exitosamente

Poscondiciones: 1. Se crea la actividad 2. Se despliega la ventana de propiedades para su definición


1. El diseñador selecciona el botón de crear actividad 2. Da clic en el área de trabajo donde desea definirla 3. Introduce el nombre de la actividad y el participante que la

ejecutará 4. Se crea la actividad 5. Se despliega la ventana para definir sus propiedades


104


1. El diseñador selecciona el botón de crear actividad 2. Da clic en el área de trabajo donde desea definirla 3. Introduce el nombre de la actividad 4. El nombre ya existe 5. Se manda un mensaje de error 6. Se pide un nuevo nombre

Includes:

Suposiciones: 1. Se supone que el editor mantiene conexión con la consola

de administración.

ID: CU_4


Definir atributos




Fecha de creación:




Descripción: Permite que el diseñador cree atributos y asigne sus propiedades.


exitosamente

Poscondiciones: 1. Se crea un atributo


1. El diseñador da clic con el botón derecho sobre una actividad o proceso

2. Se despliega la ventana de propiedades y se selecciona la pestaña atributos

3. Se elige la opción agregar (add) 4. Se selecciona el tipo de atributo 5. Se definen las propiedades 6. El editor guarda el atributo


1. El diseñador da clic con el botón derecho sobre una actividad o proceso

2. Se despliega la ventana de propiedades y se selecciona la pestaña atributos

3. Se elige la opción agregar (add) 4. Se selecciona el tipo de atributo 5. Se definen las propiedades 6. Los valores introducidos son inválidos 7. Se despliega mensaje de error 8. Se cierra la ventana


105

Includes: CU_10. Editar formulario


de administración.

ID: CU_5


Modificar actividades




Fecha de creación:




Descripción: El editor de procesos permite al diseñador modificar las propiedades de las actividades.


exitosamente.

Poscondiciones: 1. Se guardan los nuevos valores de las propiedades de la

actividad.


1. Se edita la actividad 2. Se introducen los nuevo valores 3. Las modificaciones son guardadas


1. Se edita la actividad 2. Los valores introducidos son inválidos 3. Se manda un mensaje de error 4. Se descartan las modificaciones 5. Se cierra la ventana

Includes:

Suposiciones:

1. Se supone que el editor mantiene conexión con la consola de administración.

2. La actividad ha sido definida con la herramienta modificada.

ID: CU_6


Modificar atributos


106




Fecha de creación:




Descripción: El editor de procesos permite al diseñador modificar las propiedades de los atributos.

Precondiciones: 1. El proceso del caso de uso CU_2 debe haber concluido con

éxito.

Poscondiciones: 1. Se guardan los nuevos valores de las propiedades del

atributo.


1. Se selecciona el atributo 2. Seleccionar opción editar (edit) 3. Se introducen los nuevo valores 4. Las modificaciones son guardadas


1. Se selecciona el atributo 2. Seleccionar opción editar (edit) 3. Se introducen los nuevo valores 4. Los valores introducidos son inválidos 5. Se despliega un mensaje de error 6. Las modificaciones son descartadas 7. Se cierra la ventana

Includes:


de administración. 2. El atributo ha sido definido con la herramienta modificada.

ID: CU_7


Definir atributo cadena




Fecha de creación:




Descripción: Crea un atributo del tipo cadena


éxito


107

Poscondiciones: 1. Se crea un atributo del tipo con las propiedades definidas

por el usuario.


1. En la pestaña de atributos se selecciona la opción agregar (add).

2. Se selecciona tipo cadena (string) 3. Se introduce el nombre. 4. Se guarda el atributo. 5. El editor de procesos agrega el atributo dentro del modelo.



2. Se selecciona tipo cadena 3. Se introduce el nombre 4. Un atributo con ese nombre ya existe 5. Se despliega un mensaje de error 6. Se vuelve a pedir el nombre



2. Se selecciona tipo cadena 3. Se introduce el nombre 4. El nombre tiene una sintaxis invalida 5. Se despliega un mensaje de error 6. Se vuelve a pedir el nombre

Includes:


de administración.

ID: CU_8


Definir atributo de decisión




Fecha de creación:




Descripción: Crea un atributo del tipo decisión


éxito

Poscondiciones: 1. Se crea un atributo de decisión con las propiedades

definidas por el usuario


108



2. Se selecciona tipo decisión 3. Se introducen los valores de las propiedades. 4. Se guarda el atributo. 5. El editor de procesos agrega el atributo dentro del modelo



2. Se selecciona tipo decisión 3. Se introducen los valores de las propiedades 4. Un atributo con ese nombre ya existe 5. Se despliega un mensaje de error 6. Se vuelve a pedir el nombre



2. Se selecciona tipo decisión 3. Se introduce los valores de las propiedades 4. No se seleccionó un valor por defecto 5. Se despliega un mensaje de error 6. Se vuelven a pedir las propiedades

Includes:

Suposiciones: 1. El editor mantiene conexión con la consola de

administración

ID: CU_9


Definir atributo espacial




Fecha de creación:




Descripción: Crea un atributo de tipo espacial


éxito 2. Debe existir un servidor de mapas disponible

Poscondiciones: 1. Se crea un atributo de tipo espacial con las propiedades

definidas por el usuario


109



2. Se selecciona tipo espacial 3. Se introduce nombre del atributo 4. Se introduce la dirección del servidor de mapas. 5. Se obtiene el catálogo y se despliega al diseñador en forma

de lista de selección 6. Se seleccionan los mapas a utilizar 7. Se elige mapa como capa base 8. Se guarda el atributo. 9. El editor de procesos agrega el atributo dentro del modelo




de lista de selección 6. Se seleccionan mapas a utilizar 7. Se guarda el atributo. 8. El nombre ya está usado por otro atributo en el proceso 9. Se despliega un mensaje de error 10. Se regresa a la ventana de propiedades para introducir

nuevo valor



2. Se selecciona el tipo espacial 3. Se introduce nombre del atributo 4. Se introduce la dirección del servidor de mapas. 5. No se obtuvo catálogo de mapas 6. Se despliega un mensaje de error 7. Se regresa a la venta de propiedades para introducir nueva

dirección del servidor




de lista de selección 6. Se seleccionan mapas a utilizar 7. Se guarda el atributo. 8. No se definió capa base 9. Se despliega un mensaje de error 10. Se regresa a la ventana de propiedades para seleccionar el

mapa que fungirá como capa base

Includes: CU_11. Procesar catálogo del servidor de mapas


110

Suposiciones: 1. El editor mantiene conexión con la consola de

administración 2. El servidor de mapas está disponible en la red

ID: CU_10


Editar formulario




Fecha de creación:




Descripción: Genera el código en HTML de cada atributo para su almacenamiento y muestra una vista del formulario para su manipulación.

Precondiciones: 1. Deben existir atributos definidos 2. Se debe haber sincronizado el proceso con el editor de

formularios

Poscondiciones:

1. Se despliega el editor de formularios para la edición de atributos

2. Se genera el código de cada atributo para ser guardado como formulario XHTML


1. Se elige la opción Edit Xforms en la pestaña atributos dentro de las propiedades

2. Se crea el código de cada atributo 3. Se despliega la ventana del editor con los atributos

definidos.


1. Se elige la opción Edit Xforms en la pestaña atributos dentro de las propiedades

2. Ocurre un error durante la generación de código 3. Se lanza una excepción 4. EL código para el formulario queda incompleto

Includes: CU_12. Generar código del visor de mapas CU_13. Guardar formulario

Suposiciones:

1. El editor mantiene conexión con la consola de administración.

2. El editor de formularios tiene conexión con el motor de workflow.


111

ID: CU_11


Procesar catálogo del servidor de mapas




Fecha de creación:



Actores: Editor de procesos ProEd

Descripción: Procesa el catálogo del servidor de mapas y despliega una lista de los mapas disponibles.

Precondiciones:

1. Se debe estar en la fase de creación de un atributo del tipo espacial.

2. Se debe haber introducido una dirección (URL) en el campo correspondiente.

Poscondiciones:

1. Despliega una lista de los mapas disponibles en el servidor de mapas.

2. Se crea un arreglo con las propiedades que corresponden a cada mapa.


1. Se conecta al servidor de mapas 2. Se obtiene el catálogo en formato XML 3. Se obtienen los nombres de los mapas y sus propiedades 4. Se ordena de acuerdo a sus sistema de referencia espacial

(SRS) 5. Se despliega un lista con los nombres de los mapas

disponibles


1. No se puede establecer la conexión en el servidor de mapas 2. Se manda un mensaje de error de conexión


1. Se conecta al servidor de mapas 2. Se obtiene el catálogo en formato XML 3. No se encuentran mapas disponibles 4. Se despliega un mensaje de error

Includes:

Suposiciones:



3. El servidor de mapas se encuentra disponible en la red.


112

ID: CU_12


Generar código del visor de mapas




Fecha de creación:



Actores: Editor de formularios ProEd

Descripción: Genera el código en HTML del visor de mapas en base a las propiedades del atributo.

Precondiciones: 1. Debe existir un atributo de tipo espacial definido

Poscondiciones: 1. Se genera el código que corresponde al visor de mapas a

desplegar 2. Se despliega el código dentro del editor de formularios


1. Se reciben las propiedades del atributo 2. Se desempaquetan las propiedades 3. Se crea el código para el visor de mapas 4. Se despliega el código generado en el editor de formularios


1. Se reciben las propiedades del atributo 2. Se desempaquetan las propiedades 3. Las propiedades están incompletas 4. Se lanza una excepción 5. El código del formulario queda incompleto

Includes:

Suposiciones:



ID: CU_13


Guardar formulario




Fecha de creación:





113

Descripción: Guarda el formulario creado en el motor de workflow


éxito

Poscondiciones: 1. Se crea un formulario XHTML en el motor de workflow, el

cual guarda correspondencia con el proceso modelado.


1. El diseñador selecciona la opción guardar (save) 2. Se guarda el formulario en el motor de workflow 3. Se envía mensaje de formulario guardado


1. El diseñador selecciona la opción guardar (save) 2. Falla la conexión con el motor de workflow 3. Se envía mensaje de error

Includes:

Suposiciones:



Anexo C. Descripción de los casos de prueba

114

Anexo C.

Descripción de los casos de prueba En este anexo se describen de forma completa los procedimientos de los casos de prueba para la herramienta de definición de procesos ProEd presentados en el capítulo 5 de esta tesis. Estas pruebas tienen como objetivo validar y verificar que las funciones agregadas a la herramienta se comporten de forma adecuada.

Para cada caso de prueba se describe el propósito, entorno, proceso y resultado esperado.


115

1. GEOPROED-01 Definición de formularios con datos espaciales a) Propósito

Definir atributos de tipo Map Viewer en los formularios a utilizar por los procesos modelados. b) Entorno de prueba

La definición de los formularios se debe realizar con el editor de procesos modificado ProEd, en un ambiente como el descrito en la sección 6.3 inciso (j). Se tiene como prerrequisito tener creado un proceso. 1.1 GEOPROED-01-01 Definición del atributo Map Viewer

a) Propósito

Definir un atributo Map Viewer, el cual contendrá las propiedades necesarias para crear un visor de mapas dentro del formulario del proceso o actividad correspondiente. b) Entorno de prueba

Esta prueba se llevará a cabo dentro del editor de procesos (ProEd), habiendo definido previamente un proceso de negocio en un ambiente como el descrito en la sección 6.3 inciso (j). c) Proceso

1. Dentro de la pestaña atributos seleccionar la opción add 2. Elegir el tipo Map Viewer 3. Introducir la dirección del servidor de mapas 4. Establecer conexión por medio del botón Connect 5. Seleccionar las capas deseadas 6. Guardar las capas con el botón Save 7. Seleccionar el mapa que fungirá como capa base 8. Guardar el atributo dando clic en ok

d) Resultado esperado

El editor de procesos creará el atributo Map Viewer con las propiedades definidas por el diseñador.

1.2 GEOPROED-01-02 Procesamiento del catálogo de mapas.

a) Propósito

Procesar el catálogo recibido, extraer los nombres y atributos de los mapas disponibles en el servidor de mapas

b) Entorno de prueba

La prueba tiene como prerrequisito estar en la etapa de definición de un atributo Map Viewer (GEOPROED-01-01), introducir la dirección del servidor de mapas en el campo correspondiente.


116

c) Proceso

1. Establecer comunicación con el servidor de mapas 2. Obtener el catálogo en formato XML 3. Extraer las mapas y atributos 4. Ordenar de acuerdo al sistema de referencia espacial (SRS) 5. Desplegar lista de mapas disponibles


Se desplegará la lista de las capas disponibles en el servidor de mapas al diseñador para que éste seleccione las deseadas.

1.3 GEOPROED-01-03 Modificación del atributo Map Viewer

a) Propósito

Modificar las propiedades definidas de un atributo Map Viewer, permitiendo cambiar el servidor de mapas así como los mapas a desplegar. b) Entorno de prueba

La prueba tiene como prerrequisito haber definido un atributo del tipo Map Viewer (GEOPROED-01-01). c) Proceso

1. Seleccionar el atributo a modificar 2. Elegir la opción edit 3. Realizar las modificaciones pertinentes 4. Guardar cambios dando clic en el botón ok


El atributo guardará los nuevos valores introducidos. 1.4 GEOPROED-01-04 Eliminación de un atributo Map Viewer

a) Propósito

Eliminar un atributo Map Viewer. b) Entorno de prueba


1. Seleccionar el atributo a eliminar 2. Dar clic en el botón delete 3. Confirmar la eliminación del atributo


El atributo será eliminado de los atributos a crear en el formulario.


117

1.5 GEOPROED-01-05 Propagación dato Map Viewer a) Propósito

El atributo Map Viewer podrá ser utilizado por las actividades definidas posteriormente.



1. Definir una nueva actividad 2. En la pestaña atributos, el atributo Map Viewer definido con anterioridad

esta marcado como atributo inherente.


Una vez definido un atributo del tipo Map Viewer se marcará como atributo inherente para el resto de las actividades del proceso.

2. GEOPROED-02 Generación de formulario a) Propósito

Que el editor de procesos sea capaz de generar el código correspondiente al atributo Map Viewer. b) Entorno de prueba

La prueba tiene como prerrequisito haber definido un atributo del tipo Map Viewer (GEOPROED-01-01). 2.1 GEOPROED-02-01 Generación del código para el atributo Map Viewer

a) Propósito

Que el editor de formulario cree el código para un visor de mapas.


Se tiene como prerrequisito haber definido un atributo del tipo Map Viewer (GEOPROED-01-01).

c) Proceso 1. Dentro de la pestaña atributos, seleccionar la opción Edit Xform 2. xformeditor generara automáticamente el código 3. Se presentará al diseñador una ventana con los atributos y código del

formulario XHTML.


El editor de formularios xformeditor es capaz de crear el código necesario para construir un visor de mapas, con las características especificadas por el diseñador.


118

2.2 GEOPROED-02-02 Manipulación del atributo Map Viewer dentro del formulario

a) Propósito

El atributo Map Viewer podrá ser manipulado, de forma que el diseñador pueda cambiarlo de posición.


Se tiene como prerrequisito haber realizado la prueba GEOPROED-02-01.

c) Proceso

1. Seleccionar el atributo 2. Utilizar los botones de arriba y abajo para mover el atributo 3. Guardar cambios


EL atributo se cambiará de posición de acuerdo a la especificación del diseñador.

3. GEOPROED-03 Conexión de la aplicación Web con el servidor de mapas. a) Propósito

Establecer comunicación con el servidor de mapas y recibir como respuesta el mapa solicitado, desde el proceso en ejecución a través visor de mapas. b) Entorno de prueba

Esta prueba tiene como prerrequisito haber realizado la prueba GEOPROED-02 y haber importado el proceso desde la consola de administración de procesos. El formulario será llamado desde la consola de administración de procesos en un ambiente de cliente como el descrito en la sección 6.3 inciso (j). c) Proceso

1. Ejecutar la instancia de proceso. 2. La consola de administración llama al formulario correspondiente. 3. EL formulario envía la petición al servidor de mapas mediante el script generado

4. Desplegar respuesta en forma de mapa al usuario.


Desplegar al usuario el/los mapa(s) correspondiente(s) contenido(s) en el visor de mapas.

4. GEOPROED-04 Interacción con el mapa a) Propósito

Interactuar con el mapa mediante el visor de mapas.


119

b) Entorno de prueba Se tiene como prerrequisito haber realizado el caso de prueba GEOPROED-03, en un ambiente de cliente como el descrito en la sección 6.3 inciso (j). 4.1 GEOPROED-04-01 Realizar zoom in sobre el mapa

a) Propósito

Realizar la operación de zoom in (acercamiento) sobre el mapa.


Esta prueba tiene como prerrequisito haber ejecutado la prueba GEOPROED-03 Interacción del visor de mapas creado con el servidor de mapas. c) Proceso

Dar clic en el botón de acercamiento de las herramientas de visualización de visor de mapas o en su defecto mover el scroll del mouse hacia arriba.


El mapa se mostrará al usuario a una mayor escala. 4.2 GEOPROED-04-02 Realizar zoom out sobre mapa

a) Propósito

Realizar la operación de zoom out (alejamiento) sobre el mapa. b) Entorno de prueba Esta prueba tiene como prerrequisito haber ejecutado la prueba GEOPROED-03. c) Proceso

Dar clic en el botón de alejamiento de las herramientas de visualización de visor de mapas o en su defecto mover el scroll del mouse hacia abajo.


El mapa se mostrará al usuario a una menor escala. 4.3 GEOPROED-04-03 Paneo sobre el mapa

a) Propósito

Mover el 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. b) Entorno de prueba

Esta prueba tiene como prerrequisito haber ejecutado la prueba GEOPROED-03. c) Proceso Dar clic en la el mapa y mover en dirección contraria a la región que desea visualizar.


120

d) Resultado esperado Se visualizará la región del mapa que el usuario desea visualizar. 4.4 GEOPROED-04-04 Manipulación de capas

a) Propósito

Activar o desactivar la visualización de las capas disponibles en el visor de mapas. b) Entorno de prueba

Esta prueba tiene como prerrequisito haber ejecutado la prueba GEOPROED-03. c) Proceso

1. Dar clic en el área de visualización de capas del visor de mapas 2. Activar o desactivar las capas que desea visualizar


En el visor de mapas sólo se mostrarán las capas activadas por el usuario. 4.5 GEOPROED-04-05 Inserción de puntos de interés

a) Propósito

Fijar puntos de interés (POIs) sobre el mapa a través del visor de mapas. b) Entorno de prueba

Esta prueba tiene como prerrequisito haber ejecutado la prueba GEOPROED-03. c) Proceso

1. Dar clic en la región de mapa donde se desee fijar el punto de interés 2. Si se desea remover dar clic en otra región del mapa


Se fijará un punto de interés en la región del mapa seleccionada por el usuario.

5 GEOPROED-05 Almacén de puntos de interés (POIs) a) Propósito

Guardar y desplegar el punto de interés definido por el usuario. b) Entorno de prueba

Se tiene como prerrequisito haber realizado los casos de prueba: GEOPROED-03 y GEOPROED-04-05. La prueba se debe realizar en un ambiente como el descrito en la sección 6.3 inciso (j).


121

5.1 GEOPROED-05-01 Inserción de puntos de interés (POIs) a) Propósito

Almacenar el punto de interés insertado por el usuario en la instancia de proceso. b) Entorno de prueba

Se tiene como prerrequisito haber realizado los casos de prueba: GEOPROED-03, GEOPROED-04-05. El ambiente debe ser el descrito en la sección 6.3 inciso (j). c) Proceso

1. Tomar las coordenadas del punto de interés. 2. Fijar los valores en los campos correspondientes.

3. Enviar los valores de los campos del formulario al motor de workflow


El punto de interés se almacenado dentro del motor de workflow.

5.2 GEOPROED-05-02 Recuperación de puntos de interés (POIs)

a) Propósito

Dibujar el punto de interés marcado por el usuario sobre el mapa, el cual corresponde a la instancia del proceso en ejecución. b) Entorno de prueba

Se tiene como prerrequisito haber realizado el caso de prueba GEOPROED 05-01. El ambiente debe ser el descrito en la sección 6.3 inciso (j). c) Proceso

1. Extraer los valores de los campos correspondientes a las coordenadas del punto de interés.

2. Marcar el punto de interés sobre el mapa.


Desplegar el punto de interés (POI) marcado por el usuario en una actividad anterior.

6. GEOPROED-06 Reconocimiento de atributos Map Viewer a partir de un proceso existente. a) Propósito

Cargar a memoria los atributos Map Viewer a partir de un proceso previamente creado en formato XPDL para su modificación.


122

b) Entorno de prueba La prueba se debe realizar con el editor de procesos modificado ProEd, en un ambiente como el descrito en la sección 6.3 inciso (j). Se tiene como prerrequisito contar con un proceso en formato XPDL, modelado previamente con la herramienta sujeta a prueba en este plan. c) Proceso

1. Cargar un proceso existente mediante la opción open. 2. El editor de procesos carga a memoria las actividades y atributos definidos.

3. Reconoce el atributo de tipo Map Viewer 4. Agrega el atributo al modelo para su modificación.


Los atributos Map Viewer son reconocidos por el editor de procesos a partir de un proceso existente en formato XPDL, permitiendo su modificación.

Referencias

123

Referencias [BLAC07] OW2 Consortium, Marc Blachon, “Cutomizing XForms”, 29 de marzo de 2007,

http://forge.objectweb.org/forum/message.php?msg_id=8373, [fecha consulta: marzo de 2008].

[BULL07] Bull R&D, “Bonita, The Open Source Workflow project”, http://wiki.bonita.

objectweb.org/xwiki/bin/view/Main/, [fecha consulta: septiembre de 2007]. [CALV07] Daniel Calvelo, “Intercambio de datos espaciales”, 6 de julio de 2007, http://

metadatos.ingemmet.gob.pe/files/IDEP_ANEXO5_INTERCAMBIO.pdf, [fecha consulta: septiembre de 2008].

[CARO03] Carol Prior, “Workflow and Process Management”, 02 de mayo de 2003, http://

www.wfmc.org/information/Workflow_and_Process_Management.pdf, [fecha consulta: septiembre de 2008].

[CONS08] Consejo superior geográfico, Infraestructura de datos espaciales de España,

“WMS, Web Map Service Versión: 1.3.0”, http://www.idee.es/show.do?to= pideep_desarrollador_wms.ES, [fecha consulta: septiembre de 2008].

[CORA99] Coralina Bastidas Ramírez, “Integración de tecnologías de información cliente/

servidor, workflow y gis una experiencia nacional”, http://gis2.esri.com/library /userconf/latinproc99/ponencias/ponencia39.html#_Toc447014972, [fecha consulta: noviembre de 2007].

[DELG03] Delgado Jalón José Luis, “Integración de información económica y territorial”,

VIII Congreso Internacional del CLAD sobre la Reforma del Estado y de la Administración Pública, octubre de 2003, http://unpan1.un.org/intradoc/ groups/public/documents/CLAD/clad0047804.pdf, [fecha consulta: agosto de 2008].

[FERN05] Tomás Fdez. de Sevilla Riaza, “GML: El lenguaje de marcado extendido (XML)

para la Ingeniería Geográfica. Ventajas y aplicaciones.”, abril de 2005, Departamento de Ingeniería Topográfica y Cartografía, Universidad Politécnica de Madrid, http://mapas.topografia.upm.es/geoserviciosOGC/documentacion/ GML/GML_en_la_IngGeografica_ver2005.pdf, [fecha consulta: septiembre de 2008].

[GEOP04] Diputación Provincial de Valencia, “Aplicación GeoPISTA”, http://www.dival.es

/isum/Main?ISUM_ID=Left&ISUM_SCR=serviceScr&ISUM_CIPH=ntnBCl!WtMj1UE-TUO0yiuzUr6iUUu6GOofSGy qoevU#, [fecha consulta: octubre de 2007].

[GEOP04b] GeoPISTA, “GeoPISTA (Hoja del producto)”, marzo de 2004, http://www.

geopista.com/fileadmin/docs/Hoja%20de%20producto.pdf, [fecha consulta: octubre de 2007].

[GEOP06] GeoPISTA, “Guía GeoPISTA”, marzo de 2006, http://www.pistalocal.es/ppal/

Main?ISUM_ID=Content&ISUM_SCR=externalServiceScr&ISUM_CIPH=NO4nynRwy0OE6lYBQZAIU3ppTzJTAb8hGkD54Dj8nH1tyPpcHA1MlIIFVSaz763SmXxM

Referencias

124

kI3utXtp3StuJ5zpcaqdhzkhW6GgKRsKp19ysnlzVv2uQ5eOEHkS-0M2GeO8QjJ dRDM3Kj3yNMMdXNTOK9PMB4GMvOMe, [fecha consulta: octubre de 2007]

[GERO07] G. Gerónimo, V. Canseco, “Breve Introducción a los Sistemas Colaborativos:

Groupware & Workflow”, Universidad Tecnológica de Mixteca http://mixtli.utm. mx/~resdi/breve_introduccion_a_los_sistemas_colaborativos.pdf, [fecha consulta: mayo de 2007].

[GEOP08] GeoPortal, Portal de IDEs del Instituto Geográfico Militar, “Infraestructura de Datos Espaciales”, http://www.geoportaligm.gov.ec:8080/portal/, [fecha consulta: septiembre de 2008].

[GIS07] GIS, “¿What is GIS?”, http://www.gis.com/whatisgis/index.html, [fecha

consulta: septiembre de 2008]. [HERR07] Fabio Andrés Herrera Rozo, “Servidores de Mapas, Modelo de Datos para SIG”,

Facultad de Ingeniería Civil y Geomática, Universidad del Valle, 04 de mayo de 2007, http://t763rm3n.googlepages.com/MDBSIG_Taller4_DBSig_ServMaps .pdf, [fecha consulta: septiembre de 2008].

[IDEE08a] Infraestructura de Datos Espaciales de España, “WFS, Web Feature Service

Versión: 1.1.0”, http://www.idee.es/CatalogoServicios/operaciones/WFS_Web_ Feature_Service_V_1_1_0.pdf, [fecha consulta: septiembre de 2008].

[IDEE08b] Infraestructura de Datos Espaciales de España, “WCS, Web Coverage Service

Versión: 1.1.1c1”, http://www.idee.es/show.do?to=pideep_desarrollador_wcs. ES, [fecha consulta: septiembre de 2008].

[IEEE98] Software Engineering Technical Committee of the IEEE Computer Society, USA,

“IEEE standard for software test documentation”, 16 de diciembre de 1998, E-ISBN: 0-7381-1444-8, ISBN: 0-7381-1443-X, [fecha de consulta: marzo de 2008]

[INTA07] Intalio, “Product Benefits”, http://www.intalio.com/products/designer/, [fecha

consulta: septiembre de 2007]. [JBOO07] Red Hat, Inc., JBoos, “JBOSS JBPM”, http://www.jboss.com/pdf/

jb_jbpm_04_07.pdf, [fecha consulta: septiembre de 2007]. [LANT03] Lantmäteriet, “ArcCadastre”, febrero de 2003, http://www.arccadastre.com

/pub_files/Arc_2003.spa_esri.pdf, [fecha consulta: noviembre de 2007]. [LANT07] Lantmäteriet, “ArcCadastre Product”, 25 de mayo de 2007,

http://www10.giscafe. com/link/display_ detail.php?link_id=19442, [fecha consulta: noviembre de 2007]

[LUNA04] Luna Macías, “OGGDB: Modelado e Implementación de una Base de datos

Geográfica para OpenGIS”, Departamento de Ingeniería en Sistemas Computacionales, Universidad de las Américas Puebla, tesis Licenciatura, agosto de 2004. http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/ macias_l_c/, [fecha consulta: septiembre de 2008].

Referencias

125

[MARRO99] Marroquin Willy, “Workflow y UML”, octubre de 1999, http://www.willydev.net/ descargas/articulos/general/WorkFlowUML.pdf, [fecha consulta: abril de 2007].

[MONT07] Montesinos Lajara Miguel, Gaspar Sanz Salinas Jorge, “Panorama actual del

ecosistema de software libre para SIG”, Jornadas de SIG Libre, http://www.sigte.udg.es/jornadassiglibre2007/comun/1pdf/12.pdf, [fecha consulta: septiembre de 2008].

[MUÑO06] Muñoz-Cruzado García Carmen, “Web Feature Service (WFS)”, Universidad Politécnica de Madrid, octubre de 2006, http://mapas.topografia.upm.es/ geoserviciosOGC/documentacion/WFS/WFS1.pdf, [fecha consulta: septiembre de 2008].

[NURI07] Nuria Cordón, “Los Sistemas de Información Geográfica se hacen populares en

la empresa”, Computerworld Nº: 1128, Pág. 12, IDG Communications, S.A.U., 02 de febrero de 2007, http://www.idg.es/computerworld/articulo.asp?id= 300536762, [fecha consulta: junio de 2007].

[OPEN08] Open Source software community, OpenLayers, http://www.openlayers.org/,

[fecha de consulta: julio de 2008]. [PANA05] Panagiotis A. Vretanos, “Web Feature Service Implementation Specification”,

Open Geospatial Consortium, mayo de 2005, http://www.opengeospatial.org/ standards/wfs, [fecha consulta: septiembre de 2008].

[PELA03] Pelaez Ramírez J. J., “El modelo de capacidad de madurez y su enfoque al

proceso personal de software (PSP)”, Departamento de Ingeniería en Sistemas Computacionales, Universidad de las Américas Puebla, tesis de licenciatura, marzo 2003, http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/pelaez_r_ jj/capitulo_4.html, [fecha consulta: diciembre de 2008].

[RENA03] Renato de Laurentiis Gianni, “BPMS, Tecnología para la Integración y

Orquestación de Procesos, Sistemas y Organización”, octubre de 2003, http://www.rrhhmagazine.com/articulos.asp?num_art=253, [fecha consulta: junio de 2007].

[SANC08] Sánchez Maganto Alejandra, “Estándares y recomendaciones: OGC y CSG”,

Instituto Geográfico Nacional de España, julio de 2008, http://www. conc2008login.ibge.gov.br/pesquisador/doc/geo/5.B.5_SLD_Teoria.pdf, [fecha consulta: septiembre de 2008].

[SERR02] Serra del Pozo Pau, “Cinco servidores de mapas”, Oficina Técnica de Cartografía,

Diputación de Barcelona, octubre de 2002, http://www.mapping interactivo.com/plantilla-ante.asp?id_articulo=179, [fecha consulta: septiembre de 2008].

[TINO08] Tinoco Guevara Roberto, “Definición y algunas aplicaciones de los sistemas de

información geográfica”, http://www.monografias.com/trabajos14/informa geogra/informageogra.shtml#ap, [fecha consulta: septiembre de 2008].

Referencias

126

[TOGE07] Together Teamlösungen EDV-Dienstleistungen GmbH, “Open source Java XPDL editor”, The Enhydra.org initiative, http://www.enhydra.org/workflow/ jawe/index.html, [fecha consulta: septiembre de 2007].

[VALD05] Valdés Faura Miguel, “Form Generator 1.1”, Bull R&D, 26 de abril de 2005,

http://wiki.bonita.objectweb.org/xwiki/bin/download/Main/Documentation/formGenerator.pdf., [fecha consulta: noviembre 2007].

[VALD06] Valdés Faura Miguel, Blachon Marc, “The BONITA Workflow System XPDL

Support” (Version 1.0), BULL R&D, mayo de 2006, http://wiki.bonita. objectweb.org/xwiki/bin/download/Main/Documentation/bonitaXPDL.pdf, [fecha consulta: septiembre de 2008].

[WILM03] Wil M.P. van der Aalst, “Patterns and XPDL: A Critical Evaluation of the XML

Process Definition Language”, Eindhoven University of Technology, junio de 2003, http://is.tm.tue.nl/research/patterns/download/ce-xpdl.pdf, [fecha consulta: noviembre 2007]

[WfMC05] The Workflow Management Coalition, “Workflow Process Definition Interface

XML Process Definition Language”, octubre de 2005, http://www.wfmc.org/ standards/docs/TC-1025_xpdl_2_2005-10-03.pdf, [fecha consulta: abril de 2007].

[WfMC99] Workflow Management Coalition, “Terminology & Glossary”, febrero de 1999,

http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf, [fecha consulta: abril de 2007].

ACC Documento tesis - CENIDET · 2020. 7. 7. · facilitado el manejo y procesamiento de...

Documents

Transcript of ACC Documento tesis - CENIDET · 2020. 7. 7. · facilitado el manejo y procesamiento de...