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.
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.
1
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
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
visualizador
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.
2
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 Mostrar las opciones o cajas de texto, a las cuales tendrá acceso el usuario 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 Mostrar las opciones o cajas de texto, a las cuales tendrá acceso el usuario 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.
3
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.
4
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).
Obtencion de Requerimientos
Diseño Navegacional
Implementación
Modelo Conceptual
Diseño de Interfaz Abstracta
Figura 1. Fases de la metodología OOHDM Fuente: (Silva & Mercerat, 2002). Elaborado por: Carina Torres y Darwin Aldas
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.
5
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: 6
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
Elaborado por: Carina Torres & Darwin Aldas
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).
7
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). 8
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 Elaborado por: Carina Torres & Darwin Aldas
9
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
Usuario encargado de la administración de la información consolidada
Casa Salesiana
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.
Elaborado por: Carina Torres & Darwin Aldas
10
Tabla 4. Descripción de casos de uso del sistema Roles
Tareas
Administración
de
información del módulo de
El administrador puede ingresar, consultar, actualizar y eliminar información de todos los módulos que forman el sistema.
seguridad Edición de información del
El Editor Datos por Casa Salesiana se encargará de editar los datos
módulo de gestión de datos
de acuerdo a la Casa y Obra Salesiana a la que pertenezca.
Consultar
al
módulo
del
El invitado podrá acceder únicamente al visualizador y hacer consultas dentro de él.
visualizador.
Elaborado por: Carina Torres & Darwin Aldas
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
El administrador puede realizar auditorías (consultas) de las
realizadas
por
transacciones el
usuario
registrado.
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
El administrador puede ingresar, consultar, actualizar y
pantallas
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
El administrador puede ingresar, consultar, actualizar y
rol.
eliminar información de módulos por rol a través del módulo de seguridad.
Elaborado por: Carina Torres & Darwin Aldas
11
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
Auditoría de transacciones realizadas por el usuario administrador en el
de uso
sistema
Actores
Usuario Administrador
Camino
Ingresar al sistema
Principal
Ingresar usuario y contraseña Consultar información de procesos mediante filtros de búsqueda. Enviar registro de transacciones Generar reporte.
Camino
2.1. Datos del usuario administrador son incorrectos
secundario
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.
Elaborado por: Carina Torres & Darwin Aldas
12
Figura 3. Caso de uso de auditoría Elaborado por: Carina Torres & Darwin Aldas
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.
13
Tabla 7. Casos de uso: Ingreso visual de la ubicación del lugar Nombre de caso de uso
Cambio de contraseña
Actores
Usuario Administrador Usuario Editor Datos por Casa Salesiana
Camino Principal
Ingresar al sistema
Usuarios
Ingresar usuario y contraseña
Administrador,
Editor Datos, Editor GIS
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.
Precondiciones
El usuario deber estar registrado en el portal
Postcondiciones
Interacción y validación de información entre portal y BDD. Envío de confirmación de cambio de contraseña.
Elaborado por: Carina Torres & Darwin Aldas
Figura 4.Caso de uso: Cambio de contraseña Elaborado por: Carina Torres & Darwin Aldas
14
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
Administración de perfiles
uso Actores
Usuario Administrador
Camino Principal
Ingresar al sistema
Usuarios
Ingresar usuario y contraseña
Administrador
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.
Camino secundario
2.1. Datos de usuario incorrectos. 2.1.1. Enviar notificación de datos incorrectos. 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.
Precondiciones
El usuario deber estar registrado en el portal
Postcondiciones
Interacción y validación de información entre portal y BDD. Envío de notificación de inserción, actualización y/o eliminación.
Elaborado por: Carina Torres & Darwin Aldas
15
Figura 5.Caso de uso: Administración de perfiles Elaborado por: Carina Torres & Darwin Aldas
16
Tabla 9. Casos de uso: Administración de módulos Nombre de caso de uso
Administración de módulos
Actores
Usuario Administrador
Camino Principal
Ingresar al sistema
Usuarios Administrador
Ingresar usuario y contraseña 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.
Camino secundario
2.1. Datos de usuario incorrectos. 2.1.1. Enviar notificación de datos incorrectos. 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.
Precondiciones
El usuario deber estar registrado en el portal
Postcondiciones
Interacción y validación de información entre portal y BDD. Envío de notificación de inserción, actualización y/o eliminación.
Elaborado por: Carina Torres & Darwin Aldas
17
Figura 6. Caso de uso: Administración de módulos Elaborado por: Carina Torres & Darwin Aldas
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.
18
Tabla 10. Caso de uso: Administración de menús por pantalla Nombre de caso de uso
Administración de menús por pantalla
Actores
Usuario Administrador
Camino Principal
Ingresar al sistema
Usuarios
Ingresar usuario y contraseña
Administrador
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.
Camino secundario
2.1. Datos de usuario incorrectos. 2.1.1. Enviar notificación de datos incorrectos. 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.
Precondiciones
El usuario deber estar registrado en el portal
Postcondiciones
Interacción y validación de información entre portal y BDD. Envío de notificación de inserción, actualización y/o eliminación.
Elaborado por: Carina Torres y Darwin Aldas
Figura 7. Caso de uso: Administración de menús por pantalla Elaborado por: Carina Torres & Darwin Aldas
19
Tabla 11. Caso de uso: Administración de usuarios Nombre de caso de uso
Administración de usuarios
Actores
Usuario Administrador
Camino Principal
Ingresar al sistema
Usuarios Administrador
Ingresar usuario y contraseña 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.
Camino secundario
2.1. Datos de usuario incorrectos. 2.1.1. Enviar notificación de datos incorrectos. 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.
Precondiciones
El usuario deber estar registrado en el portal
Postcondiciones
Interacción y validación de información entre portal y BDD. Envío de notificación de inserción, actualización y/o eliminación.
Elaborado por: Carina Torres y Darwin Aldas
Figura 8.Caso de uso: Administración de usuarios Elaborado por: Carina Torres & Darwin Aldas
20
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
Actores
Usuario Administrador
Camino Principal
Ingresar al sistema
Usuarios Administrador
Ingresar usuario y contraseña 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.
Camino secundario
2.1. Datos de usuario incorrectos. 2.1.1. Enviar notificación de datos incorrectos. 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.
Precondiciones
El usuario deber estar registrado en el portal
Postcondiciones
Interacción y validación de información entre portal y BDD. Envío de notificación de inserción, actualización y/o eliminación.
Elaborado por: Carina Torres y Darwin Aldas
Figura 9. Caso de uso: Administración de roles Elaborado por: Carina Torres & Darwin Aldas
21
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
Actores
Usuario Administrador
Camino Principal
Ingresar al sistema
Usuarios Administrador
Ingresar usuario y contraseña 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.
Camino secundario
2.1. Datos de usuario incorrectos. 2.1.1. Enviar notificación de datos incorrectos. 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.
Precondiciones
El usuario deber estar registrado en el portal
Postcondiciones
Interacción y validación de información entre portal y BDD. Envío de notificación de inserción, actualización y/o eliminación.
Elaborado por: Carina Torres y Darwin Aldas
Figura 10. Caso de uso: Administración de módulos por rol Elaborado por: Carina Torres & Darwin Aldas
22
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 Elaborado por: Carina Torres & Darwin Aldas
23
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 Elaborado por: Carina Torres y Darwin Aldas
24
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 Elaborado por: Carina Torres y Darwin Aldas
25
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 Elaborado por: Carina Torres y Darwin Aldas
26
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 Elaborado por: Carina Torres y Darwin Aldas
27
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.
ASPECTOS
CONFIDENCIALIDAD INTEGRIDAD DISPONIBILIDAD
HARDWARE ELEMENTOS
SOFTWARE DATOS
INTERRUPCIÓN SEGURIDAD
FIABILIDAD
MODIFICACIÓN CREACIÓN AMENAZAS PERSONAS AMENAZAS LÓGICAS CATÁSTROFES
PREVENCIÓN MECANISMOS
DETECCIÓN RECUPERACIÓN
Figura16. Módulo de seguridad Elaborado por: Carina Torres & Darwin Aldas
28
Figura 17. Módulo de seguridad para el geoportal Elaborado por: Carina Torres & Darwin Aldas
É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.
Interfaz 1 Persona
Módulo de Seguridad
Usuarios
Figura 18. Diseño lógico del módulo de seguridad Elaborado por: Carina Torres & Darwin Aldas
29
Perfil
Interfaz 2 Interfaz 3
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.
Rol
Invitado Editor de datos por Casa Salesiana Administrador Geoportal
Figura 19. Principales roles de administración para el geoportal Elaborado por: Carina Torres & Darwin Aldas
30
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.
É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.
Figura 20. Diseño conceptual módulo: Administración de seguridad Diagrama creado con herramienta Navicat. Elaborado por: Carina Torres y Darwin Aldas
31
3.2 Diseño navegacional
Figura 21. Diseño navegacional: Módulo de administración de seguridad Diagrama creado con herramienta Navicat. Elaborado por: Carina Torres & Darwin Aldas
32
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.
Figura 22.ADV’s Pantalla inicio y autenticación Elaborado por: Carina Torres & Darwin Aldas
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 23.ADV’s Pantalla de elementos del menú del sistema Elaborado por: Carina Torres & Darwin Aldas
33
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.
Figura 24.ADV’s Pantalla de administración del módulo de seguridad Elaborado por: Carina Torres & Darwin Aldas
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
34
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.
Figura 26.ADV’s Elementos de interfaz de auditoría Elaborado por: Carina Torres & Darwin Aldas
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.
35
Diagrama de clases del gestor datos geográficos
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.
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)
36
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)
37
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. Elaborado por: Carina Torres & Darwin Aldas
38
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. Elaborado por: Carina Torres y Darwin Aldas
39
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. Elaborado por: Carina Torres y Darwin Aldas
40
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).
Elaborado por: Carina Torres & Darwin Aldas
La tabla Submódulo contiene un conjunto de datos que representa las diferentes páginas a las que el usuario tendrá acceso.
41
Tabla 15.Diccionario de datos tabla Submódulo Nombre
tb_submodulo
Descripción
Almacena la información básica del submódulo
Primary
id_submod
Key Key
ColumnName
Data Type
NotNull
Descripción
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
Elaborado por: Carina Torres & Darwin Aldas
La tabla Permiso contiene un conjunto de datos que definirá un determinado permiso. Tabla 16.Diccionario de datos tabla Permiso Nombre Descripción
tb_permiso Almacena la información de los permisos que tendrá cada submódulo de acuerdo al rol que tenga. id_permiso
Primary Key Key
ColumnName
Data Type
NotNull
Descripción
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
Elaborado por: Carina Torres & Darwin Aldas
42
La tabla Rol contiene un conjunto de datos que definirá un rol. Tabla 17.Diccionario de datos tabla Rol Nombre
tb_rol
Descripción
Almacena la información de los roles
Primary
id_rol
Key Key
ColumnName
Data Type
NotNull
Descripción
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
Elaborado por: Carina Torres & Darwin Aldas
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.
Key
ColumnName
Data Type
NotNull
Descripción
FK
id_rol
integer
Yes
Representa al indicador del rol.
FK
id_submod
integer
Yes
Representa al indicador del submódulo.
Elaborado por: Carina Torres & Darwin Aldas
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
Key
ColumnName
Data Type
NotNull
Descripción
PK
tb_menu
serial
Yes
Identificación única del menú.
descripcion_menu
text
Yes
Es la descripción o nombre del menú.
Elaborado por: Carina Torres & Darwin Aldas
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. 43
Tabla 20.Diccionario de datos tabla Módulo rol Nombre
tb_modulorol
Descripción Key
Almacena la información de los diferentes módulos que forman parte del menú. ColumnName Data Type NotNull Descripción
FK
id_modul
integer
Yes
FK
id_rol
integer
Yes
FK
id_menu
integer
Yes
Representa al indicador del módulo. Representa al indicador del rol. 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
Key
ColumnName
Data Type
NotNull
Descripción
PK
id_cas
serial
Yes
nombre_cas
text
Yes
Identifica a la casa a la cual hace referencia Nombre de la casa salesiana
direccion_cas
text
Yes
telefono_cas
text
No
Dirección o ubicación de la casa salesiana. Teléfono de la casa salesiana.
correo_cas
text
Yes
Correo de la casa salesiana
director_cas
text
Yes
pathicono_cas
text
Yes
nombrecorto_cas
text
Yes
estado_cas
boolean
No
Director o persona responsable de la casa salesiana. Es el directorio o path donde se encuentran almacenados todos los iconos disponibles para las casas salesianas. Es una abreviación del nombre de la casa salesiana por motivo de diseño de interfaz. Almacenará un true o false
Elaborado por: Carina Torres & Darwin Aldas
La tabla País contiene un conjunto de datos que definirá a que país pertenecen las Casas Salesianas.
44
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
Key FK
ColumnName
Data Type
NotNull
Descripción
id_pais
integer
Yes
Representa al indicador del país.
descripción_pais
text
Yes
Representa
el
nombre
o
descripción del país. Elaborado por: Carina Torres & Darwin Aldas
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
Key
ColumnName
Data Type
NotNull
Descripción
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.
Elaborado por: Carina Torres & Darwin Aldas
La tabla Persona contiene un conjunto de datos que especifica las credenciales del usuario.
45
Tabla 24. Diccionario de datos tabla Persona Nombre
tb_persona
Descripción
Almacena la información de las personas.
Primary
id_per
Key Key
ColumnName
Data Type
NotNull
Descripción
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.
FK
estado_persona
boolean
Yes
Almacenará un true o false
id_cas
integer
Yes
Representa al indicador de la casa salesiana a la que pertenece la persona.
Elaborado por: Carina Torres & Darwin Aldas
La tabla Usuario contiene un conjunto de datos que especifica las credenciales del usuario.
46
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
Key
ColumnName
Data Type
NotNull
Descripción
PK
id_usu
serial
Yes
FK
id_per
integer
Yes
usuario_usu
character
Yes
contrasenia_usu
character
Yes
fechacrea_usu
date
Yes
fechamodif_usu
date
Yes
fecmodifcontras_usu
date
Yes
Identificador único del beneficiario Representa al indicador del estilo del beneficiario Es una pequeña descripción del usuario. Contraseña que se le asigna al usuario. Fecha en la que se crea el usuario. Fecha en la que se modifica el usuario. Fecha en la que se modifica la contraseña del usuario.
Elaborado por: Carina Torres & Darwin Aldas
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 Elaborado por: Carina Torres & Darwin Aldas
47
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 Elaborado por: Carina Torres y Darwin Aldas
48
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.
49
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
Figura 34. Proyectos restaurados en un solo IDE, Etapas Elaborado por: Carina Torres & Darwin Aldas
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 Elaborado por: Carina Torres & Darwin Aldas
50
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
Figura 37. Integración de los paquetes y
correspondientes a capa interfaz
clases de cada uno de los proyectos
Elaborado por: Carina Torres & Darwin Aldas
Elaborado por: Carina Torres y Darwin Aldas
51
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.
Figura 38. Ejemplo de importación de paquetes con el nombre correcto Elaborado por: Carina Torres & Darwin Aldas
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.
52
Figura 39. Unificación de librerías Elaborado por: Carina Torres y Darwin Aldas
53
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.
Figura 40. Sistema Integrado Salesiano Elaborado por: Carina Torres & Darwin Aldas
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. 54
Figura 41. Clase LoginFilter Elaborado por: Carina Torres & Darwin Aldas
55
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; }
56
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);
57
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()) { habilitaEstilosVisualizador = 1; 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 { habilitaEstilosVisualizador = 0; 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();
58
return au; }
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(); }
59
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.
60
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.
61
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.
62
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.
63
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 Elaborado por: Carina Torres & Darwin Aldas
64
Figura 46.Usuario por Casa Salesiana Elaborado por: Carina Torres & Darwin Aldas
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 47.Clase ServicioAuditoría(verificar la ubicación de la clase que ayuda a procesar la información de la auditoria.) Elaborado por: Carina Torres & Darwin Aldas
65
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
Elaborado por: Carina Torres y Darwin Aldas
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 Elaborado por: Carina Torres y Darwin Aldas
66
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.
Figura 49.Ejecución del script postgis Elaborado por: Carina Torres y Darwin Aldas
Figura 50.Ejecución de script Spatial Elaborado por: Carina Torres y Darwin Aldas
Figura 51.Restauración de la base de datos Elaborado por: Carina Torres y Darwin Aldas
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.
67
Figura 52. Servidor web Elaborado por: Carina Torres y Darwin Aldas
Acceder a la característica de administración de Tomcat dando un clic en “Tomcat Manager” para iniciar sesión.
Figura 53 Ingreso a administración del servidor Elaborado por: Carina Torres y Darwin Aldas
68
Se desplegará el gestor de aplicaciones web del servidor y se puede observar los proyectos cargados en el mismo.
Figura 54 Pantalla de gestión de aplicaciones Elaborado por: Carina Torres y Darwin Aldas
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 55. Selección del archivo war Elaborado por: Carina Torres y Darwin Aldas
69
Al desplegar el proyecto en el archivo WAR se podrá observar que se encuentra en la lista de aplicaciones del servidor.
Figura 56. Proyectos desplegados Elaborado por: Carina Torres y Darwin Aldas
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
70
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.
Figura 57.Creación de grupo de hilos Elaborado por: Carina Torres & Darwin Aldas
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
71
Figura 58.Creación de petición HTTP Elaborado por: Carina Torres & Darwin Aldas
Crear las vistas de resultados:
Ver resultados en árbol
Ver árbol de resultados
Figura 59.Creación de resultados Elaborado por: Carina Torres & Darwin Aldas
72
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
Figura 60.Resultado en árbol (prueba con 50 muestras) Elaborado por: Carina Torres & Darwin Aldas
Figura 61. Árbol de resultados. Elaborado por: Carina Torres & Darwin Aldas
Las pruebas se realzaron nuevamente con una muestra de 150 y de 200
usuarios.
73
Figura 62.Resultado en árbol (prueba con 150 muestras) Elaborado por: Carina Torres & Darwin Aldas
Figura 63.Resultado en árbol (prueba con 200 muestras) Elaborado por: Carina Torres & Darwin Aldas
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.
74
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.
75
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.
76
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://geocivil.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/eses/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
77
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.pucrio.br/navigation/context/o_158de19d@1?p=o_PatriciaVilain_48b9
78
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
79
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.
80
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
81
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.
82
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.
83
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.
84
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
85
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. 86
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.
87
Búsqueda obra: Se puede realizar la búsqueda marcando la obra en general o una de sus subcategorías.
88
Árbol casa-obra: Se puede realizar la búsqueda marcando la casa o una de sus obras.
89
Á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. 90
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.
91
Estilo beneficiario: Permite crear un nuevo estilo para el beneficiario, con nuevos colores.
92
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
93
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.
94
Menú Gestión datos, submenú Lugar Lugar: Permite ingresar, modificar, eliminar y visualizar la información únicamente de los lugares a las que pertenece.
95
Menú Gestión datos, submenú beneficiario Beneficiario: Permite ingresar y visualizar la información únicamente los beneficiarios de la Casa a la que pertenecen.
96
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.
97
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.
98
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. Este anexo es digital, la ruta en la que se encuentra es la siguiente: 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. Este anexo es digital, la ruta en la que se encuentra es la siguiente: 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. Este anexo es digital, la ruta en la que se encuentra es la siguiente: ANEXO 6.docx
99
