Pruebas - Repositorio Digital-UPS: Homedspace.ups.edu.ec/bitstream/123456789/7581/1/UPS-ST001316.pdf · El capítulo 1 “Marco teórico” contiene información de la metodología

Pruebas

UNIVERSIDAD POLITÉCNICA SALESIANA

SEDE QUITO

CARRERA:

INGENIERÍA DE SISTEMAS

Trabajo de titulación previo a la obtención del título de: INGENIERO DE SISTEMAS E INGENIERA DE SISTEMAS

TEMA:

ANÁLISIS, DISEÑO Y CONSTRUCCIÓN DEL MÓDULO DE SEGURIDAD E INTEGRACIÓN DE LOS MÓDULOS DE VISUALIZACIÓN Y GESTIÓN

DE DATOS GEOGRÁFICOS DEL GEOPORTAL DE LA COMUNIDAD SALESIANA VERSIÓN 2.0.

AUTORES: TANIA CARINA TORRES JÁCOME

DARWIN VINICIO ALDAS BARRERA

DIRECTOR: GUSTAVO ERNESTO NAVAS RUILOVA

Quito, enero del 2015

DECLARATORIA DE RESPONSABILIDAD Y AUTORIZACIÓN DE USO

DEL TRABAJO DE TITULACIÓN

Nosotros, autorizamos a la Universidad Politécnica Salesiana la publicación total o

parcial de este trabajo de titulación su reproducción sin fines de lucro.

Además, declaramos que los conceptos y análisis desarrollados y las conclusiones

del presente trabajo son de exclusiva responsabilidad de los autores.

Quito, enero del 2015

---------------------------------------------- ----------------------------------------

Tania Carina Torres Jácome Darwin Vinicio Aldas Barrera

CC 1723519078 CC 1719279729

AGRADECIMIENTO

Agradecemos a la Universidad Politécnica Salesiana y a sus docentes por habernos

abierto sus puertas, para acoger el conocimiento con el que ahora contamos y poder

defendernos frente a la sociedad competitiva en que nos encontramos actualmente.

Por último agradecemos a nuestro tutor Gustavo Navas Ruilova, por asignarnos este

proyecto, y estar siempre disponible para todas las consultas que le hemos realizado

durante la realización del mismo, su apoyo incondicional ha ayudado a que nuestro

trabajo en conjunto finalice exitosamente.

A todos ellos muchas gracias y que Dios los bendiga.

Carina Torres Jácome

Darwin Aldas Barrera

ÍNDICE

INTRODUCCIÓN ....................................................................................................... 1

CAPÍTULO 1 ............................................................................................................... 2

MARCO TEÓRICO ..................................................................................................... 2

1.1 Objetivos ................................................................................................................ 2

1.1.1 Objetivo general .................................................................................................. 2

1.1.2 Objetivos específicos .......................................................................................... 2

1.2 Alcance ................................................................................................................... 2

1.3 Justificación............................................................................................................ 4

1.4 Marco teórico ......................................................................................................... 4

1.4.1 Geoportal Web .................................................................................................... 4

1.4.2 Metodología OOHDM ........................................................................................ 5

1.4.3 Herramientas de desarrollo a utilizar. ................................................................. 7

1.4.4 Tipo de Arquitectura ........................................................................................... 9

CAPÍTULO 2 ............................................................................................................. 10

REQUERIMIENTOS DEL SISTEMA ...................................................................... 10

2.1 Definición de roles ............................................................................................... 10

2.2 Priorización de escenarios .................................................................................... 11

2.3 Especificación de casos de uso de negocio .......................................................... 12

2.4 Diagramas de secuencia ....................................................................................... 23

CAPÍTULO 3 ............................................................................................................. 28

DISEÑO DE LA ARQUITECTURA ....................................................................... 28

3.1 Diseño conceptual ................................................................................................ 31

3.2. Diseño navegacional ........................................................................................... 32

3.3 Diseño de interfaz abstracta ................................................................................. 33

3.5 Diagrama de clases ............................................................................................... 38

3.6 Modelo de la base de datos .................................................................................. 39

3.7 Diccionario de base de datos ................................................................................ 41

3.8 Diagrama de componentes ................................................................................... 47

3.9 Diagrama de despliegue ....................................................................................... 48

CAPÍTULO 4 ............................................................................................................. 49

DESARROLLO ......................................................................................................... 49

4.1 Funciones del módulo de seguridad. .................................................................... 49

4.2 Integración del sistema ......................................................................................... 49

4.3 Autenticación. ...................................................................................................... 60

4.4 Auditoría. ............................................................................................................. 65

CAPÍTULO 5 ............................................................................................................. 66

IMPLEMENTACIÓN Y PRUEBAS ......................................................................... 66

5.1 Implementación .................................................................................................... 66

5.1.2 Requerimientos mínimos .................................................................................. 66

5.1.3 Restauración de la base de datos ....................................................................... 67

5.1.4 Carga del archivo .war en el servidor Apache Tomcat ..................................... 67

5.2 Pruebas ................................................................................................................. 70

CONCLUSIONES ..................................................................................................... 75

RECOMENDACIONES ............................................................................................ 76

LISTA DE REFERENCIAS ...................................................................................... 77

ÍNDICE DE FIGURAS

Figura 1. Fases de la metodología OOHDM ................................................................ 5

Figura 2. Arquitectura en tres capas ............................................................................. 8

Figura 3. Caso de uso auditoría .................................................................................. 11

Figura 4. Caso de uso cambio de contraseña ............................................................ 12

Figura 5. Caso de uso administración de perfiles ...................................................... 13

Figura 6. Caso de uso administración de módulos ..................................................... 14

Figura 7. Caso de uso administración de menús por pantalla .................................... 15

Figura 8. Caso de uso administración de usuarios ..................................................... 16

Figura 9. Caso de uso administración de roles ........................................................... 17

Figura 10. Caso de uso administración de módulos por rol ...................................... 18

Figura 11. Diagrama de secuencia auditoría de transacciones en el sistema.. ........... 19

Figura 12. Diagrama de secuencia cambio de contraseña.......................................... 20

Figura 13. Diagrama de secuencia administración de perfiles ................................... 21

Figura 14. Diagrama de secuencia administración de módulos ................................. 22

Figura 15. Diagrama de secuencia administración de usuarios ................................. 23

Figura 16. Módulo de seguridad ................................................................................ 24

Figura 17. Módulo de seguridad para el geoportal. ................................................... 25

Figura 18. Diseño lógico del módulo de seguridad.................................................... 25

Figura 19. Roles de administración para el geoportal ................................................ 26

Figura 20. Diseño Conceptual del mòdulo de seguridad ........................................... 27

Figura 21. Diseño Navegacional de la seguridad ...................................................... 28

Figura 22. ADV’s Pantalla inicio y autenticación ..................................................... 29

Figura 23. ADV’s Pantalla de elementos del menú del sistema ................................ 29

Figura 24. ADV’s Pantalla de administración del módulo de seguridad ................... 30

Figura 25. ADV’s Pantalla inserción y edición de registros ...................................... 30

Figura 26. ADV’s Elementos de interfaz de auditoría ............................................... 31

Figura 27. Diagrama de clases del gstor y visualizador . ........................................... 32

Figura 28. Diagrama de clases del módulo de seguridad. .......................................... 33

Figura 29. Modelo lógico de la base de datos ............................................................ 34

Figura 30. Modelo físico de la base de datos ............................................................. 35

Figura 31. Diagrama de componentes del módulo de seguridad. .............................. 42

Figura 32. Diagrama de despliegue del sistema. ........................................................ 43

Figura 33. Proyectos restaurados en un solo IDE, Etapas. ........................................ 45

Figura 34.Proyectos restaurados en un solo IDE. ...................................................... 45

Figura 35. Integración de los archivos correspondientes a capa interfaz. .................. 46

Figura 36. Integración de los paquetes y clases de cada uno de los proyectos. ......... 46

Figura 37. Ejemplo de importación de paquetes con el nombre correcto. ................. 47

Figura 38. Unificación de librerías............................................................................ 48

Figura 39. Sistema Integrado Salesiano ..................................................................... 49

Figura 40. Clase LoginFilter ...................................................................................... 50

Figura 41. Método de paso por filtro a usuarios activos ............................................ 50

Figura 42 Clase LoginBean (clase que ayuda a validar el ingreso al sistema). ......... 52

Figura 43.Clase control_md5(ubicación de la clase para encriptar las contraseñas). 54

Figura 44. Método ConsultaUsuarioActivo ............................................................... 55

Figura 45. Método buscaUsuario. .............................................................................. 55

Figura 46. Usuario por Casa Salesiana ..................................................................... 60

Figura 47. Clase ServicioAuditoria ........................................................................... 61

Figura 48. Creación de la base de datos .................................................................... 61

Figura 49. Ejecución del scipt postgis....................................................................... 65

Figura 50. Ejecución de script Spatial....................................................................... 67

Figura 51. Restauración de la base de datos ............................................................. 68

Figura 52. Servidor web ............................................................................................ 68

Figura 53. Ingreso a administración del servidor web .............................................. 69

Figura 54. Pantalla de gestión de aplicaciones.......................................................... 70

Figura 55. Selección del archivo war ........................................................................ 71

Figura 56. Proyectos desplegados .............................................................................. 71

Figura 57. Creación de grupo de hilos ....................................................................... 71

Figura 58. Creación de petición HTTP ...................................................................... 72

Figura 59. Creación de resultados .............................................................................. 72

Figura 60. Resultados árbol con 50 muestras ............................................................ 73

Figura 61. Árbol de resultados ................................................................................... 73

Figura 62. Resultado en árbol con 150 muestras ....................................................... 74

Figura 63. Resultados en árbol con 200 muestras ...................................................... 74

ÍNDICE DE TABLAS

Tabla 1. Módulos que forman parte del sistema integrado .......................................... 2

Tabla 2. Herramientas utilizadas para el desarrollo del módulo de seguridad............. 6

Tabla 3. Descripción de actores del sistema ................................................................ 9

Tabla 4. Descripción de casos de uso del sistema ...................................................... 10

Tabla 5. Descripción de casos de uso del módulo de seguridad ................................ 11

Tabla 6. Casos de uso de auditoría ............................................................................. 12

Tabla 7. Casos de uso de ingreso visual de la ubicaciòn del lugar ............................ 13

Tabla 8. Casos de uso administración de perfiles ...................................................... 15

Tabla 9. Casos de uso administración de módulos .................................................... 18

Tabla 10. Caso de uso adminitración de menús por pantalla ..................................... 19

Tabla 11. Casos de uso administración de usuarios ................................................... 20

Tabla 12. Casos de uso administración de roles ........................................................ 21

Tabla 13 Caso de uso administración de módulos por rol ......................................... 40

Tabla 14. Diccionario de datos tabla módulo............................................................. 41

Tabla 15. Diccionario de datos tabla submódulo ....................................................... 41

Tabla 16. Diccionario de datos tabla permiso ............................................................ 42

Tabla 17. Diccionario de datos tabla rol .................................................................... 42

Tabla 18. Diccionario de datos tabla perfil submódulo ............................................. 43

Tabla 19. Diccionario de datos tabla menú ................................................................ 44

Tabla 20. Diccionario de datos tabla módulo rol ....................................................... 44

Tabla 21. Diccionario de datos tabla Casa Salesiana ................................................. 45

Tabla 22. Diccionario de datos tablapaís ................................................................... 45

Tabla 23. Diccionario de datos tabla ciudad .............................................................. 46

Tabla 24. Diccionario de datos tabla persona ............................................................ 46

Tabla 25. Diccionario de datos tabla usuario ............................................................. 47

Tabla 26. Requerimientos de software ....................................................................... 67

Tabla 27. Características de equipo utilizado para realizar pruebas .......................... 70

ÍNDICE DE ANEXOS

Anexo 1. Manual de usuario (Usuario Administrador) ............................................. 79

Anexo 2. Manual de usuario (Usuario por casa salesiana) ........................................ 93

Anexo 3. Diagramas lógico y físico del módulo de Administración. ........................ 99

Anexo 4. Diccionario de datos del módulo de Administración ................................. 99

Anexo 5. Cambios realizados a la base de datos. ....................................................... 99

Anexo 6. Diccionario de datos del visualizador......................................................... 99

RESUMEN

Este producto está basado en el módulo de seguridad e integración de los módulos de

Gestión de datos, Gestión del visualizador, Gestión de estilos, Administración del

visualizador del Geoportal de la Comunidad Salesiana a partir de su versión 1.0 para

incrementar requerimientos del usuario en estos módulos.

El presente documento contara de 5 capítulos que se detallan a continuación.

El capítulo 1 “Marco teórico” contiene información de la metodología OOHDM y

herramientas de desarrollo que se utilizará.

El capítulo 2 “Requerimientos del sistema” se obtendrá los requerimientos para el

sistema a desarrollar.

El capítulo 3 “Diseño” se parte del análisis de los requerimientos para crear los

diagramas de clases, base de datos, secuencia, entre otros que servirán como base

para la creación del sistema.

El capítulo 4 “Desarrollo” se empezará con la creación de la aplicación en base al

diseño.

El capítulo 5 “Implementación y pruebas” esta parte sirve de referencia en caso de

tener problemas al momento de realizar las pruebas para corregir y tener un sistema

confiable.

Por último tenemos las conclusiones, recomendaciones y anexos que se van

obteniendo a medida que se avanza en el desarrollo del sistema.

ABSTRACT

This product will be based on the security module and integration of data

management modules, management of the display, management styles, management

of the display of the Salesian community GEOPORTAL from version 1.0 to increase

user requirements in these modules.

This document count of 5 chapters below.

Chapter 1 "THEORETICAL" contains information on the OOHDM methodology

and development tools to be used.

Chapter 2 "SYSTEM REQUIREMENTS" requirements for the system to be

developed will be obtained.

Chapter 3 "DESIGN" is part of the requirements analysis to create class diagrams,

database, string, etc. that were the basis for the creation of the system.

Chapter 4 "DEVELOPMENT" will begin with the creation of the application based

on the design.

Chapter 5 "IMPLEMENTATION AND TESTING" This part serves as a reference in

case you have problems when testing to correct and maintain a reliable system.

Finally we have the conclusions and recommendations that are obtained as you

progress in the development of the system.

1

INTRODUCCIÓN

La expansión de casas y obras salesianas en todo el Ecuador ha sido muy grande, lo

cual requiere un mejor conocimiento de las actividades que se realizan en cada una

de ellas. El Geoportal de la Comunidad Salesiana es un sistema web que brinda

información sobre los servicios entregados, conjuntamente con su grado de

influencia benéfica.

Información que necesita ser respaldado por un módulo de seguridad con el fin de

establecer un sistema centralizado que permita el control y la administración de

usuarios y recursos al sistema.

Para ello se analizó, desarrolló e implementó un sistema de seguridad bajo entorno

web, orientado a la administración y definición de roles y perfiles de usuarios, con lo

cual se quiere controlar y limitar la utilización de recursos para la administración de

los módulos que comprende el Geoportal de la Comunidad Salesiana.

El sistema está enfocado directamente a la gestión de los principios de seguridad

como son: autorización, autenticación y auditoria de accesos las cuales permitirán al

usuario conocer quién administrara los recursos del Geoportal y de los eventos o

alteraciones en la información que se pudiera realizar sobre los módulos que forman

parte de él.

2

CAPÍTULO 1

MARCO TEÓRICO

1.1 Objetivos

1.1.1 Objetivo general.

Analizar, diseñar y construir el módulo de seguridad e integrar los módulos

de visualización y gestión de datos geográficos del Geoportal de la

Comunidad Salesiana versión 2.0.

1.1.2 Objetivos específicos.

Recolectar y digitalizar información geográfica que será usada en

pruebas para el módulo de administración, con el fin de manipular datos

reales.

Generar reportes con información acerca de las obras, realizando

filtrados por parte de los usuarios.

Subir la aplicación al servidor del IDE UPS, y ponerlo al servicio de las

personas interesadas.

1.2 Alcance

El producto final permitirá satisfacer necesidades en la gestión de seguridad para el

acceso al geoportal y el resultado será un sistema totalmente integrado sobre una

misma plataforma, con requerimientos establecidos por la Inspectoría Salesiana, el

cual estará formado de los siguientes módulos.

Tabla 1. Módulos que forman parte del sistema integrado

Módulo Versión Desarrolladores

Gestión de datos Versión 1.0 Fabricio Mullo &Andrea Moya

Gestión del

visualizador

Versión 2.0 Víctor Cofre &Stalin Toledo

Gestión de estilos Versión 1.0 Gabriela Eras y Cristian Arcos

Administración Versión 1.0 Oswaldo Tutillo& Byron Sandoval

Seguridad Versión 1.0 Carina Torres & Darwin Aldas

Elaborado por: Carina Torres & Darwin Aldas

Módulo de gestión de datos

Mostrar las opciones o cajas de texto, a las cuales tendrán acceso el usuario

administrador y el usuario asignado por casa salesiana, para manipular la

información de acuerdo a las casas y obras salesianas.

3

Módulo de gestión del visualizador

Mostrar las opciones o cajas de texto, a las cuales tendrán acceso el usuario

administrador y el usuario asignado por casa salesiana, para manipular la

información de acuerdo a las casas y obras salesianas.

El usuario invitado podrá acceder al visualizador y realizar únicamente

consultas y búsquedas.

Módulo de gestión de estilos

Mostrar las opciones o cajas de texto, a las cuales tendrá acceso el usuario

administrador, para manipular los estilos que se dan por defecto al ingresar un

área de influencia correspondiente a una casa salesiana.

Módulo de administración


administrador, para manipular permisos a los submódulos a los cuales los

usuarios podrán acceder de acuerdo a las casas y obras salesianas a las que

pertenezcan.

Módulo de seguridad


administrador, para manipular a usuarios, perfiles, sesiones, y bitácora.

Se considerará aspectos que satisfagan necesidades en la administración y

accesos al geoportal como:

Autentificación

Mediante el cual se asignará y validará la identidad del usuario que manipula

el sistema, este proceso se realiza mediante el uso de cuentas de usuario y

contraseñas.

Autorización

En el cual se definirá los permisos de navegación web, lo que un usuario

podrá ver, hacer, modificar y acceder, a través de un rol y perfil.

4

Los roles de usuario que contemplará el sistema son:

Usuario administrador del geoportal (Súper usuario).

Usuario asignado por Casa Salesiana.

Usuario invitado.

Auditoria de accesos

Dentro del módulo de seguridad se dispondrá de un historial de transacciones para

conocer en un reporte quién y cuándo realizó transacciones cómo:

Actualización del registro.

Eliminación del registro.

Creación del registro.

1.3 Justificación

El auge de los geoportales a nivel mundial ha sido motivo de relevancia en éstos

últimos años, razón que implica la participación de empresas públicas y privadas en

la adquisición de este tipo de sistemas.

En nuestro caso la aplicación en general permitirá conocer las labores que realiza la

Comunidad Salesiana en nuestro territorio ya que mostrará los diferentes lugares

donde actúan las obras salesianas brindando apoyo a la comunidad, y a la cual se

podrá acceder desde cualquier lugar y podrá ser administrada sin ningún

inconveniente.

El objetivo principal de la creación del módulo de seguridad es garantizar la

integridad de la información que se da a conocer en el geoportal, mediante el manejo

de roles y perfiles.

1.4 Marco teórico

El marco teórico como parte fundamental permite mostrar la información de los

elementos que serán utilizados en el presente producto.

1.4.1 Geoportal web.

El geoportal es un sitio web accesible a través de los navegadores estándar,

ofreciendo acceso a recursos y servicios basados en información geográfica.

5

Permiten el descubrimiento, acceso y visualización de los datos geoespaciales

que facilitan la integración, la interoperabilidad y el intercambio de

información entre las diferentes instituciones, ciudadanos y agentes sociales.

Actualmente, con la aparición de las infraestructuras de datos espaciales,

estos servicios han aumentado considerablemente su potencialidad, tanto por

los nuevos servicios que pueden incluir (desarrollos sobre WMS, WFS, WCS,

Catálogos) como por la posibilidad de ser invocados tanto desde el portal

propio como desde otros externos. (AMHON, 2012).

1.4.2 Metodología OOHDM

Método de diseño de hipermedia orientado a objetos, es una metodología de

desarrollo propuesta por Rossi y Schwabe para la elaboración de aplicaciones

multimedia que tiene como objetivo simplificar y a la vez hacer más eficaz el

diseño de aplicaciones hipermedia.

OOHDM propone el desarrollo de aplicaciones hipermedia a través de un

proceso compuesto por 5 etapas: (Silva & Mercerat, 2002).

Obtención de requerimientos

La herramienta en la cual se fundamenta esta fase son los diagramas de casos de uso,

los cuales son diseñados por escenarios con la finalidad de obtener de manera clara

los requerimientos y acciones del sistema.

Identificación de roles y tareas

En esta etapa se van a identificar los diferentes roles para que el software pueda ser

utilizado de acuerdo a las tareas que cada usuario necesite.

Figura 1. Fases de la metodología OOHDM Fuente: (Silva & Mercerat, 2002).

Elaborado por: Carina Torres y Darwin Aldas

Obtencion de Requerimientos

Modelo Conceptual

Diseño Navegacional

Diseño de Interfaz Abstracta

Implementación

6

Especificación de escenarios

En esta etapa, cada usuario deberá especificar los escenarios que describen su tarea.

Especificación de casos de uso

En esta etapa se especificara la interacción entre el usuario y el sistema, agrupando

las tareas representadas en los escenarios existentes.

Diseño conceptual

Durante esta fase se crearán los diagramas de clases para que la implementación sea

sencilla y éstas aporten y optimicen a la funcionalidad que el geoportal necesite al

momento de ejecutarse

Diseño navegacional

Un modelo navegacional es construido como una vista sobre el diseño conceptual,

consta con un esquema de clases de navegación. El diseño de navegación es

expresado en dos esquemas: el esquema de clases y de contextos navegacionales.

En OOHDM hay una serie de clases que se conocen como clases navegacionales:

Nodos

Enlaces

Estructuras de acceso

Los menús

Los índices

Las guías de ruta

Diseño de interfaz abstracta

Cuando se define las interfaces de la aplicación se definirá como aparecerán los

objetos navegacionales y cuales activarán la navegación.

En OOHDM se utiliza el diseño de interfaz abstracta para describir la interfaz del

usuario de la aplicación de hipermedia.

Implementación

En esta fase los objetos serán puestos en un lenguaje de programación en nuestro

caso Java y para esto tendremos:

7

Productos: Aplicación ejecutable

Herramientas: Entorno del lenguaje de programación java

Mecanismos: Los ofrecidos por el lenguaje

Objetivo de diseño: Obtener la aplicación ejecutable (Silva & Mercerat, 2002).

1.4.3 Herramientas de desarrollo a utilizar.

Dentro de las etapas que se considerarán para la creación del módulo de

seguridad son:

Definición de un modelo relacional de base de datos que permita la integración entre

el módulo de seguridad con los módulos mencionados, sobre una misma plataforma.

Para el desarrollo del módulo web de seguridad se utilizará:

Tabla 2. Herramientas utilizadas para el desarrollo del módulo de seguridad

Patrón de arquitectura MVC (modelo, vista, controlador)

JSF(Java Server Faces) Versión 2.0

Primfaces Versión3.3

JDBC (Java DatabaseConectivity) Conector con la base de datos

Apache Tomcat Versión 7.5.0

PostgreSQL Versión 9.1

Postgis Versión 1.5


JSF

La tecnología JavaServer Faces establece el estándar para la creación de interfaces de

usuario del lado del servidor, que muestra cómo crear un componente de interfaz de

usuario compuesta y utilizarlo en una aplicación web (The Apache Software

Foundation , 2014).

Primfaces

Es una librería de componentes visuales para trabajar con JavaServerFaces (JSF) de

código abierto que cuenta con gran cantidad de componentes que facilitan la creación

de las aplicaciones web. Es de código abierto y tiene licencia de Apache License V2,

utiliza JQuery para los efectos visuales (Oracle, 2014).

8

Apache Tomcat

Esuna implementación de código abierto de software de las tecnologías Java Servlet

y JavaServerPages. Apache Tomcat está destinado a ser una colaboración de los

desarrolladores para un mejor desenvolvimiento en sus tareas (The Apache Software

Foundation , 2014).

PostgreSQL 9

Es un sistema de gestión de base de datos relacional orientada a objetos y libre,

publicado bajo la licencia BSD. Ofrece características como alta concurrencia y

amplia variedad de tipos nativos (PostgreSQL, PostgreSQL, 2013).

PostGIS 1.5

Es una extensión del sistema de base de datos de objetos relacionales PostgreSQL

que gestiona GIS (Geographic Information Systems), a través de su almacenamiento

en la base de datos. Permite importar y exportar datos a través de varias herramientas

conversoras (Oracle, 2014).

Quantum GIS (QGIS) 1.8

QGIS es un sistema de información geográfica multiplataforma con una comunidad

de apoyo internacional de entusiasmados usuarios, desarrolladores y colaboradores.

La arquitectura de módulos de QGIS permite añadir fácilmente muchas nuevas

características/funcionalidades a la aplicación (Foundation O. S., 2013).

Las principales características son:

Crea, edita, visualiza, analiza y publica información geoespacial, ya sea para

Windows, Mac, Linux, BSD y Android.

Navega y pre visualiza datos y metadatos.

Herramientas de Análisis Espacial.

Importación y exportación de datos GPS (GIS, 2013).

Netbeans 7.1

Netbeans es un IDE que permite desarrollo de aplicación java de escritorio, web,

móvil, etc. de manera más rápida ya que cuenta con un gran número de librerías,

plantillas, consejos y herramientas para facilitar el desarrollo de software aplicativo.

Es gratuito, de código abierto además soporta muchos lenguaje como Java, C / C + +,

XML y HTML, PHP, JavaScript y JSP (Tello, 2013).

9

1.4.4. Tipo de Arquitectura.

Para el desarrollo de éste proyecto se utilizará una arquitectura en 3 capas que

permitirá la separación de la lógica de negocios de la lógica de diseño, un ejemplo

básico de esto es separar la capa de datos de la capa de presentación al usuario.

Las capas que serán utilizadas son:

Capa de presentación o Interfaz de usuario

Presentará el sistema y le comunicará la información al usuario. Esta capa se

comunica únicamente con la capa de negocio. Es importante recalcar que las

interfaces a las que el usuario accederá serán páginas web JSF.

Capa de negocio

Es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se

comunicará con la capa de presentación, recibirá las solicitudes dadas por el usuario

y presentará los resultados, y con la capa de datos solicitará al gestor de base de datos

peticiones para almacenar o recuperar datos de él.

Capa de datos

Está formada por el gestor de bases de datos que en nuestro caso será PostgreSQL

9.1 y su complemento de datos geográficos PostGIS 1.5 que realiza todo el

almacenamiento de datos, recibirá solicitudes de almacenamiento o recuperación de

información desde la capa de negocio, que posteriormente será mostrada al usuario.

Figura 2.Arquitectura en tres capas


10

CAPÍTULO 2

REQUERIMIENTOS DEL SISTEMA

Los requerimientos de los módulos de seguridad del proyecto del Geoportal de la

Comunidad Salesiana son tener acceso a las páginas que tiene el proyecto y realizar

actividades de acuerdo al rol y perfil que se asignará a cada usuario, conservando

siempre la integridad de los datos que el mismo contiene.

2.1 Definición de roles (actores) y tareas y casos de uso de negocio

Caso de uso:

Un caso de uso representa una unidad funcional coherente de un sistema, subsistema

o clase.

En un caso de uso uno o más actores interaccionan con el sistema que realiza algunas

acciones.

Elementos de un modelo de casos de uso:

Actores

Casos de uso

Relaciones

Actor:

Los actores representan papeles (ROLES) que interpretan personas, periféricos u

otros sistemas cuando el sistema está en uso (Tello, 2013).

Los actores y tareas serán implementados por el módulo de seguridad se los describe

a continuación, para el manejo del sistema integrado.

Tabla3. Descripción de actores del sistema

Roles Tareas

Administrador Usuario encargado de la administración del sistema.

Nota: el usuario administrador podrá tener acceso a todos los módulos

del sistema para el ingreso, actualización, visualización o eliminación de

información.

Editor Datos por

Casa Salesiana

Usuario encargado de la administración de la información consolidada

de las casas y las obras salesianas que le pertenecen.

Invitado Usuario que podrá acceder únicamente al módulo del visualizador y

hacer consultas dentro de él.

Consultas: por categorías, temática, obra, casa-obra, casa-tipo-obra.


11

Tabla 4. Descripción de casos de uso del sistema

Roles Tareas

Administración de

información del módulo de

seguridad

El administrador puede ingresar, consultar, actualizar y eliminar

información de todos los módulos que forman el sistema.

Edición de información del

módulo de gestión de datos

El Editor Datos por Casa Salesiana se encargará de editar los datos

de acuerdo a la Casa y Obra Salesiana a la que pertenezca.

Consultar al módulo del

visualizador.

El invitado podrá acceder únicamente al visualizador y hacer

consultas dentro de él.


2.2 Priorización escenarios y casos de uso de negocio

Para la administración de la información del módulo de seguridad se presentan los

siguientes casos de uso en los que se describirá la información del módulo, como es

el proceso de auditoría de transacciones, cambio de contraseñas.

Tabla 5. Descripción de casos de uso en el módulo de seguridad

Escenario(Caso de uso) Descripción

Auditoría de transacciones

realizadas por el usuario

registrado.

El administrador puede realizar auditorías (consultas) de las

transacciones realizadas por el usuario dentro del geoportal

mediante filtros como: fechas las cuales pueden ser

desplegadas en reportes.

Cambio de contraseña Todos los usuarios pueden realizar el cambio de contraseña a

través de la pantalla de configuración al iniciar sesión.

Administración de menús por

pantallas

El administrador puede ingresar, consultar, actualizar y

eliminar información de menús por cada pantalla en el

módulo de seguridad.

Administración de usuarios El administrador puede ingresar, consultar, actualizar y

eliminar información de los usuarios a través del módulo de

seguridad.

Administración de roles El administrador puede ingresar, consultar, actualizar y

eliminar información de los roles a través del módulo de

seguridad.

Administración de módulos por

rol.

El administrador puede ingresar, consultar, actualizar y

eliminar información de módulos por rol a través del módulo

de seguridad.


12

2.3 Especificación de casos de uso de negocio

Los casos de uso permiten identificar la interacción entre los usuarios y cada uno de

los procesos de la aplicación. Se describe a detalle cada caso de uso en la que se

analizará el orden de sucesos, es decir su inicio, fin e interacción de los actores

dentro de cada escenario en el sistema.

En el caso de uso presentado a continuación se detalla como el usuario administrador

opera el sistema para obtener la información de auditoría que conforma la bitácora de

transacciones generadas dentro del sistema.

Tabla 6. Casos de uso de auditoría

Nombre de caso

de uso

Auditoría de transacciones realizadas por el usuario administrador en el

sistema

Actores Usuario Administrador

Camino

Principal

Ingresar al sistema

Ingresar usuario y contraseña

Consultar información de procesos mediante filtros de búsqueda.

Enviar registro de transacciones

Generar reporte.

Camino

secundario

2.1. Datos del usuario administrador son incorrectos

2.1.1. Enviar notificación de datos erróneos.

3.1. Registros no encontrados de acuerdo a filtros de búsqueda.

3.1.1 Enviar notificación de datos no encontrados.

Precondiciones El usuario deber estar registrado en el portal

Pos condiciones Interacción y validación de información entre portal y BDD.

Informe de auditoría de procesos.


13

En el siguiente caso de uso se detalla como el Administrador, Editor de datos por

Casa Salesiana, operan en el sistema para realizar el cambio de su contraseña.

Figura 3. Caso de uso de auditoría


14

Tabla 7. Casos de uso: Ingreso visual de la ubicación del lugar

Nombre de caso de uso Cambio de contraseña


Usuario Editor Datos por Casa Salesiana

Camino Principal

Usuarios Administrador,

Editor Datos, Editor GIS

Ingresar al sistema


Escoger cambio de contraseña

Ingresar y confirmar nueva contraseña.

Enviar confirmación de contraseña.

Camino secundario 2.1. Datos de usuario incorrectos.

2.1.1. Enviar notificación de datos incorrectos.

4.1 Nueva contraseña y confirmación son diferentes.

4.1.1. Enviar notificación de que la nueva contraseña y su

confirmación son diferentes.


Postcondiciones Interacción y validación de información entre portal y BDD.

Envío de confirmación de cambio de contraseña.


Figura 4.Caso de uso: Cambio de contraseña


15

En los siguientes casos de uso, descritos en las tablas 8 y 9, se detalla como el

administrador operará el sistema para realizar la gestión de información de módulos

respectivamente que contempla el Geoportal de la Comunidad Salesiana.

Tabla 8. Casos de uso administración de perfiles

Nombre de caso de

uso

Administración de perfiles


Camino Principal

Usuarios

Administrador

Ingresar al sistema


Visualizar información

Ingresar información.

Enviar confirmación de inserción.

Editar información.

Enviar mensaje de actualización de datos.

Eliminar información

Enviar confirmación de eliminación.



4.1 Tipo de datos erróneos.

4.1.1. Enviar notificación de tipo de datos erróneos.

5.1. Enviar notificación de error de inserción.

7.1. Enviar notificación de error de actualización.

9.1. Enviar notificación de error de eliminación.



Envío de notificación de inserción, actualización y/o eliminación.


16

Figura 5.Caso de uso: Administración de perfiles


17

Tabla 9. Casos de uso: Administración de módulos

Nombre de caso de uso Administración de módulos


Camino Principal

Usuarios Administrador

Ingresar al sistema




















18

Los casos de uso descritos en las tablas 10 y 11 detallan como el administrador opera

el sistema para realizar la gestión de los menús por pantallas y usuarios.

Figura 6. Caso de uso: Administración de módulos


19

Tabla 10. Caso de uso: Administración de menús por pantalla

Nombre de caso de uso Administración de menús por pantalla


Camino Principal

Usuarios

Administrador

Ingresar al sistema




















Figura 7. Caso de uso: Administración de menús por pantalla


20

Tabla 11. Caso de uso: Administración de usuarios

Nombre de caso de uso Administración de usuarios


Camino Principal


Ingresar al sistema




















Figura 8.Caso de uso: Administración de usuarios


21

El siguiente caso de uso detalla como el administrador opera el sistema, para realizar

la gestión de información de roles.

Tabla 12. Caso de uso: Administración de roles

Nombre de caso de uso Administración de roles


Camino Principal


Ingresar al sistema




















Figura 9. Caso de uso: Administración de roles


22

En el siguiente caso de uso detalla como el administrador opera en el sistema, para

realizar la gestión de información de los módulos asignados para cada rol.

Tabla 13. Caso de uso: Administración de módulos por rol

Nombre de caso de uso Administración de módulos por rol


Camino Principal


Ingresar al sistema




















Figura 10. Caso de uso: Administración de módulos por rol


23

2.4. Diagramas de secuencia

En un diagrama de secuencia se indicarán los módulos o clases que forman parte del

programa y las llamadas que se hacen en cada uno de ellos para realizar una tarea

determinada.

Se realizan diagramas de secuencia para definir acciones que se pueden realizar en la

aplicación en cuestión (Tello, 2013).

Para la auditoría de transacciones en el sistema se presenta el siguiente diagrama de

secuencia en el que se describe el proceso a seguir para obtener la información de

auditoría de procesos dentro del geoportal.

Figura 11. Diagrama de secuencia: Auditoría de transacciones en el

sistema


24

A continuación se detalla el diagrama de secuencia que nos indica el proceso a seguir

para el cambio de contraseña.

.

Figura 12. Diagrama de secuencia: Cambio de contraseña


25

Para la administración de perfiles se presenta el siguiente diagrama de secuencia, en

el que se describe el proceso a seguir para la gestión de los perfiles.

Figura 13. Diagrama de secuencia: Administración de perfiles


26

Para la administración de información de los módulos se presenta el siguiente

diagrama de secuencia, describe el proceso a seguir para la gestión de información de

los módulos.

Figura 14. Diagrama de secuencia: Administración de módulos


27

Para la administración de información de los usuarios se presenta el siguiente

diagrama de secuencia, en el que se describe el proceso a seguir para la gestión de

información de usuarios.

Figura 15. Diagrama de secuencia: Administración de usuarios


28

CAPÍTULO 3

DISEÑO DE LA ARQUITECTURA

El módulo de seguridad del Geoportal de la Comunidad Salesiana, permitirá la

administración de usuarios, creación de roles y perfiles que tendrá un único control

de autenticación, autorización de accesos de manera centralizada dentro del

geoportal, como lo muestra la siguiente figura.

Figura16. Módulo de seguridad


SEGURIDAD FIABILIDAD

ASPECTOS CONFIDENCIALIDAD

INTEGRIDAD

DISPONIBILIDAD

ELEMENTOS

HARDWARE

SOFTWARE

DATOS

AMENAZAS

INTERRUPCIÓN

MODIFICACIÓN

CREACIÓN

PERSONAS

AMENAZAS LÓGICAS

CATÁSTROFES

MECANISMOS

PREVENCIÓN

DETECCIÓN

RECUPERACIÓN

29

Éste módulo dispone de una sistema de gestión de perfiles y credenciales con los

cuales se podrá establecer políticas de navegación en el geoportal, permitiendo el

acceso a los recursos necesarios del sistema que se definen de acuerdo a la credencial

proporcionada al usuario.

Figura 17. Módulo de seguridad para el geoportal


Figura 18. Diseño lógico del módulo de seguridad


Persona Módulo de Seguridad

Usuarios Perfil

Interfaz 1

Interfaz 2

Interfaz 3

30

Se define una administración de usuarios de la siguiente manera.

Cada usuario será relacionado a un perfil, para que pueda desempeñarse de acuerdo a

su rol al interactuar en el sistema.

De acuerdo a los permisos que se otorguen al perfil del usuario, el mismo tendrá la

capacidad de realizar transacciones y operar el sistema.

El módulo de seguridad describe los principales componentes como:

Servicio de gestión de usuarios: Realiza la función de gestión de usuarios (consulta,

modificación, eliminación).

Servicio de autorización: Realiza la función de autorización a la aplicación en base

a perfiles autorizados.

Servicio de autenticación: Permite la autenticación de usuario y contraseña.

Entidades comunes: interfaces que interactúan con el usuario que permitirán la

administración de los módulos.

Aplicaciones: Cada uno de los módulos que forman el sistema son distintas

aplicaciones que funcionan de manera cliente servidor y se encuentran integradas de

tal manera que forman un sistema centralizado.

Figura 19. Principales roles de administración para el geoportal


Ro

l

Invitado

Editor de datos por Casa Salesiana

Administrador Geoportal

31

3.1 Diseño conceptual

El esquema conceptual es la representación de las clases, con sus respectivas relaciones y colaboraciones que el sistema correspondiente a la Comunidad Salesiana en su versión2.0 contendrá, las clases en el

proyecto interactuarán como entidades.

Figura 20. Diseño conceptual módulo: Administración de seguridad Diagrama creado con herramienta Navicat.


Éste es el diseño conceptual que se

maneja actualmente para la

administración del sistema integrado,

está basado del diseño que fue

modificado por Byron Sandoval y

Oswaldo Tutillo, basado en una versión

anterior el cual se encuentra como

Anexo 3, Anexo 4 y Anexo 5, los cuales

indican los cambios que se realizaron.

32

3.2 Diseño navegacional

Figura 21. Diseño navegacional: Módulo de administración de seguridad

Diagrama creado con herramienta Navicat.


33

3.3 Diseño de interfaz abstracta (Prototipo de interfaz de usuario)

ADV son interfaces compuestas con elementos que interactuará y visualizará el

usuario, las mismas que por ser dinámicas y versátiles permitirá el modelamiento.

Pantalla de inicio (Figura 22)

El usuario al acceder al sistema será autenticado mediante la interfaz de inicio donde

se solicitará la información de credencial como muestra la siguiente figura.

Menú del Sistema (Figura 23)

Una vez autenticado el usuario tendrá acceso a un menú de acuerdo al rol y perfil

asignado dentro del sistema.

Figura 22.ADV’s Pantalla inicio y autenticación Elaborado por: Carina Torres & Darwin Aldas

Figura 23.ADV’s Pantalla de elementos del menú del sistema


34

Administración del módulo de seguridad (Figura 24)

La administración de información del módulo de seguridad, es la interfaz en la cual

el usuario administrador podrá insertar, actualizar y/o eliminar información.

Edición e inserción de registros (Figura 25)

Para la edición e inserción de nuevos registros se utilizará una ventana dónde la

información será gestionada de la siguiente manera.

Figura 25.ADV’s Pantalla inserción y edición de registros Elaborado por: Carina Torres & Darwin Aldas

Figura 24.ADV’s Pantalla de administración del módulo de

seguridad


35

Los prototipos de la interfaz presentada serán utilizados en todas las pantallas que

forman parte de la administración del módulo de seguridad.

Perfiles

Módulos

Pantallas

Usuarios

Roles

Módulos por rol.

Auditoría de transacciones en el sistema (Figura 26)

Esta pantalla permitirá la visualización de las transacciones realizadas por los

usuarios sobre el módulo de seguridad como: inserción, eliminación, actualización a

través del uso de filtros de búsqueda, o de manera generalizada.

3.4 Diagrama de clases

Los diagramas de clases indican las entidades, controladores y servicios que la

aplicación utilizara basado cada controlador en base a los ADVs y los servicios

según los requerimientos que cada controlador.

Figura 26.ADV’s Elementos de interfaz de auditoría


36

Diagrama de clases del gestor datos geográficos

Figura 27. Diagrama de clases del gestor datos geográficos

Fuente: (Cofre & Toledo, Análisis diseño y construcción del módulo del visualizador de la comunidad salesiana versión 2.0. (Tesis de pregrado), 2014)

Los diagramas de fondo azul son sacados del trabajo de titulación de Víctor Cofre y Stalin Toledo, y forman parte de la

base de datos del Sistema Integrado final, su diccionario de datos respectivo se encuentra como ANEXO 6.

37

Diagrama de clases del visualizador

Figura 28. Diagrama de clases del visualizador

Fuente: (Cofre & Toledo, Análisis diseño y construcción del módulo del visualizador de la comunidad salesiana versión 2.0. (Tesis de pregrado), 2014)

38

3.5 Diagrama de clases del módulo de seguridad

A partir de la figura 19 y los diagramas ADV´s se obtuvo el diagrama de clases definitivo.

Figura 29. Diagrama de clases del módulo de seguridad

Diagrama elaborado con herramienta UModel – Altova.


39

3.6 Modelo de la base de datos

El modelo lógico de la base de datos permite ver la estructura que se va a utilizar en el ingreso y consulta de la información de los usuarios a la información de las obras salesianas tanto para el módulo de

gestión de datos geográficos como para el visualizador.

Figura 30. Modelo lógico de la base de datos

Para generar este diagrama se utilizó la herramienta Power Designer.


40

El modelo físico define las relaciones y la estructura de almacenamiento que utilizara en la base de datos para tener un acceso rápido, ordenado y volviendo a la base de datos completamente eficiente.

Figura 31. Modelo físico de la base de datos

Para generar este diagrama se utilizó la herramienta Power Designer.


41

3.7 Diccionario de base de datos del módulo de seguridad

En esta sección se hace uso de tablas con la descripción de los campos con los que

cuenta la base de datos incluyendo información como el nombre de los campos, el

tipo de dato y la descripción de que información que se guardará.

Es importante recalcar que para la construcción del módulo de seguridad se tomaron

como guía tablas existentes anteriormente en la base de datos, se hicieron cambios y

se aumentaron campos de acuerdo a la necesidad que requiera el módulo, los cuales

se encuentran en el anexo 5.

La tabla Módulo contiene un conjunto de datos que representa las características que

deberá tener cada módulo que se almacena en el sistema.

Tabla 14. Diccionario de datos tabla módulo

Nombre tb_modulo

Descripción Almacena la información básica de los módulos

Primary Key id_modulo

Key ColumnName Data Type NotNull Descripción

PK id_modul Integer Yes Identifica al módulo al cual hace

referencia

nombre_modul Text Yes Nombre del módulo

imagen_modul Text Yes Imagen con que se identificará el

módulo.

orden_modul Text Yes Orden en el que será visualizado el

módulo.

estado_modul boolean No Estado en el que se encuentra el

módulo (true o false).


La tabla Submódulo contiene un conjunto de datos que representa las diferentes

páginas a las que el usuario tendrá acceso.

42

Tabla 15.Diccionario de datos tabla Submódulo

Nombre tb_submodulo

Descripción Almacena la información básica del submódulo

Primary

Key

id_submod


PK id_submod Serial Yes Identificación única del tipo de

submenú.

nombre_submod Text Yes Nombre del submódulo

icono_submod Text Yes Se especifica el directorio en el cual

se guardaran los iconos disponibles

para los submódulos.

archivo_submod text Yes Directorio dónde se encuentra la

página.

orden_submod text Yes Orden en el que será visualizado el

submódulo dentro de un módulo.

estado_submod boolean No Almacenará un true o false


La tabla Permiso contiene un conjunto de datos que definirá un determinado permiso.

Tabla 16.Diccionario de datos tabla Permiso

Nombre tb_permiso

Descripción Almacena la información de los permisos que tendrá cada submódulo de acuerdo al

rol que tenga.

Primary

Key

id_permiso


PK id_permiso serial Yes Identificador único del lugar

FK id_rolinteger integer Yes Representa al indicador del rol

FK id_submod integer Yes Representa al indicador del

submódulo.

ver_permiso boolean No Almacenará un true o false

editar_permiso boolean No Almacenará un true o false

eliminar_permiso boolean No Almacenará un true o false

generar_permiso boolean No Almacenará un true o false

importar_permiso boolean No Almacenará un true o false

exportar_permiso boolean No Almacenará un true o false

estado_permiso boolean No Almacenará un true o false


43

La tabla Rol contiene un conjunto de datos que definirá un rol.

Tabla 17.Diccionario de datos tabla Rol


La tabla Perfil submódulo contiene un conjunto de datos que especifica el submódulo

de acuerdo al rol.

Tabla 18. Diccionario de datos tabla Perfil submódulo

Nombre tb_perfil_tb_submodulo

Descripción Almacena la información básica del submódulo de acuerdo al rol.


FK id_rol integer Yes Representa al indicador del rol.

FK id_submod integer Yes Representa al indicador del

submódulo.


La tabla Menú contiene un conjunto de datos del que contendrá el sistema.

Tabla 19.Diccionario de datos tabla Menú

Nombre tb_menu

Descripción Almacena la información del menú.

Primary Key id_menu


PK tb_menu serial Yes Identificación única del menú.

descripcion_menu text Yes Es la descripción o nombre del

menú.


La tabla Módulo rol contiene un conjunto de datos que definirá los módulos que

formarán parte del menú de acuerdo al rol.

Nombre tb_rol

Descripción Almacena la información de los roles

Primary

Key

id_rol


PK id_rol serial Yes Identificador único del rol al

cual hace referencia

nombre_rol text Yes Es el nombre del rol.

descripcion_rol text Yes Descripción del rol.

estado_rol boolean Yes Almacenará un true o false

44

Tabla 20.Diccionario de datos tabla Módulo rol

Nombre tb_modulorol

Descripción Almacena la información de los diferentes módulos que forman parte del

menú.


FK id_modul integer Yes Representa al indicador del

módulo.

FK id_rol integer Yes Representa al indicador del rol.

FK id_menu integer Yes Representa al indicador del

menú. Elaborado por: Carina Torres & Darwin Aldas

La tabla Casa Salesiana contiene un conjunto de datos que representa las

características que deberá tener cada casa que almacena el sistema.

Tabla 21.Diccionario de datos tabla Casa Salesiana

Nombre tb_casasalesiana

Descripción Almacena la información básica de las Casas Salesianas

Primary Key id_cas


PK id_cas serial Yes Identifica a la casa a la cual hace

referencia

nombre_cas text Yes Nombre de la casa salesiana

direccion_cas text Yes Dirección o ubicación de la casa

salesiana.

telefono_cas text No Teléfono de la casa salesiana.

correo_cas text Yes Correo de la casa salesiana

director_cas text Yes Director o persona responsable de

la casa salesiana.

pathicono_cas text Yes Es el directorio o path donde se

encuentran almacenados todos los

iconos disponibles para las casas

salesianas.

nombrecorto_cas text Yes Es una abreviación del nombre de

la casa salesiana por motivo de

diseño de interfaz.

estado_cas boolean No Almacenará un true o false


La tabla País contiene un conjunto de datos que definirá a que país pertenecen las

Casas Salesianas.

45

Tabla 22.Diccionario de datos tabla País

Nombre tb_pais

Descripción Almacena la información de los diferentes módulos que forman parte del menú.

Primary Key id_pais


FK id_pais integer Yes Representa al indicador del país.

descripción_pais text Yes Representa el nombre o

descripción del país.


La tabla Ciudad contiene un conjunto de datos que definirá a que ciudad pertenecen

las Casas Salesianas.

Tabla 23.Diccionario de datos tabla Ciudad

Nombre tb_ciudad

Descripción Almacena la información de los diferentes módulos que forman parte del menú.

Primary Key id_ciudad


PK id_ciu serial Yes Representa al indicador de la ciudad.

FK Id_pais integer Yes Representa al indicador del país.

descripción_ciu text Yes Representa el nombre o descripción

de la ciudad.


La tabla Persona contiene un conjunto de datos que especifica las credenciales del

usuario.

46

Tabla 24. Diccionario de datos tabla Persona

Nombre tb_persona

Descripción Almacena la información de las personas.

Primary

Key

id_per


PK id_per serial Yes Identificador único de la persona.

FK id_ciu integer Yes Representa al indicador de la

cuidad a la que pertenece la

persona.

apellido_per character Yes Apellidos de la persona.

nombre_per character Yes Nombres de la persona.

fechanac_per date Yes Fecha de nacimiento de la persona.

correo_per character Yes Correo personal de la persona.

telefono_per character Yes Teléfono personal de la persona

direccion_per character Yes Dirección personal de la persona

fax_per character Yes Fax de la persona

telefonotrab_per character Yes Teléfono del trabajo de la persona

direcciontrab_per character Yes Dirección del trabajo de la persona

fechacrea_per date Yes Fecha en la que se crea la persona.

fechamodif_per date Yes Fecha en la que se modifica a la

persona.

estado_persona boolean Yes Almacenará un true o false

FK id_cas integer Yes Representa al indicador de la casa

salesiana a la que pertenece la

persona.


La tabla Usuario contiene un conjunto de datos que especifica las credenciales del

usuario.

47

Tabla 25.Diccionario de datos tabla Usuario

Nombre tb_usuario

Descripción Almacena la información de las credenciales del usuario.

Primary Key id_usu


PK id_usu serial Yes Identificador único del

beneficiario

FK id_per integer Yes Representa al indicador del

estilo del beneficiario

usuario_usu character Yes Es una pequeña descripción

del usuario.

contrasenia_usu character Yes Contraseña que se le asigna

al usuario.

fechacrea_usu date Yes Fecha en la que se crea el

usuario.

fechamodif_usu date Yes Fecha en la que se modifica el

usuario.

fecmodifcontras_usu date Yes Fecha en la que se modifica la

contraseña del usuario.


3.8 Diagrama de componentes

Un diagrama de componentes permite visualizar con facilidad la estructura general y

el comportamiento del sistema y del servicio que estos componentes proporcionan y

utilizan a través de las interfaces. (Msdn, 2014)

Para el módulo de seguridad se ha usado el siguiente diagrama de componentes, el

cual está formado por elementos que proporcionan un buen funcionamiento y acceso

al sistema, contiene base de datos, librerías e interfaces de acceso.

Figura 32.Diagrama de componentes del módulo de seguridad


48

3.9 Diagrama de despliegue

Un diagrama de despliegue modela la arquitectura en tiempo de ejecución de un

sistema. Esto muestra la configuración de los elementos de hardware (nodos) y

muestra como los elementos y artefactos de software se trazan en esos nodos.

(sparxsystems, 2013)

Nodo.

Un nodo es un elemento de hardware o software. (sparxsystems, 2013)

Artefacto.

Un artefacto es un producto del proceso de desarrollo de software, que puede incluir

los modelos del proceso archivo fuente, ejecutables, documentos de diseño, reportes

de prueba, prototipos, manuales de usuario y más. (sparxsystems, 2013)

Figura 33.Diagrama de despliegue del sistema


49

CAPÍTULO 4

DESARROLLO

Durante esta etapa se desarrolla el código del sistema, el cuál contendrá las partes

importantes del código que se crea conveniente explicar.

4.1 Funciones del módulo de seguridad

1. Permite manejar el uso de sesiones pues de esta manera se controla el acceso

al Geoportal Salesiano.

2. Controla el acceso a los paths de los diferentes submódulos que contiene el

sistema, ya que un usuario común no podrá acceder a las páginas que maneja

el administrador pegando la URL en un navegador.

3. Permite administrar usuarios, roles, perfiles y contraseñas.

4. Permite obtener una auditoria de todas las transacciones que se han realizado

en el sistema, ya sean de ingreso de datos, edición o eliminación.

5. Ayuda a controlar de manera general la integridad de la información dentro

del portal.

4.2 Integración del sistema

El proceso de integración que se ha llevado a cabo en el Geoportal Salesiano consiste

en realizar la unión de tres trabajos de titulación que trabajan con una misma base de

datos en común.

Este trabajo de titulación está basado en 10 trabajos que fueron elaborados

anteriormente.

Los proyectos a integrarse son los siguientes:

1. prjModuloAdministracion

Función: Contiene la administración y parte de la seguridad usado en la gestión del

portal.

2. ProyectoTesisUps

Función: Contiene información de todos los datos geográficos mostrados en un

visualizador de mapas con polígonos y puntos geo referenciados.

3. TesisP

Función: Realiza la gestión de la información de todos los datos referentes a casas

salesiana, obras salesianas, lugares etc.

50

Para obtener un sólo sistema integrado, se siguieron varios pasos los cuales serán

detallados en las siguientes etapas.

Etapas de integración del sistema

Etapa 1

I. Restauración de proyectos en un solo IDE

Es importante destacar que la unificación de proyectos conlleva el uso de una sola

herramienta para su óptimo desarrollo, por tal motivo se ha decidido hacer uso de

Netbeans (Entorno de desarrollo) como plataforma de trabajo.

Figura 35. Proyectos restaurados en un solo IDE


Figura 34. Proyectos restaurados en un solo IDE, Etapas


51

Etapa 2

I. Integración de clases, paquetes, librerías y archivos .xhtml en un solo

proyecto

En este proceso se realizó la unificación de clases, archivos .xhtml, paquetes y

librerías en un solo proyecto, cabe recalcar que en este proceso se crearon nuevos

paquetes con nombres referentes a las trabajos de titulación que se están integrando

ejemplo paquetes con el nombre: modGesInf llevan estas iniciales debido a que

hacen referencia al proyecto gestión de información, los paquetes que inician con los

nombres modVisPostgisUps, hacen referencia al proyecto que contiene el

visualizador, para organizar de mejor manera los archivos correspondientes a la

interfaz gráfica, es decir aquellos que tienen extensión.xhtml fueron distribuidos en

su mayoría en carpetas que permiten reconocer a que módulo pertenecen tal como

muestran las figuras 36 y 37.

Figura 36. Integración de los archivos

correspondientes a capa interfaz


Figura 37. Integración de los paquetes y

clases de cada uno de los proyectos


52

Etapa 3

II. Detección de errores y corrección de los mismos

En la realización de las etapas 1 y 2 se presenta la aparición de varios errores los

cuales se fueron corrigiendo dependiendo a la necesidad, entre los más comunes se

tienen: importación de paquetes, instancia de las clases con su respectivo paquete e

importación de las librerías adecuadas.

En la figura 39 se puede apreciar la importación de las librerías correspondientes a

cada uno de los trabajo de titulación, cabe recalcar que cada aplicación está

conformada por un determinado número de librerías las cuales al integrarse en un

solo proyecto estas también deben ser unificadas.

Figura 38. Ejemplo de importación de paquetes con el nombre correcto Elaborado por: Carina Torres & Darwin Aldas

53

Figura 39. Unificación de librerías Elaborado por: Carina Torres y Darwin Aldas

54

Una vez realizado el proceso de unificación de clases, paquetes y librerías

conjuntamente con la revisión y corrección de errores se tendrá un solo proyecto el

cual tiene como nombre: S.I.Salesiano, (Sistema Integrado Salesiano), la figura 40

refleja la integración del sistema en uno solo.

Etapa 4

III. Seguridad, conexión y comunicación entre cada uno de los módulos

IV.I. Seguridad

Para la implementación de la seguridad se realizó la creación de un filtro que

permite acceder a una determinada página siempre y cuando el usuario haya

iniciado sesión, caso contrario no se puede acceder a ninguna página del

sistema, esta clase está ubicada en el paquete filtros dentro de la clase

LoginFilter.

La figura 39 muestra la ubicación de la clase que actúa como filtro en el sistema, su

función principal es realizar por medio del login una consulta a la base de datos que

retorne todos los paths correspondientes a cada submódulo esto permite hacer un

barrido de todas las páginas que el usuario puede ver.

Figura 40. Sistema Integrado Salesiano Elaborado por: Carina Torres & Darwin Aldas

55

Figura 41. Clase LoginFilter Elaborado por: Carina Torres & Darwin Aldas

56

Métodos que definen la clase LoginFilter:

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException,

ServletException {

HttpServletRequestreq = (HttpServletRequest) request;

HttpServletResponse res = (HttpServletResponse) response;

// Obtengo el bean que representa el usuario desde el scope sesión

LoginBeanloginBean = (LoginBean) req.getSession().getAttribute("loginBean");

System.out.println("ESTE SI ES-----------------" + loginBean);

// Proceso la URL que está requiriendo el cliente

String urlStr = req.getRequestURL().toString().toLowerCase();

booleannoProteger = noProteger(urlStr);

System.out.println(urlStr + " - desprotegido=[" + noProteger + "]");

// Si no requiere protección continuo normalmente.

if (noProteger(urlStr)) {

chain.doFilter(request, response);

return;

}

// El usuario no estalogueado

if (loginBean == null || !loginBean.estaLogeado()) {

res.sendRedirect(req.getContextPath() + "/index.jsf");

return;

}

// El recurso requiere protección, pero el usuario ya está logueado.

chain.doFilter(request, response);

}

/**

* Este método evalúa cada una de las peticiones de páginas que realiza el usuario y si esta en la lista de las

permitidas las

* muestra. Tambien es necesario incluir los archivos como imágenes que se necesiten. Se planea la revisión para

que

* estos archivos sean cargados desde un archivo que no necesite compilación.

*/

private booleannoProteger(String urlStr) {

/*

* Este es un buen lugar para colocar y programar todos los patrones que creamos convenientes para determinar

cuáles

* de los recursos no requieren protección. Sin duda que habrá que crear un mecanismo tal que se obtengan de un

* archivo de configuración o algo que no requiera compilación.

*/

if (urlStr.endsWith("index.jsf")

|| (urlStr.endsWith("templateprincipal1.jsf") || (urlStr.endsWith("header1.jsf") || (urlStr.endsWith("template.jsf") ||

(urlStr.endsWith("header.jsf") || (urlStr.endsWith("piepaginatesis.png") || (urlStr.endsWith("ima1.jpg") ||

(urlStr.endsWith("ima2.jpg") || (urlStr.endsWith("ima3.jpg") || (urlStr.endsWith("ima4.jpg") ||

(urlStr.endsWith("bannertesis.png") || (urlStr.endsWith("fondo.jpg") || (urlStr.endsWith("busquedaporcategorias.jsf") ||

(urlStr.endsWith("templateprincipal.xhtml") || (urlStr.endsWith("textura-papel.jpg")

|| (urlStr.endsWith("busquedatematica.jsf") || (urlStr.endsWith("principal.jsf") ||

(urlStr.endsWith("busquedaporcasaobra.jsf") || (urlStr.endsWith("arbolcasatipoobra.jsf") ||

(urlStr.endsWith("templateprincipal.jsf") || (urlStr.endsWith("header.jsf") || (urlStr.endsWith("cssalesiana.png")

|| (urlStr.endsWith("header1.jsf")

//Desprotegiendo las pantallas para el gestor de estilos, ya que se distoriona el menuen caso de hacer ue se

genere de forma dinamica

|| (urlStr.endsWith("asignarestilolugar.jsf") || (urlStr.endsWith("asignarestilobeneficiario.jsf")

|| (urlStr.endsWith("gestionestilolugar.jsf") || (urlStr.endsWith("imagenes") || (urlStr.endsWith("hospital.png")

|| (urlStr.endsWith("gestionestilobeneficiario.jsf") || (urlStr.endsWith("homedatoseg.jsf")

|| (urlStr.endsWith("headereg.jsf") || (urlStr.endsWith("alerta.png") || (urlStr.endsWith("gestiondatos")

|| (urlStr.endsWith("templateprincipaleg.jsf") || (urlStr.endsWith("asignacoordmanual.jsf")

|| (urlStr.endsWith("administracion") || (urlStr.endsWith("menuprincipal.jsf"))))))))))))))))))))))))))))))))))))))

{

return true; }if (urlStr.indexOf("/javax.faces.resource/") != -1) {

return true;

}return false;

}

57

IV.II. Acceso al sistema: Para controlar el acceso al sistema se tiene el uso

de variables de sesión, las cuales se encargan de mantener cargados los

objetos correspondientes a un usuario logeado.

La clase creada para llevar a cabo esta función se denomina LoginBean y es la que

indica si el usuario que está ingresando al sistema consta en la base de datos y a que

submódulo puede acceder.

Figura 42. Clase LoginBean (clase que ayuda a validar el ingreso al sistema) Elaborado por: Carina Torres & Darwin Aldas

Métodos que definen la clase LoginBean:

private void initLoginBean() {

LOG.info("****Inside initLoginBean");

usuario = new Usuario();

control_md5 = new control_md5();

habilitaEstilosVisualizador = 0; }

public void login(ActionEventactionEvent) {

System.out.println("****************Inside Login Method int Login Bean!!!");

/*PERMITIR PASO POR EL FILTRO A USUARIO ACTIVO*/

habilitaEstilosVisualizador = 0;

nuevoRequestContext();

if (existeUsuario()) {

logeado = true;

cargaPermisosDeUsuario();

msg = new FacesMessage(FacesMessage.SEVERITY_INFO, "Bienvenid@", nombre);

} else {

logeado = false;

msg = new FacesMessage(FacesMessage.SEVERITY_WARN, "Login Error", "Credenciales no

válidas"); }

FacesContext.getCurrentInstance().addMessage(null, msg);

context.addCallbackParam("estaLogeado", logeado);

58

if (logeado) {

context.addCallbackParam("view", "administracion/HomeDatos.jsf");} }

//Integración este es un método para que se acceder al visualizador pasando por el filtro

public void loginUsuarioVisualizador(ActionEventactionEvent) {

System.out.println("****************Inside Login Method int Login Bean Visualizador!!!");

/*PERMITIR PASO POR EL FILTRO A USUARIO INVITADO*/

nombre = "invitado";

clave = "bgis";

nuevoRequestContext();

if (existeUsuario()) {


logeado = true;

msg = new FacesMessage(FacesMessage.SEVERITY_INFO, "Bienvenid@", "INVITADO");

} else {

logeado = false;

msg = new FacesMessage(FacesMessage.SEVERITY_WARN, "Login Error", "Credenciales no válidas");

}

FacesContext.getCurrentInstance().addMessage(null, msg); }

// Crea un nuevo usuario con los datos traídos desde el servicio usuario, para ser manipulado entre controlador

y View.

@SuppressWarnings("all")

private Usuario nuevoUsuario() {

// TODO Traer en la consulta los datos de persona asociados a el usuario

// para incluirse en los mensajes de ingreso y output de session.

try {

getControl_md5().md5(getClave());

usuario = ServicioUsuario.buscaUsuario(getNombre(), getControl_md5().md5(getClave()));

} catch (Exception e) {

System.out.println("Error en creacion de Nuevo Usuario: " + e.getMessage());

e.printStackTrace(); }

return usuario; }

/* Permite determinar si el usuario existe o no en la BBDD */

privatebooleanexisteUsuario() {

nuevoUsuario();

if (usuario != null&&usuario.getIdus() > 0) {

return true;

} else {

return false;}}

/* Crea instancia de RequestContext*/

privatevoidnuevoRequestContext() {

setContext(RequestContext.getCurrentInstance()); }

/* Metodo usado para destruir las instancias de los objetos en sesión */

public void logout() throws IOException {


LOG.info("*****Dentro de logout habilita= " + habilitaEstilosVisualizador);

FacesContext context = FacesContext.getCurrentInstance();

ExternalContextexternalContext = context.getExternalContext();

Object session = externalContext.getSession(false);

HttpSessionhttpSession = (HttpSession) session;

httpSession.invalidate();

msg = new FacesMessage(FacesMessage.SEVERITY_INFO, "La sesión actual se ha cerrado! ", "");

// redirect to your login view:

externalContext.redirect(Constantes.HOME); }

/* Carga la lista de permisos del usuario el cual a ingresado el usuario y */

publicStringcargaPermisosDeUsuario() {

LOG.info("***IntocargaPermisosDeUsuario()");

String au = "";

try {

ServicioBeneficiariosb = null;

setPermisos(ServicioMenu.cargadatosPermiso(getUsuario().getLogin(), getUsuario().getClave()));

} catch (Exception e) {

e.printStackTrace();}

limpiar();

return au; }

59

IV.IV. Uso de contraseñas seguras: El almacenamiento de la contraseña de

manera segura es un punto fundamental en la creación del usuario para su

autentificación dentro del portal.

El sistema cuenta con su algoritmo de encriptación MD5, pues este permite

que las contraseñas almacenadas en la base de datos sean seguras, la clase

encargada de realizar esta función es la clase control_md5.

Figura 43. Clase control_md5 (ubicación de la clase para encriptar las contraseñas) Elaborado por: Carina Torres y Darwin Aldas

Método que forma la clase control_md5.

public static String md5(String clear) throws Exception {

MessageDigest md = MessageDigest.getInstance("MD5");

byte[] b = md.digest(clear.getBytes());

int size = b.length;

StringBuffer h = new StringBuffer(size);

//algoritmo y arreglo md5

for (int i = 0; i < size; i++) {

int u = b[i] & 255;

if (u < 16) {

h.append("0" + Integer.toHexString(u)); }

else { h.append(Integer.toHexString(u));

} }

returnh.toString(); }

60

Las 3 clases citadas anteriormente, LoginFilter.java, LoginBean.java y

control_md5.java, son fundamentales en el módulo de seguridad, ya que

ayudan a controlar el acceso al sistema integrado.

Para el manejo del visualizador se ha creado en la clase encargada de

controlar el acceso de usuarios (LoginBean), un método exclusivo que

permita el acceso al módulo de visualización geográfica sin tener que

logearse, adicionalmente el sistema permite que este usuario tenga libre

acceso al visualizador, sin embargo, trabaja con variables de sesión, las cuales

ayudan a mantener controlados los objetos.

Cabe recalcar que entre las funcionalidades que presta el sistema es la

existencia de un usuario que únicamente pueda gestionar los datos referentes

a la Casa Salesiana a la que pertenece.

4.3 Autenticación

La autenticación dentro del sistema se lo hará a través de la identificación del usuario

a quien el administrador le entregara el nombre de usuario y contraseña que lo

identificara dentro del geoportal.

El método ConsultaUsuarioActivo, es el que permite realizar la consulta a la base de

datos para conocer el estado del usuario.

El método buscaUsuario, con ayuda del método ConsultaUsuarioActivo, realiza la

validación de las credenciales del usuario.

61

Para lograr que el usuario posea mayor seguridad dentro del sistema se implementó

la encriptación de la contraseña por medio del uso del algoritmo md5.

4.3.1 Autorización.

Para dar autorización en el sistema al usuario se definirán permisos de navegación

web mediante la especificación de roles.

En el sistema este proceso se logrará obteniendo información de la base de datos de

los permisos asignados a cada usuario dependiendo del perfil y rol al que pertenecen

y cargando de manera dinámica el menú al que tendrá acceso.

62

4.3.2 Auditoría de accesos.

Mediante la auditoría de accesos se busca conservar un historial de las transacciones

que serán realizadas por los usuarios que podrán realizar acciones como: crear,

modificar, eliminar registros, obteniendo una descripción detallada de la acción

realizada en el módulo de seguridad.

Nombre de la clase y método en el que se realizó la transacción.

Nombre del usuario que realizó la transacción.

Tipo de transacción: inserción, actualización o eliminación.

4.3.3 Creación, modificación y eliminación de registros.

El usuario administrador es el que tendrá acceso total al control de los registros de

inserción de nuevos registros, actualización o eliminación de los mismos.

Todo el desarrollo del módulo de seguridad está representado en clases dentro de las

cuales se definen los atributos que representan las columnas de las tablas de la base

de datos asimismo los métodos de inserción, consulta, actualización y eliminación de

la información.

Para realizar la eliminación o actualización de información primero se realiza la

selección del registro.

63

Para lograr este propósito se han creado métodos en cada una de las pantallas que

involucra la gestión de una casa Salesiana validando así la gestión de la casa a la

que el usuario hace referencia.

Para establecer la autorización de navegación se implementa el método

“obtenerMenuBarGesDatos” que permite la construcción dinámica del menú al que

tendrá acceso cada usuario dependiendo del rol y perfil al que pertenezca.

64

Para verificar la validez de la autorización en cada uno de los módulos integrados, se

definieron dos tipos de perfiles que pertenecen al mismo rol “Editor”.

Figura 45.Ingreso al sistema como Administrador


65

4.4. Auditoria

La auditoría está estructurada por una clase que permite identificar mediante sus

métodos, cual es el usuario que esta logeado, en que submódulo se encuentra

ubicado, que tipo de transacción está realizando, la fecha y hora en que realiza la

acción, toda esta información la podrá ver el administrador mediante un reporte.

La clase que realiza todas estas funciones se llama: ServicioAuditoria.java

Figura 46.Usuario por Casa Salesiana


Figura 47.Clase ServicioAuditoría(verificar la ubicación de la clase que

ayuda a procesar la información de la auditoria.)


66

CAPÍTULO 5

IMPLEMENTACIÓN Y PRUEBAS

5.1 Implementación

La presente aplicación se la configuró en el servidor HP ProLiant ML110 G7 que fue

designado por el CIMA-UPS que tiene las siguientes características:

5.1.1 Requerimientos mínimos.

Para el funcionamiento del sistema con una carga mínima de rendimiento se

necesitan de los siguientes requisitos a nivel de software:

Tabla 26.Requerimientos de software

Especificaciones de software

Sistema operativo Centos versión 5.9

Base de datos PostgreSQL versión 9.1.9

Datos espaciales PostGIS versión 1.5

Servidor web Apache 7.5.0

Lenguaje de desarrollo Java 7


5.1.2 Restauración de la base de datos.

El primer paso será la creación de la base de datos mediante la ejecución de

los siguientes comandos en el terminal.

psql –U postgres

Figura 48.Creación de la base de datos


67

Como segundo paso se ejecutará el script PostGis y el script Spatial esto se realiza

para el manejo de datos espaciales en el motor de base de datos y la restauración de

la misma.

5.1.3 Carga del archivo .war en el servidor Apache Tomcat.

En un navegador web digitar la siguiente dirección http://ide.ups.edu.ec:8081

para poder ingresar al servidor de Apache Tomcat.

Figura 49.Ejecución del script postgis


Figura 50.Ejecución de script Spatial


Figura 51.Restauración de la base de datos


http://ide.ups.edu.ec:8081/

68

Acceder a la característica de administración de Tomcat dando un clic en “Tomcat

Manager” para iniciar sesión.

Figura 52. Servidor web


Figura 53 Ingreso a administración del servidor


69

Se desplegará el gestor de aplicaciones web del servidor y se puede observar los

proyectos cargados en el mismo.

En la parte inferior de la pantalla la sección de desplegar que contiene la subsección

“Archivo WAR a desplegar “en la que se puede seleccionar el archivo.

Figura 54 Pantalla de gestión de aplicaciones


Figura 55. Selección del archivo war


70

Al desplegar el proyecto en el archivo WAR se podrá observar que se encuentra en la

lista de aplicaciones del servidor.

5.2 Pruebas

Las pruebas de rendimiento que se realizaron fueron al sistema de la Comunidad

Salesiana Integrado instalado correctamente en el servidor de CIMA mediante la

herramienta Apache-JMeter-2.11.

Las pruebas se realizaron desde un equipo de escritorio con las siguientes

características:

Tabla 27. Características de equipo utilizado para realizar pruebas.

Característica Detalle

Procesador: Intel(R) Xeon(R) i5 CPU E5506 @ 2.13GHz (4 CPUs), ~2.13GHz

Memoria: 4.00GB (3.23GB utilizable)

Sistema Operativo: Windows 7 Professional de 32 bits

Elaborado por: Carina Torres& Darwin Aldas

Figura 56. Proyectos desplegados


71

Los procedimientos para realizar el plan de pruebas fueron:

Crear un nuevo grupo de hilos

Poner un nombre a grupo de hilos

Especificar la acción a realizar en caso de tener un error

Indicar el número de hilos que se usara y el periodo de subida que tendrán los

mismos

Colocar el valor del contador del bucle.

Crear la petición http e indicar el nombre del servidor o la IP, indicar el puerto que se

utiliza y la ruta del proyecto.

Nombre del servidor: ide.ups.edu.ec

Puerto: el puesto actual que usa el servidor de apache utilizado es el 8081

La ruta: aquí se ingresa la ruta del sistema integrado final (/S.I.Salesiano)

respectivamente en cada prueba

Figura 57.Creación de grupo de hilos


72

Crear las vistas de resultados:

Ver resultados en árbol

Ver árbol de resultados

Figura 58.Creación de petición HTTP


Figura 59.Creación de resultados


73

Ejecutar el plan de pruebas con un número de muestra de 50 usuarios, en el

cual se observa el estado, los bytes, la latencia y el número de errores

Las pruebas se realzaron nuevamente con una muestra de 150 y de 200

usuarios.

Figura 60.Resultado en árbol (prueba con 50 muestras) Elaborado por: Carina Torres & Darwin Aldas

Figura 61. Árbol de resultados.


74

Después de realizar las pruebas respectivas se puede aclarar que el sistema soporta

200 usuarios aunque al aumentar el número el tiempo de carga va siendo mayor, se

toma en cuenta que actualmente existen alrededor de 28 a 30 casas salesianas lo cual

indica que por cada casa podrán conectarse un usuario y aun si se conectaran 5

usuarios al mismo instante por cada casa el sistema soportaría la carga

satisfactoriamente.



75

CONCLUSIONES

Se observó que la con la integración de los módulos en sus nuevas versiones,

el geoportal mejora significativamente en usabilidad, funcionalidad y portabilidad en

el servidor, ya que permite al usuario de acuerdo al rol y perfil que tenga

desenvolverse de manera ágil.

Se pudo identificar y definir las políticas de acceso a los recursos e

información consolidada en el Geoportal de la Comunidad Salesiana, mediante la

asignación de usuarios a roles y perfiles para la administración, respaldando de ésta

manera la integridad a la información.

Se diseñó un sistema de seguridad basado en la gestión de autenticación,

autorización y auditoría de acceso, lo cual permitirá la administración de

credenciales de acceso para la navegación web en cada uno de los módulos que

componen el geoportal.

Se concluye que a través del uso de perfiles de usuarios, se puede inducir al

uso de un mismo rol para definir distintas formas de navegación dentro del geoportal,

evitando de esta manera la creación de roles innecesarios.

Se concluye que mediante la consulta de auditoría de procesos en las

transacciones que gestiona el usuario; el administrador de seguridad podrá conocer

las acciones que se está realizando en el trato de información, permitiendo controlar

la integridad de la información del geoportal.

76

RECOMENDACIONES

Para la adecuada gestión del sistema integrado, es factible como primer paso

revisar el manual de usuario (de acuerdo al rol con el que cuente cada usuario) puesto

que se detalla claramente la funcionalidad de las interfaces.

Se recomienda al usuario administrador de seguridad, el análisis periódico de

las bitácoras generadas por el sistema, con el fin de generar técnicas que permitan

mejorar a futuro el rendimiento del sistema.

Es recomendable realizar mantenimientos periódicos a las credenciales de

usuario con el fin de con el fin de garantizar una adecuada administración de

seguridad de acceso, y así evitar el plagio de identidad.

Se recomienda que para una nueva versión del módulo de seguridad, sea

profundizado el tema de auditoría de accesos, debido a que es un tema muy amplio

que necesita ser implementado en su máximo potencial.

Sería deseable que este trabajo de titulación se lo pueda utilizar como servicio

wms o wfs, ya que ésta tecnología produce mapas de datos espaciales referidos de

forma dinámica a partir de la información geográfica producida.

Es recomendable que a futuro se considere que la aplicación pueda realizar la

carga y generación de archivos .shp (shapefile), éstos se utilizan para almacenar la

ubicación geométrica y la información de atributos de las entidades geográficas.

77

LISTA DE REFERENCIAS

AMHON, A. d. (09 de febrero de 2012). AMHON. Recuperado el 11 de octubre de 2013, de

AMHON en la Era de las Telecomunicaciones:

http://201.218.63.172/geoupse/index.php?option=com_content&view=article&id=

50&Itemid=11

Cofre, V., & Toledo, S. (2014).

Cofre, V., & Toledo, S. (2014). Análisis diseño y construcción del módulo del visualizador de

la comunidad salesiana versión 2.0. (Tesis de pregrado). Quito: Universidad

Politécnica Salesiana.

Corporation, O. (2013). NetBeans Platform. Recuperado el 03 de 07 de 2013, de

https://netbeans.org/features/index.html

Delgado Fernández, T., & Crompvoets, J. (2007). Infraestructuras de Datos Espaciales.

Recuperado el 27 de 06 de 2013, de Infraestructuras de Datos Espaciales:

http://faces.unah.edu.hn/ctig/images/stories/PDF/IDE/ide_geoportales.pdf

Dudney, B., Lehr, J., Willis, B., & Mattingly, L. (2004). Mastering JavaServerFaces. Canada:

Wiley.

Foundation, O. S. (2013). Quantum GIS. Recuperado el 10 de 08 de 2013, de

http://qgis.org/es/docs/index.html

Foundation, O. S. (2013). Quantum GIS. Recuperado el 28 de 06 de 2013, de

http://www.ensayosgratis.com/Temas-Variados/Qtumgis/108948.html

Fuentes, H. (14 de Marzo de 2011). GeoCivil. Obtenido de http://geo-

civil.blogspot.com/2011/03/quantum-gis-sig-opensource.html

Geary, D., & Horstmann, C. (2010). Core Java Server Faces 3rd edition. Prentice hall.

Geoupse. (01 de 10 de 2013). Geoportal. Obtenido de Geoportal UPSE:

http://201.218.63.172/geoupse/

GIS, D. (2013). QuantumGIS página Oficial. Recuperado el 10 de agosto de 2013, de

http://www.qgis.org/es/site/about/features.html

Leonard, A. (2010). JSF 2.0 Cookbook. Mumbai: Packt.

Mac Kay, P. (Octubre de 2004). Arquitectura de aplicaciones y servicios. Obtenido de La

visión de un ingeniero de campo:

https://msmvps.com/blogs/pmackay/archive/2004/10/04/14900.aspx

Martinez, J. (2008). Talleres Prácticos de iniciación a Postgis. Valencia: Universidad

Politécnica de Valencia.

Msdn. (2014). Msdn. Recuperado el 25 de 06 de 2014, de http://msdn.microsoft.com/es-

es/library/dd409377

Oracle. (2014). JavaServer Faces Technology. Recuperado el 11 de septiembre de 2014, de

http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html

78

PostgreSQL, E. G. (27 de 06 de 2013). PostgreSQL. Recuperado el 28 de 06 de 2013, de

http://www.postgresql.org/about/

PostgreSQL, E. G. (27 de junio de 2013). PostgreSQL. Recuperado el 28 de junio de 2013, de

http://www.postgresql.org/

Proyecto, P. C. (2013). OPENGEO. Recuperado el 28 de 06 de 2013, de

http://opengeo.org/technology/postgis/

Salesianos. (2014). Quienes Somos. Obtenido de Salesianos Ecuador:

http://www.salesianos.org.ec

Sevilla, G. (Abril de 2008). Desarrollo de un tutorial para la enseñanza de ensamblaje de

computadora personales a nivel básico. Quito.

Silva, D. A., & Mercerat, B. (29 de enero de 2002). Construyendo aplicaciones web con una

metodología de diseño. Recuperado el 03 de septiembre de 2013, de

http://www.unab.edu.co/editorialunab/revistas/rcc/pdfs/r22_art5_c.pdf

sparxsystems. (2013). sparxsystems. Recuperado el 25 de 06 de 2012, de

http://www.sparxsystems.com.ar/resources/tutorial/uml2_deploymentdiagram.ht

ml

teknoloji, p. (2014). PrimeFaces Userʼs Guide.

Tello, J. C. (2013). Diagramas de secuencia Universidad de Alcalá. Recuperado el 10 de

mayo de 2014, de http://www2.uah.es/jcaceres/capsulas/DiagramaSecuencia.pdf

The Apache Software Foundation . (2014). Apache Tomcat. Recuperado el 07 de 11 de

2014, de http://tomcat.apache.org/

Vilain, P., Schwabe, D., & Sieckenius de Souza, C. (10 de 2000). TECWEB(Web Engineering

Laboratory). Obtenido de http://www.tecweb.inf.puc-

rio.br/navigation/context/o_158de19d@1?p=o_PatriciaVilain_48b9

79

ANEXOS

Anexo 1. Manual de usuario para el Administrador

Pantalla de inicio (Home). Tiene un menú con el que permite acceder al visualizador como

usuario invitado, y otro para logearse.

Ingresar al sistema (usuario y contraseña)

Menús y submenús a los que tiene acceso el usuario Administrador

80

Menú Administración, submenú Edición permiso

Edición permiso: permite asignar los permisos, modificar, eliminar y visualizar que tendrá

cada uno de los roles a los menús y a los submenús.

Menú Administración, submenú Edición submódulo

Edición submódulo: Permite asignar, modificar, eliminar y visualizar los submódulos de

acuerdo al rol.

Menú Seguridad, submenú Edición persona

Edición persona: Permite el ingreso de los datos de la persona de acuerdo a la Casa

Salesiana a la que pertenezca.

81

Menú Seguridad, submenú Rol

Rol: Permite crear, modificar, eliminar y visualizar nuevos roles y la descripción de cada

uno de ellos.

Menú Seguridad, submenú Usuario

Usuario: Permite crear, modificar, eliminar y visualizar usuarios y password de acuerdo a

una persona

82

Menú Seguridad, submenú Perfil

Perfil: Permite asignar un rol a un usuario.

Menú Seguridad, submenú Cambio de contraseña.

Cambio de contraseña: permite realizar el cambio de la contraseña actual en el sistema

Menú Gestión datos, submenú Casa Salesiana

Casa Salesiana: Permite ingresar, modificar, eliminar y visualizar la información de las

Casas Salesianas.

83

Menú Gestión datos, submenú Obra Salesiana

Obra Salesiana: Permite ingresar, modificar, eliminar y visualizar la información de las

Obras de acuerdo a las Casas Salesianas.

Menú Gestión datos, submenú Lugar

Lugar: Permite ingresar, modificar, eliminar y visualizar la información del lugar de

acuerdo a la Casa y Obra.

Menú Gestión datos, submenú Beneficiario

Beneficiario: Permite ingresar, modificar, eliminar y visualizar la información de

beneficiarios de acuerdo a la Casa, Obra y lugar.

84

Menú Gestión datos, submenú Colaborador

Colaborador: Permite ingresar, modificar, eliminar y visualizar la información de

colaborador de acuerdo a la Casa, Obra y Lugar.

Menú Gestión datos, submenú Foto

Foto: Permite ingresar, modificar, eliminar y visualizar fotos de acuerdo a la casa, obra y

lugar.

Menú Edición datos geográficos, submenú Ubicación lugar manual

Ubicación lugar manual: Permite ingresar el Lugar en el mapa, si conocemos la latitud y

longitud del mismo, de acuerdo a una Casa, Obra y Lugar.

85

Menú Edición datos geográficos, submenú Ubicación de lugar visual

Ubicación de lugar visual: Permite ingresar el Lugar en el mapa dando doble clic, si está

identificado correctamente la ubicación del mismo, de acuerdo a una Casa, Obra y Lugar.

Menú Edición datos geográficos, submenú Ubicación de beneficiario con geojson

Ubicación de beneficiario con geojson: Permite ingresar el área de influencia (polígonos y

multipolígonos) en el mapa, de acuerdo a una casa, obra y lugar.

Menú Gestión estilos visualizador, submenú Gestión estilos visualizador

86

Gestión estilos visualizador: Contiene menús de búsquedas y gestión de estilos, la primera

búsqueda que se puede realizar es pos casa y tipo de obra.

En todos los tipos de búsqueda el resultado se podrá visualizar de la misma manera.

Tipos de búsqueda.

Búsqueda temática.

Búsqueda obra.

Árbol casa-obra.

Árbol casa-tipo-obra.

87

Búsqueda temática: Ingresando el nombre del lugar y aparecerá la lista con las opciones,

seleccionar la que se quiera visualizar y ejecutar el botón BUSCAR.

88

Búsqueda obra: Se puede realizar la búsqueda marcando la obra en general o una de sus

subcategorías.

89

Árbol casa-obra: Se puede realizar la búsqueda marcando la casa o una de sus obras.

90

Árbol casa-tipo-obra: Se puede realizar la búsqueda marcando la casa, un tipo o una de sus

obras.

Menú Gestión de estilos tiene los submenús:

Asignar estilo lugar.

Asignar estilo beneficiario.

Estilo lugar.

Estilo beneficiario.

91

Asignar estilo lugar: Permite personalizar con un ícono a un lugar de acuerdo al tipo de

obra que sea.

Asignar estilo beneficiario: permite personalizar con colores al beneficiario (área de

influencia).

Estilo lugar: Permite crear o eliminar un estilo para el lugar, con un ícono nuevo.

92

Estilo beneficiario: Permite crear un nuevo estilo para el beneficiario, con nuevos colores.

93

Anexo 2. Manual de usuario (usuario por Casa Salesiana)

Pantalla de inicio.

Pantalla de login

Menús y submenús disponibles para el usuario por Casa Salesiana

Menú Seguridad, submenú cambio de contraseña

94

Cambio de contraseña: Permite realizar el cambio de la contraseña que se le asigna al

usuario, y realizar el proceso las veces que el usuario requiera.

Menú gestión datos, submenú Casa Salesiana

Casa Salesiana: Permite ingresar la información únicamente de la Casa Salesiana a la que

pertenece.

Menú Gestión datos, submenú Obra Salesiana

Obra Salesiana: Permite ingresar y visualizar la información únicamente de las Obras

Salesianas a las que pertenece.

95

Menú Gestión datos, submenú Lugar

Lugar: Permite ingresar, modificar, eliminar y visualizar la información únicamente de los

lugares a las que pertenece.

96

Menú Gestión datos, submenú beneficiario

Beneficiario: Permite ingresar y visualizar la información únicamente los beneficiarios de la

Casa a la que pertenecen.

97

Menú Gestión datos, submenú Colaborador

Colaborador: Permite ingresar, actualizar, eliminar y visualizar la información únicamente

de los Colaboradores de la Casa a la que pertenecen.

Menú Edición datos geográficos, submenú Ubicación lugar manual

Ubicación lugar manual: Permite ingresar los puntos de latitud y longitud únicamente de

las obras y lugares de la Casa Salesiana a la que pertenecen.

98

Menú Edición datos geográficos, submenú Ubicación de lugar visual

Ubicación de lugar visual: Permite escoger la ubicación del lugar siempre y cuando se

tenga claro la dónde queda, únicamente de la Casa a la que pertenece siempre.

99

Anexo 3. Diagramas lógico y físico módulo de Administración

Diagramas lógico y físico inicial del módulo de Administración de seguridad, elaborado por

Byron Sandoval & Oswaldo Tutillo.

Este anexo es digital, la ruta en la que se encuentra es la siguiente:

ANEXO 3

Estos son los modelos iniciales físico y lógico del módulo de Administración de seguridad, a

los mismos que se realizaron cambios de acuerdo a las necesidades que requería el sistema

para la integración.

Anexo 4. Diccionario de datos módulo de Administración

Documento que contiene el diccionario de datos del modelo físico de la base de datos del

módulo de Administración de seguridad realizado por Byron Sandoval y Oswaldo Tutillo.


ANEXO 4.docx

Anexo 5. Cambios realizados a la base de datos

Documentos de cambios realizados a la base de datos e integración del sistema.


ANEXO 5.xlsx

El documento contiene los cambios que se hicieron en la base de datos original, las tablas

que se crearon con sus respectivos scripts de inserción y actualización, con el nombre de los

responsables de los cambios, además de las clases que se crearon y sus principales

características, durante el proceso de integración del sistema.

Anexo 6. Diccionario de datos del visualizador

Documento que contiene el diccionario de datos del visualizador realizado por Víctor Cofre

y Stalin Toledo.


ANEXO 6.docx

Documents

Pruebas - Repositorio Digital-UPS: Homedspace.ups.edu.ec/bitstream/123456789/7581/1/UPS-ST001316.pdf · El capítulo 1 “Marco teórico” contiene información de la metodología