UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA CIENCIAS FÍSICAS Y
MATEMÁTICA.
CARRERA DE INGENIERÍA INFORMÁTICA.
“SISTEMA PARA LA GESTIÓN Y RESERVACIÓN DE SALAS, GALERÍAS,
AUDITORIOS Y TEATROS DE LA SEDE NACIONAL DE CASA DE LA
CULTURA ECUATORIANA.”
TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE
INGENIERO INFORMÁTICO.
AUTOR:
JENNY LILIANA PUCHA ATÁN.
TUTOR:
ING. RENÉ ALFONSO CARRILLO FLORES MSc.
QUITO - ECUADOR
2015
DEDICATORIA
A mis padres Gloria y Manuel, porque creyeron en mí y trabajaron muy duro para
sacarme adelante, además de formarme con ejemplos dignos de superación y entrega,
porque es gracias a ustedes que hoy puedo ver alcanzada mi meta, ya que siempre
estuvieron alentándome en los momentos más difíciles de mi carrera. Esto es por
ustedes, por lo que valen, porque admiro su fortaleza y porque han hecho de mí una
excelente persona.
A mis hermanos Kevin, Fabián y Patricio por estar a mi lado en los buenos y malos
momentos, por su apoyo incondicional.
A mis familiares, amigos y todos quienes creyeron en mí y me apoyaron directa e
indirectamente durante toda mi etapa universitaria.
Este logro hoy representa una gran motivación para seguir siempre adelante y
conseguir más éxitos en mi vida personal y académica.
ii
AGRADECIMIENTOS
Agradezco a Dios por haberme permitido llegar hasta este punto de mi vida, por
darme salud y fortaleza para lograr mis objetivos.
Agradezco a mis padres Gloria y Manuel, quienes con mucho esfuerzo y amor me
han apoyado en el camino de mi vida, por ser los mejores padres y darme la
oportunidad de superarme, porque lo que soy ahora es gracias a ustedes. Gracias por
la confianza que depositaron en mí, por todos sus consejos y su paciencia.
Agradezco a mis hermanos Kevin, Fabián, Patricio, a toda mi familia y amigos, por
darme siempre ánimos y confiar en mí. Gracias por haber fomentado en mí el deseo
de superación y el anhelo de triunfo en la vida.
A mi novio quién ha estado en estos 5 años a mi lado brindándome sus
conocimientos, consejos y cariño gracias Javier Lucero.
A la Casa de la Cultura Ecuatoriana “Benjamín Carrión”, por su apoyo al brindarme
la oportunidad de cumplir con la realización de este proyecto de investigación y
concluir con éxito la realización del mismo.
Un especial reconocimiento y eterno agradecimiento a mí tutor de Tesis el Ing. René
Carrillo, por haber creído en mí y por brindarme su apoyo y enseñanzas para
culminar con éxito mí trabajo de graduación.
A los Ingenieros Jairo Navarro y Felipe Borja, por sus comentarios en todo el
proceso de elaboración de la Tesis y sus atinadas correcciones.
Agradezco de manera muy especial a la Universidad Central del Ecuador que a
través de su cuerpo docente supo impartirme los conocimientos adecuados y
contribuyo a mí formación profesional.
Gracias a todos por sus sabios consejos.
Jenny Pucha
iii
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL
Yo, JENNY LILIANA PUCHA ATÁN en calidad de autor del trabajo de
investigación
realizada
sobre:
“SISTEMA
PARA
LA
GESTIÓN
Y
RESERVACIÓN DE SALAS, GALERÍAS, AUDITORIOS Y TEATROS DE LA
SEDE NACIONAL DE CASA DE LA CULTURA ECUATORIANA”, por la
presente autorizo a la UNIVERSIDAD CENTRAL DEL ECUADOR, hacer uso de
todos los contenidos que me pertenecen o de parte de los que contiene esta obra, con
fines estrictamente académicos o de investigación.
Los derechos que como autor me corresponden, con excepción de la presente
autorización, seguirán vigentes a mi favor, de conformidad con lo establecido en los
artículos 5, 6, 8, 19 y demás pertinentes de la Ley de Propiedad Intelectual y su
Reglamento.
Quito, 01 de Abril de 2015
……………………………………………………………..
Jenny Liliana Pucha Atán
C.I.: 1720693504
iv
v
vi
vii
viii
CONTENIDO
DEDICATORIA ...................................................................................................... ii
AGRADECIMIENTOS .......................................................................................... iii
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL....................................... iv
CONTENIDO ......................................................................................................... ix
LISTA DE FIGURAS........................................................................................... xiv
LISTA DE TABLAS .............................................................................................. xv
RESUMEN ......................................................................................................... xviii
ABSTRACT........................................................................................................... xix
CAPÍTULO 1 ............................................................................................................... 1
1.1 INTRODUCCIÓN .............................................................................................. 1
1.2 PLANTEAMIENTO DEL PROBLEMA ........................................................... 2
1.3 FORMULACIÓN DEL PROBLEMA ............................................................... 2
1.4 INTERROGANTES DE LA INVESTIGACIÓN .............................................. 2
1.5 OBJETIVOS DE LA INVESTIGACIÓN .......................................................... 3
1.5.1 Objetivo General .......................................................................................... 3
1.5.2 Objetivo Específicos .................................................................................... 3
1.6 JUSTIFICACIÓN ............................................................................................... 4
1.7 ALCANCE ......................................................................................................... 5
1.8 LIMITACIONES ................................................................................................ 6
CAPÍTULO 2 ............................................................................................................... 7
2.1 ANTECEDENTES ............................................................................................. 7
2.2 FUNDAMENTACIÓN TEÓRICA .................................................................... 7
2.2.1 Plataforma de desarrollo .............................................................................. 8
2.2.1.1 Lenguaje de Programación JAVA ......................................................... 8
2.2.1.2 JEE6 (Java Enterprise Edition) ............................................................. 9
ix
2.2.1.3 Aplicaciones Web .................................................................................. 9
2.2.1.4 Tecnologías en la capa de Presentación ................................................. 9
Java Server Faces (JSF) .................................................................................. 9
Richfaces ....................................................................................................... 10
Ajax (Asynchronous JavaScript y XML) ..................................................... 10
Ajax4Jsf ........................................................................................................ 11
Facelets ......................................................................................................... 11
Lenguaje de Marcado de Hipertexto Extensible (XHTML) ......................... 12
Extensible Markup Language (XML)........................................................... 12
Java Script ..................................................................................................... 13
2.2.1.5 Tecnologías en la capa de Negocio...................................................... 13
Servidor de Aplicaciones JBOSS ................................................................. 13
Enterprise Java Beans (EJB) ......................................................................... 14
2.2.1.6 Tecnologías en la capa de Acceso a Datos .......................................... 15
Java Persistence API (JPA)........................................................................... 15
Unidad de persistencia .................................................................................. 16
JPA - Entity Manager ................................................................................... 17
Arquitectura JPA........................................................................................... 18
Entidades ....................................................................................................... 19
2.2.1.7 Herramientas de desarrollo .................................................................. 21
Eclipse IDE ................................................................................................... 21
Gestor de Base de Datos PostgreSql ............................................................. 21
Servidor de aplicaciones JBOSS................................................................... 23
Lenguaje de modelamiento UML ................................................................. 24
Plataforma de construcción de páginas Web JSF ......................................... 24
2.3 IDENTIFICACIÓN DE VARIABLES ............................................................ 24
2.3.1 Variables .................................................................................................... 25
x
Variable Independiente .................................................................................... 25
Variable Dependiente ...................................................................................... 25
2.4 HIPÓTESIS ...................................................................................................... 25
CAPÍTULO 3 ............................................................................................................. 26
3.1 DISEÑO DE LA INVESTIGACIÓN ............................................................... 26
3.1.1 Definición de Extreme Programming (XP) ............................................... 26
3.1.2 Los valores de XP ...................................................................................... 27
3.1.3 Los principios de XP ................................................................................. 28
3.1.4 Las actividades de XP ................................................................................ 29
3.1.5 Las prácticas de XP.................................................................................... 29
3.1.6 Ciclo de vida de un proyecto XP ............................................................... 31
3.1.7 Roles en XP ............................................................................................... 33
3.1.7.1 Cliente .................................................................................................. 33
3.1.7.2 Desarrollador ....................................................................................... 34
3.1.7.3 Gestor (Manager) ................................................................................. 35
3.1.7.4 Consultor.............................................................................................. 35
3.1.7.5 Encargado del seguimiento (Tracker) .................................................. 35
3.1.7.6 Encargado de pruebas (Tester) ............................................................ 36
3.1.7.7 Entrenador (Coach) .............................................................................. 36
3.1.8 Visión y metáfora del sistema .................................................................... 36
3.1.8.1 Visión del sistema ................................................................................ 37
3.1.8.2 Metáfora del sistema ............................................................................ 37
3.1.9 Justificación del uso de Extreme Programming ........................................ 38
3.2 DESARROLLO DEL SISTEMA ..................................................................... 38
3.2.1 Fase I: Exploración .................................................................................... 38
Especificación de requerimientos .................................................................... 38
Historias de usuario ......................................................................................... 39
xi
Identificación de las Historias de Usuario ....................................................... 39
3.2.1.1 Diagrama de procesos para SICCE-TS ................................................ 42
3.2.1.2 Diagramas de Casos de Uso................................................................. 43
CASOS DE USO IDENTIFICADOS ........................................................... 44
Caso de uso Acceso al módulo de administración ..................................... 44
Caso de uso Gestión de Empleados ........................................................... 47
Caso de uso Gestión de Espacios Físicos .................................................. 49
Caso de uso Gestión de Clientes ................................................................ 52
Caso de uso Gestión de Estados ................................................................ 55
Caso de uso Gestión de Tipos de Identificación ........................................ 58
Caso de uso Gestión Reservas ................................................................... 61
Caso de uso Gestión de Reportes ............................................................... 66
3.2.1.3 Diseño de la base de datos para SICCE-TS ......................................... 66
1. Etapa del diseño conceptual ........................................................................ 67
2. Etapa de diseño físico .................................................................................. 67
3.2.1.4 Diseño de la arquitectura para SICCE-TS ........................................... 71
3.2.2 Fase II: Planificación de la entrega ............................................................ 73
3.2.3 Fase III: Iteraciones ................................................................................... 74
3.2.3.1 Diseño de capas ................................................................................... 74
3.2.3.2 Codificación ......................................................................................... 75
Construcción de la página Web .................................................................... 75
Programación de la lógica del negocio. ........................................................ 82
Programación de la persistencia. .................................................................. 90
3.2.3.3 Seguimiento de las iteraciones ............................................................. 93
Primera iteración ........................................................................................... 94
Segunda iteración .......................................................................................... 94
Tercera iteración ........................................................................................... 94
xii
3.2.4 Fase IV: Producción................................................................................... 94
3.2.4.1 Pruebas de aceptación .......................................................................... 95
3.2.4.2 Planificación de la implantación ........................................................ 111
Definición de Requisitos de instalación...................................................... 111
Configuración del ambiente de instalación. ................................................ 112
Publicación de la aplicación web del sistema SICCE-TS........................... 112
Vista de despliegue ..................................................................................... 113
CAPÍTULO 4 ........................................................................................................... 114
4.1 RESPALDOS DE INFORMACIÓN .............................................................. 114
4.1.1 Backup ..................................................................................................... 114
4.1.2 Tipos de respaldos ................................................................................... 115
4.1.3 Periodicidad ............................................................................................. 117
CAPÍTULO 5 ........................................................................................................... 118
5.1 CONCLUSIONES .......................................................................................... 118
5.2 RECOMENDACIONES ................................................................................ 119
GLOSARIO ............................................................................................................. 120
BIBLIOGRAFÍA ..................................................................................................... 125
ANEXO A ................................................................................................................ 127
MANUAL DE INSTALACIÓN .......................................................................... 127
ANEXO B ................................................................................................................ 145
MANUAL DE EJECUCIÓN DE CÓDIGO FUENTE ........................................ 145
ANEXO C ................................................................................................................ 155
MANUAL DE USUARIO ................................................................................... 155
xiii
LISTA DE FIGURAS
Figura 1. Interpretación de un EJB ............................................................................ 15
Figura 2. Configuración persistence.xml SICCE-TS ................................................. 16
Figura 3. Relaciones entre los componentes primarios de la arquitectura JPA ......... 18
Figura 4. Estructura de directorios de JBoss7.1.1 ...................................................... 23
Figura 5. Esquema del ciclo de vida de un proyecto XP ........................................... 31
Figura 6. Equipo XP ................................................................................................... 33
Figura 7. Diagrama de procesos SICCE-TS .............................................................. 42
Figura 8. Representación de un actor en un diagrama de caso de uso ....................... 43
Figura 9. Representación de un caso de uso .............................................................. 43
Figura 10. Relación de asociación ............................................................................. 44
Figura 11. Relación de inclusión................................................................................ 44
Figura 12. Relación de extensión ............................................................................... 44
Figura 13. Representación Generalización ................................................................ 44
Figura 14. Diagrama de Caso de Uso: Acceso al módulo de administración ............ 45
Figura 15. Diagrama de Caso de Uso: Gestión Empleados ....................................... 47
Figura 16. Diagrama de Caso de Uso: Gestión Espacios Físicos .............................. 49
Figura 17. Diagrama de Caso de Uso: Gestión Clientes ............................................ 52
Figura 18. Diagrama de Caso de Uso: Gestión Estados............................................. 55
Figura 19. Diagrama de Caso de Uso: Gestión Tipos de identificación .................... 58
Figura 20. Diagrama de Caso de Uso: Gestión Reservas .......................................... 61
Figura 21. Diagrama de Caso de Uso: Gestión de reportes ....................................... 66
Figura 22. Diseño conceptual de la base de datos SICCE-TS ................................... 69
Figura 23. Diseño físico de la base de datos SICCE-TS ............................................ 70
Figura 24. Distribución de tres capas ......................................................................... 71
Figura 25. Distribución de dos niveles ....................................................................... 72
Figura 26. Plan de entrega para SICCE-TS ............................................................... 73
Figura 28. Capas SICCE-TS ...................................................................................... 74
Figura 29. Vista de despliegue SICCE-TS ............................................................... 113
Figura 30.Riesgos que se encuentran inmersos en los sistemas .............................. 114
xiv
LISTA DE TABLAS
Tabla 1. Tipos de EJB´s ............................................................................................. 14
Tabla 2. Los cinco valores de XP............................................................................... 28
Tabla 3. Los principios guiados de XP ...................................................................... 28
Tabla 4. Las actividades de XP .................................................................................. 29
Tabla 5. Las prácticas en XP ...................................................................................... 31
Tabla 6. Las fases en el ciclo de vida XP ................................................................... 32
Tabla 7. Descripción Historia de Usuario: Diagrama de flujo ................................... 40
Tabla 8. Descripción Historia de Usuario: Diagrama de casos de uso ...................... 40
Tabla 9. Descripción Historia de Usuario: Diagrama de base de datos ..................... 40
Tabla 10. Descripción Historia de Usuario: Diagrama de arquitectura ..................... 41
Tabla 11. Descripción Historia de Usuario: Módulo reservas ................................... 41
Tabla 12. Descripción Historia de Usuario: Módulo administración y reportes........ 42
Tabla 13. Descripción Caso de Uso CU-01 ............................................................... 45
Tabla 14. Descripción Caso de Uso CU-02 ............................................................... 46
Tabla 15. Descripción Caso de Uso CU-03 ............................................................... 46
Tabla 16. Descripción Caso de Uso CU-04 ............................................................... 47
Tabla 17. Descripción Caso de Uso CU-05 ............................................................... 48
Tabla 18. Descripción Caso de Uso CU-06 ............................................................... 48
Tabla 19. Descripción Caso de Uso CU-07 ............................................................... 49
Tabla 20. Descripción Caso de Uso CU-08 ............................................................... 50
Tabla 21. Descripción Caso de Uso CU-09 ............................................................... 50
Tabla 22. Descripción Caso de Uso CU-10 ............................................................... 51
Tabla 23. Descripción Caso de Uso CU-11 ............................................................... 51
Tabla 24. Descripción Caso de Uso CU-12 ............................................................... 52
Tabla 25. Descripción Caso de Uso CU-14 ............................................................... 54
Tabla 26. Descripción Caso de Uso CU-15 ............................................................... 55
Tabla 27. Descripción Caso de Uso CU-17 ............................................................... 56
Tabla 28. Descripción Caso de Uso CU-18 ............................................................... 57
Tabla 29. Descripción Caso de Uso CU-19 ............................................................... 57
Tabla 30. Descripción Caso de Uso CU-20 ............................................................... 58
xv
Tabla 31. Descripción Caso de Uso CU-21 ............................................................... 59
Tabla 32. Descripción Caso de Uso CU-22 ............................................................... 60
Tabla 33. Descripción Caso de Uso CU-23 ............................................................... 60
Tabla 34. Descripción Caso de Uso CU-25 ............................................................... 61
Tabla 35. Descripción Caso de Uso CU-25 ............................................................... 62
Tabla 36. Descripción Caso de Uso CU-26 ............................................................... 62
Tabla 37. Descripción Caso de Uso CU-27 ............................................................... 63
Tabla 38. Descripción Caso de Uso CU-28 ............................................................... 64
Tabla 39. Descripción Caso de Uso CU-29 ............................................................... 65
Tabla 40. Descripción Caso de Uso CU-30 ............................................................... 65
Tabla 41. Descripción Caso de Uso CU-31 ............................................................... 66
Tabla 42. Template: template_con_sesion.xhtml....................................................... 78
Tabla 43. IngresarEspacioFisico.xhtml ...................................................................... 82
Tabla 44. EspacioFisicoBean.java ............................................................................. 83
Tabla 45. EspacioFisicoBacking.java ........................................................................ 88
Tabla 46. EspacioFisicoImpl.java .............................................................................. 90
Tabla 47. EspacioFisico.java ..................................................................................... 93
Tabla 48. Prueba de aceptación CU-01 ...................................................................... 95
Tabla 49. Prueba de aceptación CU-02 ...................................................................... 95
Tabla 50. Prueba de aceptación CU-03 ...................................................................... 96
Tabla 51. Prueba de aceptación CU-04 ...................................................................... 96
Tabla 52. Prueba de aceptación CU-05 ...................................................................... 97
Tabla 53. Prueba de aceptación CU-06 ...................................................................... 98
Tabla 54. Prueba de aceptación CU-07 ...................................................................... 98
Tabla 55. Prueba de aceptación CU-08 ...................................................................... 99
Tabla 56. Prueba de aceptación CU-09 ...................................................................... 99
Tabla 57. Prueba de aceptación CU-10 .................................................................... 100
Tabla 58. Prueba de aceptación CU-11 .................................................................... 100
Tabla 59. Prueba de aceptación CU-12 .................................................................... 101
Tabla 60. Prueba de aceptación CU-13 .................................................................... 101
Tabla 61. Prueba de aceptación CU-14 .................................................................... 102
Tabla 62. Prueba de aceptación CU-15 .................................................................... 102
Tabla 63. Prueba de aceptación CU-16 .................................................................... 103
Tabla 64. Prueba de aceptación CU-17 .................................................................... 103
xvi
Tabla 65. Prueba de aceptación CU-18 .................................................................... 104
Tabla 66. Prueba de aceptación CU-19 .................................................................... 104
Tabla 67. Prueba de aceptación CU-20 .................................................................... 105
Tabla 68. Prueba de aceptación CU-21 .................................................................... 105
Tabla 69. Prueba de aceptación CU-22 .................................................................... 106
Tabla 70. Prueba de aceptación CU-23 .................................................................... 106
Tabla 71. Prueba de aceptación CU-24 .................................................................... 107
Tabla 72. Prueba de aceptación CU-25 .................................................................... 107
Tabla 73. Prueba de aceptación CU-26 .................................................................... 108
Tabla 74. Prueba de aceptación CU-27 .................................................................... 108
Tabla 75. Prueba de aceptación CU-28 .................................................................... 109
Tabla 76. Prueba de aceptación CU-29 .................................................................... 109
Tabla 77. Prueba de aceptación CU-30 .................................................................... 110
Tabla 78. Prueba de aceptación CU-31 .................................................................... 110
xvii
RESUMEN
SISTEMA PARA LA GESTIÓN Y
RESERVACIÓN
DE SALAS, GALERÍAS,
AUDITORIOS Y TEATROS DE LA SEDE NACIONAL DE CASA DE LA
CULTURA ECUATORIANA
El presente trabajo de graduación permite a la Casa de la Cultura Ecuatoriana
“Benjamín Carrión” llevar un control adecuado en el préstamo de sus instalaciones
con el fin de difundir y apoyar a los artistas y eventos, que fomenten el arte y cultura
ecuatoriana.
El proyecto consiste en el desarrollo de un sistema de gestión para reservaciones de
instalaciones. En dicha gestión se incluyen reservaciones, clientes (tanto nacionales
como extranjeros), instalaciones, reportes, entre otros.
El proceso de desarrollo de este proyecto se basa en la metodología ágil de
Programación Extrema XP, pues es capaz de adaptarse a los cambios de requisitos en
cualquier punto de vida del proyecto. Además las tecnologías utilizadas durante el
desarrollo son orientadas a la web, proporcionando su posterior puesta en producción
y mantenimiento.
DESCRIPTORES:
SISTEMA DE INFORMACIÓN PARA GESTIÓN DE RESERVAS / JAVA / JPA /
EJB / JSF / POSTGRESQL / METODOLOGÍA XP / RICHFACES
xviii
ABSTRACT
MANAGEMENT SYSTEM AND RESERVATION OF ROOMS, GALLERIES,
AUDITORIUM AND THEATRE OF SEDE NACIONAL DE LA CASA DE LA
CULTURA ECUATORIANA
This paper graduation allows the Casa de la Cultura Ecuatoriana "Benjamín Carrión" for
proper controls in lending facilities to disseminate and support the artists and events that
promote art and Ecuadorian culture.
The project involves the development of a management system for reservations facilities.
In this management reservations, customers (both domestic and foreign), calendar of
activities, reports, etc. are included.
The development process of this project is based on agile methodology eXtreme
Programming XP, it is able to adapt to changing requirements at any point in the project
life. Besides the technologies used during development are oriented web, providing
subsequent start of production and maintenance.
DESCRIPTORS:
MANAGEMENT INFORMATION SYSTEM FOR BOOKING / JAVA / JPA / EJB /
JSF / POSTGRESQL / METHODOLOGY XP / RICHFACES
xix
xx
xxi
CAPÍTULO 1
1.1 INTRODUCCIÓN
Debido a los enormes cambios sufridos por el mercado en los últimos años con la
incorporación de tecnologías informáticas que facilitan la administración de los datos
para ofrecer mejoras en la toma de decisiones gerenciales, en la actualidad todas las
instituciones públicas y privadas, requieren de la implementación de un sistema de
información que colabore con los procesos de gestiones empresariales.
Con el fin de mejorar la productividad y el rendimiento de una institución
competitiva, es fundamental evaluar las técnicas actuales y la tecnología disponible
para desarrollar sistemas que brinden eficiencia y eficacia de la gestión de la
información relevante.
La implementación de sistemas de información en una institución, brindan la
posibilidad de obtener grandes ventajas, y tornar de esta manera los procesos a una
verdadera competitividad. Para ello, es necesario un sistema eficaz que ofrezca
múltiples posibilidades, permitiendo acceder a los datos relevantes de manera
frecuente y oportuna.
El diseño, desarrollo e implementación del Sistema para la gestión y reservación de
salas, galerías, auditorios y teatros de la Sede Nacional de la Casa de la Cultura
Ecuatoriana, SICCE-TS, será la solución para automatizar los procesos que
conllevan la coordinación y realización de las actividades diarias a llevarse a cabo en
las salas, galerías, auditorios y teatros a fin de disminuir en lo posible confusiones
con el alquiler o prestación de las instalaciones.
El propósito del sistema es facilitar el proceso de reservas de las instalaciones
destinadas a la presentación de eventos artísticos-culturales, generando información
útil para los directores de los diferentes departamentos de la Sede Nacional de la
Casa de la Cultura Ecuatoriana.
1
1.2 PLANTEAMIENTO DEL PROBLEMA
En la Sede Nacional de la Casa de la Cultura Ecuatoriana “Benjamín Carrión” (CCE)
a la que llamaremos Institución para fines de comprensión; la gestión de las áreas
físicas para la realización de eventos artísticos-culturales se realiza de manera
independiente. Se realizan las reservaciones aproximadamente con dos meses de
anticipación, y los procesos de aprobación de reservaciones y préstamos de las áreas
físicas para eventos tardan un tiempo aproximado de tres semanas.
Además de la falta de una agenda electrónica que permita coordinar la realización de
los eventos artístico-culturales entre las distintas direcciones administrativas de la
Institución.
Se evidencia una administración independiente de las áreas físicas para los eventos,
no existe ningún punto central de información además de existir varios
intermediarios en los procesos.
1.3 FORMULACIÓN DEL PROBLEMA
¿Cómo automatizar la gestión de reservas y de los clientes, para reducir tiempos de
espera en las reservaciones, agilizar el trabajo manual, mejorar la interacción del
cliente y la planificación de eventos a realizarse en las diferentes instalaciones de la
Institución?
1.4 INTERROGANTES DE LA INVESTIGACIÓN
El presente tema de tesis surge de la inconformidad por parte de los empleados y
clientes de la Institución, los cuales interaccionan entre sí para llevar a cabo el
proceso de reservación de las instalaciones. Existen inconvenientes que surgen tanto
dentro como fuera de la Institución, lo que no permite brindar un servicio el cual sea
satisfactorio tanto para el empleado como para el cliente, ya que aún se realiza la
manipulación de la información en base a registros físicos, dando paso a que la
transmisión del conocimiento hacia los demás departamentos de la Institución sea
insuficiente e ineficiente.
2
Dentro de la investigación se desea contestar las siguientes interrogantes:

¿Cómo beneficiará la propuesta del diseño, desarrollo e implementación del
Sistema para la Gestión y Reservación de salas, teatros, galerías y auditorios
de la Sede Nacional de la CCE, en cuanto se refiere a mejorar
significativamente la atención al cliente además de la mejora en el aspecto
administrativo para la Institución?

¿Cuáles son las actividades que realizan el cliente y el personal
administrativo?

¿Qué técnicas y métodos se utilizarán en el sistema para el análisis de datos
de los clientes utilizando la investigación exploratoria y descriptiva para
obtener los datos de una manera coherente, ajustándose a la investigación
deseada?

¿Cómo se beneficiaría la Sede Nacional de la CCE “Benjamín Carrión” de las
nuevas tecnologías en herramientas de software libre?
1.5 OBJETIVOS DE LA INVESTIGACIÓN
1.5.1 Objetivo General
Implantar un sistema que permita realizar la gestión y reservación en línea de las
salas, teatros, galerías y auditorios de la Sede Nacional de la CCE “Benjamín
Carrión”, en el desarrollo de los diferentes eventos artísticos, culturales y educativos
nacionales e internacionales.
1.5.2 Objetivo Específicos

Mantener una base de datos de los clientes.
3

Gestionar simultáneamente las salas, galerías, auditorios,
teatros y sus
recursos.

Disminuir los tiempos de reservación y aprobación de las salas, galerías,
auditorios y teatros.

Mejorar la interacción entre los empleados y los clientes.

Permitir al cliente informarse de los servicios por Internet.

Emitir índices de utilización, preferencia de los clientes a partir del análisis de
datos provenientes del sistema.
1.6 JUSTIFICACIÓN
Actualmente los procesos se consideran como la base operativa de gran parte de las
instituciones, y progresivamente se van convirtiendo en la base estructural de las
mismas permitiendo definir con claridad las etapas y actividades de un proceso para
los diferentes departamentos.
Por ende la gestión de una organización a través de procesos resulta un medio de
gran importancia para definir un marco de referencia para la realización y
coordinación de las actividades diarias.
En la actualidad la Administración Pública es la más interesada en mejorar la forma
en la que presenta sus servicios a la sociedad por el creciente uso de la tecnología,
ya que representa una gran importancia en la gestión de las actividades a través de
procesos.
La importancia que representa mejorar los procesos de la CCE, continuamente lleva
a adquirir nuevas herramientas de gestión de la información; para solventar esta
necesidad se motiva el diseño, desarrollo e implementación del Sistema para la
gestión y reservación de salas, teatros, galerías y auditorios de la CCE, el cual tiene
como objetivo principal agilitar los procesos de reservaciones de los espacios físicos
4
para la realización de eventos, basándose en la automatización de recursos, logrando
de una forma directa que el usuario realice su reserva a través de la Internet, y
reduciendo la cantidad del trabajo de los administrativos que lo vienen haciendo en
forma manual.
Debido al problema de que existe información almacenada en registros físicos tales
como: hojas, libros de registros diarios de visitas escritas a mano, cartillas y
cronogramas de reserva, para funciones del personal representa una gran cantidad de
trabajo para que se pueda obtener información gerencial. Los beneficiarios directos
serán los clientes y el personal administrativo de la Institución, ya que con
información a nivel superior pueden tomar decisiones de acuerdo a las preferencias y
tendencias de uso del cliente.
El sistema permitirá crear reportes personalizados a partir de parámetros utilizados
por el personal administrativo. Logrando ver de mejor manera cómo está
funcionando el proceso de reservas, siendo este un beneficio para los directores de
cada departamento a fin de reducir el tiempo de recolección de datos para realizar un
análisis, al tener una herramienta parametrizable para el trabajo que llevan a cabo.
Con la implementación de este sistema, se puede llegar de una manera eficaz a sus
clientes con información exacta sobre sus reservaciones, para brindar una atención
personalizada continua.
1.7 ALCANCE

SICCE-TS presentará un listado de las instalaciones de tal manera que el
cliente pueda visualizar información relevante de cada una de las salas,
galerías, auditorios o teatros.

SICCE-TS presentará un calendario de eventos a realizarse.

SICCE-TS permitirá que los clientes registren sus datos, realicen la
reservación de una sala, galería, auditorio o teatro, ingresen información
5
sobre el evento a llevarse a cabo: descripción, fecha y hora de inicio,
fecha y hora de finalización, verifique el estado de la reservación por
medio de un correo electrónico.

SICCE-TS servirá a los administrativos para revisar, realizar búsquedas
por filtros, actualizar, eliminar, aprobar o rechazar las reservaciones
ingresadas con anterioridad.
1.8 LIMITACIONES
Las limitaciones del sistema son las siguientes:

No se contempla la adquisición de hardware para la implementación del
sistema. La Sede Nacional de la CCE “Benjamín Carrión” y en
particular la Dirección de Sistemas, está encargada de realizar la gestión
respectiva para la implantación del mismo en la Web.

El proyecto no está enfocado en la integración del sistema de
mencionado con los sistemas de información que se encuentran
funcionando actualmente dentro de la Institución, a pesar de esto, el
sistema puede funcionar de manera independiente, y es fácilmente
integrable con otros.

El sistema no incluye desarrollo de pantallas para los departamentos
colaterales que están involucrados en el proceso de reservas de la CCE,
ya que no se contempló como un objetivo en la tesis.

No se envían alertas a dispositivos móviles.

El SICCE-TS cumplirá solamente lo determinado en el alcance del
proyecto.
6
CAPÍTULO 2
2.1 ANTECEDENTES
En base al estudio realizado en la tesis: ELABORACIÓN DEL PLAN
ESTRATÉGICO INFORMÁTICO PARA LA CASA DE LA CULTURA
ECUATORIANA, se pudo determinar que la Sede Nacional de la Casa de la Cultura
Ecuatoriana “Benjamín Carrión” tiene varias falencias organizacionales que
producen quejas por parte de los usuarios finales y retraso en la ejecución de
procesos.
Producto de este estudio se definieron varios proyectos objetivos los mismos que son
el resultado del análisis de procesos institucionales, requerimientos actúales y
futuros, nuevas necesidades y oportunidades, los cuales permitirán mejorar la gestión
de las tecnologías de la información y automatizar los procesos de la Institución.
Uno de los proyectos objetivos y de alta prioridad es: Sistema para la gestión y
reservación de salas, galerías, auditorios y teatros de la Sede Nacional de la CCE.
El trabajo a realizar facilitará que aquellas personas involucradas y que están en
permanente contacto con las actividades que con lleva la reservación y gestión de
salas, teatros, auditorios y galerías cuenten con una herramienta que facilite su
trabajo dentro y fuera de la Institución.
Basándose en el trabajo que fue realizado para el mejoramiento de la Institución, la
intención es actuar de una forma directa para cumplir con el desarrollo e
implantación del sistema sugerido.
2.2 FUNDAMENTACIÓN TEÓRICA
Para el desarrollo de este tema de tesis se necesita de ciertas herramientas que serán
básicas para un desarrollo del trabajo final de graduación. A continuación se hace
una breve descripción de cada una de las herramientas seleccionadas en la
investigación del proyecto.
7
2.2.1 Plataforma de desarrollo
2.2.1.1 Lenguaje de Programación JAVA
Java es un lenguaje orientado a objetos de propósito general, se usa para el desarrollo
de aplicaciones que convierten a la Web en un elemento más interesante y útil. Está
desarrollado por la compañía Sun Microsystems, con gran dedicación y siempre
enfocado a cubrir las necesidades tecnológicas más punteras.
La principal característica de Java es la de ser un lenguaje compilado e interpretado.
Todo programa en Java ha de compilarse y el código que se genera bytecodes es
interpretado por una máquina virtual. De este modo se consigue la independencia de
la máquina, el código compilado se ejecuta en máquinas virtuales que si son
dependientes de la plataforma.
Otras de las características por las cuales se ha seleccionado este lenguaje de
programación para desarrollar el presente trabajo son:

Es fácil de aprender y está bien estructurado.

Es un lenguaje orientado a objetos, de una plataforma independiente.

Fue diseñado para crear software altamente fiable. Para ello proporciona
numerosas comprobaciones en tiempo de compilación y en tiempo de
ejecución.

Los programas “ejecutables”, creados por el compilador de Java, son
independientes de la arquitectura.

Se ejecutan indistintamente en una gran variedad de equipos con diferentes
microprocesadores y sistemas operativos.
8

Proporciona una colección de clases para su uso en aplicaciones de red, que
permiten abrir sockets, establecer y aceptar conexiones con servidores o
clientes remotos, facilitando así la creación de aplicaciones distribuidas.
2.2.1.2 JEE6 (Java Enterprise Edition)
Es un estándar que define una arquitectura para implementar servicios como lo hacen
las aplicaciones multicapa, las cuales son escalables, accesibles y pone a disposición
del programador un conjunto de APIs para el desarrollo de aplicaciones
empresariales que requieren altos niveles de confiabilidad, seguridad y rendimiento.
El presente proyecto se realizará sobre la plataforma de desarrollo JEE versión 6. La
cual permite desarrollar y ejecutar software de aplicaciones en lenguaje de
programación Java con arquitectura de N capas distribuidas, que se apoya en
componentes de software modulares que a la vez se despliegan sobre un servidor de
aplicaciones llamado contenedor JEE.
2.2.1.3 Aplicaciones Web
Se denomina aplicación web a la herramienta o aplicación de software que usan
usuarios mediante un navegador para acceder a un servidor web por medio del
Internet y lograr una comunicación entre usuario e información.
Java ofrece las siguientes tecnologías para el desarrollo de aplicaciones Web.
2.2.1.4 Tecnologías en la capa de Presentación
Java Server Faces (JSF)
La tecnología Java Server Faces es un marco de desarrollo de los componentes de la
interfaz de usuario.

El código JSF con el que creamos las vistas (etiquetas jsp) es muy parecido al
HTML estándar.
9

Se integra dentro de la página JSP y se encarga de recoger y generar los
valores de los elementos de la página

Resuelve validaciones, conversiones, mensajes de error e internacionalización
(i18n)

Admite introducir JavaScript en la página, para acelerar la respuesta de la
interfaz en el cliente (navegador del usuario).

Es extensible, por lo que se pueden desarrollar nuevos componentes a
medida, también se puede modificar el comportamiento del framework
mediante APIs que controlan su funcionamiento.
Richfaces
Es una librería de componentes visuales para JSF, posee un framework avanzado
para la integración de funcionalidades Ajax en dichos componentes visuales,
mediante el soporte de la librería Ajax4JSF.

Se integra perfectamente en el ciclo de vida de JSF

Incluye funcionalidades Ajax, de modo que nunca vemos el JavaScript y
tiene un contenedor Ajax propio

Contiene un conjunto de componentes visuales, con un número bastante
amplio que cubren casi todas nuestras necesidades

Soporta facelets, css, themes o skins
Ajax (Asynchronous JavaScript y XML)
Grupo de técnicas de desarrollo Web utilizados en el lado del cliente para crear
aplicaciones Web asíncronas.
10

Con Ajax, las aplicaciones Web pueden enviar y recuperar datos de un
servidor de forma asincrónica sin interferir con la visualización y el
comportamiento de la página existente.

Los datos pueden ser recuperados mediante el objeto XMLHttpRequest.
Ajax4Jsf
Es una librería de código abierto que se integra totalmente en la arquitectura de JSF y
extiende la funcionalidad de sus etiquetas dotándolas con tecnología Ajax de forma
limpia y sin añadir código Java Script.

Mediante este framework se puede variar el ciclo de vida de una petición JSF.

Recargar determinados componentes de la página sin necesidad de recargarla
por completo

Realizar peticiones al servidor automáticas.

Control de cualquier evento de usuario.
Facelets
Es un poderoso pero ligero idioma de declaración de página que se utiliza para
construir vistas JavaServer Faces utilizando plantillas de estilo HTML y construir
árboles de componentes.

El uso de XHTML para crear páginas Web

El apoyo a las bibliotecas de etiquetas Facelets además de JavaServer Faces y
librerías de etiquetas JSTL

Apoyo al Expression Language (EL)
11

Plantillas para los componentes y las páginas

El apoyo a la reutilización de código a través de plantillas y componentes de
materiales compuestos

Extensibilidad funcional de componentes y otros objetos del lado del servidor
a través de la personalización

Menor tiempo de compilación y validación en tiempo de compilación.
Lenguaje de Marcado de Hipertexto Extensible (XHTML)
Es una versión más estricta y limpia de HTML, que nace precisamente con el
objetivo de remplazar a HTML ante su limitación de uso con las cada vez más
abundantes herramientas basadas en XML.

Al estar orientado al uso de un etiquetado correcto, exige una serie de
requisitos básicos a cumplir. Entre estos requisitos básicos se puede
mencionar una estructuración coherente dentro del documento donde se
incluirían elementos correctamente anidados, etiquetas en minúsculas,
elementos cerrados correctamente, atributos de valores entrecomillados, etc.

Extiende HTML 4.0 combinando la sintaxis de HTML, diseñado para mostrar
datos, con la de XML, diseñado para describir los datos.

Surge como el lenguaje cuyo etiquetado, más estricto que HTML, va a
permitir una correcta interpretación de la información.
Extensible Markup Language (XML)
No es sólo un lenguaje, es una forma de especificar lenguajes. Es un leguaje de
etiquetas no predefinidas previamente, es decir, el programador es el que las crea en
cada caso.
12

Ahorra tiempos de desarrollo y proporciona ventajas, dotando a las
aplicaciones Web de una forma realmente potente para guardar la
información.

Se ha convertido en un formato universal para el intercambio de información
estructurada entre diferentes plataformas.

En la actualidad permite la compatibilidad entre sistemas para compartir la
información.
Java Script
Es un lenguaje de programación interpretado, es decir, no requiere de compilación ya
que el lenguaje funciona del lado del cliente.

Tiene como principal característica ser un lenguaje independiente de la
plataforma.

Los navegadores son los encargados de interpretar estos códigos.

Tiene la ventaja de ser incorporado en cualquier página Web, puede ser
ejecutado sin la necesidad de instalar otro programa para ser visualizado.
2.2.1.5 Tecnologías en la capa de Negocio
Servidor de Aplicaciones JBOSS
JBoss es un servidor de aplicaciones para Java. Es muy reconocido por ser de los
primeros servidores de aplicación empresarial gratuito y de código abierto. Al estar
basado en Java, puede ser utilizado en cualquier sistema operativo que lo soporte,
ofreciendo una plataforma de alto rendimiento para aplicaciones java, aplicaciones
Web y portales.
13
Enterprise Java Beans (EJB)
Es un modelo de programación que nos permite construir aplicaciones Java mediante
objetos ligeros. Los EJB son componentes del contexto de servidor que cubren la
necesidad de intermediar entre la capa Web y diversos sistemas empresariales.
Los EJB están especialmente pensados para integrar la lógica de la empresa que se
encuentra en sistemas distribuidos, de tal forma que el desarrollador no tenga que
preocuparse por la programación a nivel de sistema (como control de transacciones,
seguridad, etc.), sino que se centre en la representación de entidades y reglas de
negocio.
Existen tres tipos de Enterprise Java Beans:
ENTERPRISE JAVA BEANS
Entity beans
Session beans
Message-driven beans
PRÓPOSITO
Representan entidades de negocio y proveen
acceso a los datos a través de métodos. Se basan
en la idea del mapeo objeto/relacional.
Pensados para modelar procesos de negocio que
son accedidos de manera síncrona
Pensados para modelar procesos de negocio que
son accedidos de manera asíncrona, permiten el uso
de JMS desde EJBs
Tabla 1. Tipos de EJB´s
Para el desarrollo de este sistema, se elige los Entity Beans y los Session Beans por
el ahorro de trabajo que resulta una vez desarrollada la aplicación, podemos
desplegarla en cualquier contenedor compatible con EJB, beneficiándonos de todo el
trabajo que el contenedor gestiona por nosotros. De esta manera la lógica de negocio
se mantiene independiente de otro código que pueda ser necesario, resultando en
código que es más fácil de escribir y mantener.
En la especificación 3.0, los Enterprise Beans no son más que simples POJO (Plain
Old Java Objects). En otras palabras, son clases planas comunes y corrientes de Java.
Dichas clases pueden ser configuradas por programadores usando anotaciones
(annotations, también llamados metadata), con la finalidad de agregar diferentes
servicios que deberá proveer el servidor de aplicaciones.
14
En la Figura 1 se ilustra como una anotación transforma un simple POJO en un EJB.
Figura 1. Interpretación de un EJB
2.2.1.6 Tecnologías en la capa de Acceso a Datos
Java Persistence API (JPA)
JPA proporciona un modelo de persistencia basado en POJO's para mapear bases de
datos relacionales en Java. La persistencia de Java fue desarrollada por expertos de
EJB 3.0 como parte de JSR 220, aunque su uso no se limita a los componentes
software EJB. Se puede utilizar en aplicaciones Web y aplicaciones clientes.
El mapeo objeto-relacional, es decir, la relación entre entidades Java y tablas de la
base de datos se realiza mediante anotaciones en las propias clases de entidad.
Para entender JPA, tendremos que tener claro el concepto "persistencia". La
persistencia o el almacenamiento permanente, es una de las necesidades básicas de
cualquier sistema de información.
En primer lugar, se propuso que el programa tratara los datos haciendo consultas
directas a la base de datos. Después, se propuso trabajar con objetos, pero las bases
de datos tradicionales no admiten esta opción.
Debido a esta situación, aparecieron los motores de persistencia, cuya función es
traducir entre los dos formatos de datos: de registros a objetos y de objetos a
registros.
15
Persistir objetos Java en una base de datos relacional implica serializar un árbol de
objetos Java en una base de datos de estructura tabular y viceversa. Esencial es la
necesidad de mapear objetos Java para optimizar velocidad y eficiencia de la base de
datos.
Unidad de persistencia
La unidad de persistencia define un conjunto de todas las entidades (clases) que son
gestionadas por la instancia del EntityManager en una aplicación. Este conjunto de
clases de entidad representa los datos contenidos en una única base de datos.
Las unidades de persistencia se definen en el fichero de configuración
persistence.xml, en la Figura 2 se muestra dicho archivo de configuración para
SICCE-TS.
Figura 2. Configuración persistence.xml SICCE-TS
La persistencia puede tener 4 estados diferentes:
Transient: Un objeto recién creado que no ha sido enlazado con el gestor de
persistencia.
16
Persistent: Un objeto enlazado con la sesión (todos los cambios serán persistentes).
Detached: Un objeto persistente que sigue en memoria después de que termina la
sesión: existe en java y en la base de datos.
Removed: Un objeto marcado para ser eliminado de la base de datos: existe en java y
se borrará de la base de datos al terminar la sesión.
JPA - Entity Manager
Antes que nada tenemos que tener bien en claro dos temas muy importantes que son:

Application-managed entity manager

Container-managed entity manager
Para las situaciones en donde no requerimos los servicios ofrecidos por un EJB3
container, pero se quiera utilizar el modelo de persistencia de JPA, el API JPA
provee el Application-managed entity manager. En estos casos las aplicaciones son
denominadas aplicaciones standalone.
Estas aplicaciones que corren fuera de un EJB3 container usarán el resource-local
transaction provisto por el entity manager, lo que permite que la aplicación sea la
encargada de manejar el ciclo de vida del entity manager.
Para las situaciones en donde sí se requiera de los servicios de un EJB3 container
(como por ejemplo JBoss ó WebLogic application server), el API JPA provee el
Container-managed entity manager.
Siempre que una transacción sea iniciada, un nuevo contexto de persistencia
(persistence context) es creado. Esto es así tanto para el Application-managed entity
manager como también para el Container-managed entity manager.
Para el caso del Application-managed entity manager, la aplicación es la encargada
de abrir y cerrar la transacción. Para el caso del Container-managed entity manager,
la transacción es iniciada cuando se invoque desde el cliente al EJB (a un stateless
session bean, ahora bien, para los stateful session bean el comportamiento de las
17
transacciones es distinto). La transacción termina cuando finaliza la ejecución del
método del session bean.
Arquitectura JPA
Figura 3. Relaciones entre los componentes primarios de la arquitectura JPA1
Los cuatro tipos de interfaces de las que se compone la arquitectura JPA son:

javax.persistence.Persistence: Contiene métodos estáticos de ayuda para
obtener una instancia de Entity Manager Factory de una forma independiente
al vendedor de la implementación de JPA. Una clase de inicialización que va
proporcionar un método estático para la creación de una Entity Manager
Factory.

javax.persistence.EntityManagerFactory: Nos ayuda a crear objetos de
EntityManager utilizando el patrón de diseño del Factory. Este objeto en
tiempo de ejecución representa una unidad de persistencia particular.
Generalmente va a ser manejado como un singleton y proporciona métodos
para la creación de instancias EntityManager.
1
Fuente: Obtenida el 15 de marzo, 2015 de: <http://openjpa.apache.org/builds/1.2.3/apacheopenjpa/docs/jpa_overview_arch.html>
18

javax.persistence.Entity: es una anotación Java que se coloca a nivel de clases
Java serializables y que cada objeto de una de estas clases anotadas
representa un registro de una base de datos.

javax.persistence.EntityManager: Es la interfaz principal de JPA utilizada
para la persistencia de las aplicaciones. Cada Entity Manager puede realizar
operaciones CRUD (Create, Read, Update, Delete) sobre un conjunto de
objetos persistentes. Es un objeto único, no compartido que representa una
unidad de trabajo particular para el acceso a datos. Proporciona métodos para
gestionar el ciclo de vida de las instancias entidad y para crear instancias
Query.

javax.persistence.Query: JPA estandariza el soporte para consultas utilizando
Java Persistence Query Language (JPQL) y Structured Query Language
(SQL). Podemos obtener una instancia de Query desde una instancia de un
Entity Manager.

javax.persistence.EntityTransaction: Cada instancia de Entity Manager tiene
una
relación
de
uno
a
javax.persistence.EntityTransaction,
uno
permite
con
una
operaciones
instancia
sobre
de
datos
persistentes de manera que agrupados formen una unidad de trabajo
transaccional, en el que todo el grupo sincroniza su estado de persistencia en
la base de datos o todos fallan en el intento, en caso de fallo, la base de datos
quedará con su estado original. Maneja el concepto de todos o ninguno para
mantener la integridad de los datos.
Entidades
Una entidad es un objeto de dominio de persistencia. Normalmente, una entidad
representa una tabla en el modelo de datos relacional y cada instancia de esta entidad
corresponde a un registro en esa tabla.
El estado de persistencia de una entidad se representa por medio de campos
persistentes o propiedades persistentes. Estos campos o propiedades usan
19
anotaciones para el mapeo de estos objetos en el modelo de base de datos.
El estado persistente de una entidad puede ser accesible a través de variables de
instancia a la entidad o bien a través de las propiedades de estilo de JavaBean. Las
entidades podrán usar campos persistentes o propiedades. Si las anotaciones de
mapeo se aplican a las instancias de las entidades, la entidad utiliza campos
persistentes, en cambio, si se aplican a los métodos getters de la entidad, se usarán
propiedades persistentes. Hay que tener en cuenta que no es posible aplicar
anotaciones tanto a campos como a propiedades en una misma entidad.
Una entidad pasará a ser manejada por el contexto de persistencia de JPA cuando
ésta sea persistida. En este punto, la entidad pasará a estar asociada a lo que
comúnmente llamamos el contexto de persistencia. En este caso, y mientras la
entidad sea manejada/asociada por el contexto de persistencia (también se las conoce
como entidades atachadas o attached entities), el estado (valores de la propiedades)
de la entidad será automáticamente sincronizado con la base de datos.

Campos de persistencia permanente: Si la entidad utiliza campos de
persistencia permanente, los accesos se realizan en tiempo de ejecución.
Aquellos
campos
que
no
tienen
anotaciones
del
tipo
javax.persistence.Transient o no han sido marcados como Java transitorio
serán persistentes para el almacenamiento de datos. Las anotaciones de
mapeo objeto/relación deben aplicarse a los atributos de la instancia.

Propiedades de persistencia permanente: Si la entidad utiliza propiedades de
persistencia permanente, la entidad debe seguir el método de los convenios de
componentes JavaBeans. Las propiedades de JavaBean usan métodos getters
y setters en cuyo nombre va incluido el atributo de la clase al cual hacen
referencia. Si el atributo es booleano podrá utilizarse isProperty en lugar de
getProperty.
20
2.2.1.7 Herramientas de desarrollo
Eclipse IDE
IDE o entorno de desarrollo integrado está diseñado para el desarrollo de
aplicaciones, cuyo propósito es facilitar la construcción de software disminuyendo
tiempo y complejidad. En pocas palabras representa a un editor de código, un
compilador, un depurador y un constructor de interfaz gráfica (GUI).
Algunas de las razones para seleccionar un IDE que facilite al programador cumplir
las tareas encomendadas, se presentan a continuación:

Generación automática de código.

Presentación de errores y advertencias

Permite realizar depuración de código.

Permite una fácil integración con sistemas de control de versiones como
SVN, CVS.

Ejecución de pruebas unitarias.

Permite la generación de JavaDoc.
En la actualidad Eclipse se puede considerar un IDE de código abierto y
multiplataforma, por esta razón SICCE-TS se desarrollará sobre Eclipse en la versión
Juno Release.
Gestor de Base de Datos PostgreSql
Para el desarrollo del presente proyecto se escogió como motor de base datos
PostgreSQL, por su ventaja de ser código abierto, y brindar estabilidad y confiabilidad.
21
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido
bajo licencia BSD y con su código fuente disponible libremente.
Estas son algunas de sus características:

Su administración se basa en usuarios y privilegios.

Diseñado para ambientes de alto volumen.

Herramientas gráficas de diseño y administración de bases de datos.

Instalación ilimitada.

Mejor soporte que los proveedores comerciales.

Ahorros considerables en costos de operación.

Multiplataforma

Alta concurrencia.

Extensible.

Diseñado para ambientes de alto volumen.

Gran capacidad de almacenamiento.

Buena escalabilidad.

Es altamente confiable en cuanto a estabilidad se refiere.

Soporte.
22
Servidor de aplicaciones JBOSS
Para el desarrollo del sistema se ha seleccionado como servidor de aplicaciones a JBoss
Application Server por las siguientes razones:

Es un servidor de aplicaciones de código abierto.

Servidor robusto y de alto rendimiento diseñado para aplicaciones de negocio
que se integra y aprovecha las funcionalidades y ventajas de una arquitectura
SOA.

Soporta la utilización de la especificación de Enterprise Java Beans 3.0, API
utilizado para el desarrollo de los servicios.

El uso de memoria es menor a las versiones anteriores.

La versión de JBoss utilizada para el presente trabajo es JBoss Application
Server versión 7.1.1 ya que proporciona una arquitectura compatible con la nube,
además de que el tiempo de arranque del mismo es mucho menor a los de sus
predecesores.
Figura 4. Estructura de directorios de JBoss7.1.1
23
Lenguaje de modelamiento UML
En el presente proyecto se utiliza UML para apoyar las tareas de planificación y
diseño de XP en el desarrollo del sistema Web.
La notación UML (no hay que confundir con las metodologías que utilizan dicha
notación), se ha convertido desde finales de los 90 en un estándar para modelar, con
tecnología orientada a objetos, todos aquellos elementos que configuran la
arquitectura de un sistema de información y, por extensión, de los procesos de
negocio de una organización.
Los diagramas UML suministran un modelo de referencia para formalizar los
procesos, reglas de negocio, objetos y componentes de una organización. La
interacción de todos estos elementos es una representación de nuestra realidad.
Plataforma de construcción de páginas Web JSF
Se utilizará JSF como marco de trabajo para la construcción de las páginas Web del
sistema, aprovechando la ventaja de que JSF forma parte de Java EE.
JSF es capaz de simplificar la construcción de páginas Web, ya que la programación
de la interfaz de usuario se la realiza a través de componentes y basada en eventos.
JSF es un marco de trabajo para crear aplicaciones Java EE (Java Enterprise Edition)
basadas en el patrón Modelo Vista Controlador (MVC). Esta tecnología simplifica la
construcción de interfaces de usuario. Los desarrolladores pueden construir
rápidamente aplicaciones Web, ensamblando componentes de interfaces de usuario
(UI) reusables en una página, conectando estos componentes a una aplicación de
datos, y enlazando los eventos generados por el cliente con el manejador de eventos
del lado del servidor.
2.3 IDENTIFICACIÓN DE VARIABLES
La identificación de variables se realiza en función de los parámetros que definen la
calidad de un proceso o servicio, en el caso del presente trabajo identificamos las
24
variables en las que el software puede mejorar el proceso. Las variables que están
fuera del alcance del software se las tomará como un parámetro constante.
2.3.1 Variables
Tiempos de respuesta, disponibilidad, planificación de visitas, identificación de
tendencias del cliente.
Variable Independiente
Interacción entre el cliente y la Institución.
Variable Dependiente
La calidad del proceso de realizar y coordinar reservaciones.
2.4 HIPÓTESIS
La implementación del Sistema para la gestión y reservación de salas, galerías,
auditorios y teatros de la Sede Nacional de Casa de la Cultura Ecuatoriana
“Benjamín Carrión”, permitirá la automatización de las reservaciones y la generación
de una base de datos para su análisis, así como una mejora en la interacción del
personal involucrado con las reservas de de salas, teatros, auditorios y galerías, con
los clientes y público en general.
25
CAPÍTULO 3
3.1 DISEÑO DE LA INVESTIGACIÓN
En la parte inicial del desarrollo de este sistema se utilizó la técnica de la entrevista
para reunir información proveniente de los empleados de la CCE, así como la
observación del funcionamiento de procesos actuales, ya que permite explicar los
eventos u ocurrencias con ejemplos reales.
Se categorizaron las prioridades según la jerarquía de los empleados de los
departamentos involucrados así como del personal que se vio afectado positiva o
negativamente en el desarrollo del sistema.
Una vez que se ha validado los requerimientos se procedió a la construcción del
sistema, para ello se adoptó a Extreme Programming (XP) como metodología de
desarrollo. Como preludio, en las siguientes secciones (3.1.1 hasta el 3.1.7) se detalla
claramente en que consiste la metodología XP de manera que se pueda justificar el
uso de la misma en el desarrollo del presente proyecto.
3.1.1 Definición de Extreme Programming (XP)
Es una metodología ágil centrada en potenciar las relaciones interpersonales como
clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo,
preocupándose por el aprendizaje de los desarrolladores, y favoreciendo un buen
clima de trabajo.
XP se basa en la realimentación continua entre el cliente y el equipo de desarrollo,
comunicación fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes,
y donde existe un alto riesgo técnico.
Es así que XP se puede definir como:

Metodología liviana de desarrollo de software.
26

Conjunto de prácticas y reglas empleadas para desarrollar software.

Basada en diferentes ideas acerca de cómo enfrentar ambientes muy
cambiantes.

En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto
un poco cada vez, a través de todo el proceso de desarrollo
De manera global, XP la conforman cuatro partes fundamentales: valores, principios,
actividades y prácticas.
3.1.2 Los valores de XP
XP inicia con un conjunto de valores compartidos por el equipo de desarrollo y el
cliente. Estos valores explicados en la Tabla 2, constituyen el enfoque de un
desarrollo con XP.
VALOR
Comunicación
DESCRIPCIÓN
Algunos problemas en los proyectos tienen
origen en que alguien no dijo algo importante
en algún momento. XP hace imposible la falta
de comunicación.
Simplicidad
XP propone el principio de hacer la cosa más
simple que pueda funcionar, en relación al
proceso y la codificación. Es mejor hacer hoy
algo simple, que hacerlo complicado y
probablemente nunca usarlo mañana.
Retroalimentación
Retroalimentación concreta y frecuente del
cliente, del equipo y de los usuarios finales da
una mayor oportunidad de dirigir el esfuerzo
eficientemente.
27
Coraje
El coraje existe en el contexto de los otros tres
valores (si funciona…mejóralo).
Respeto
El valor del respeto en XP establece: “Todos
en el equipo dan y reciben el respeto que
merecen como integrantes del equipo y los
aportes de cada integrante son valorados por
todos."
Tabla 2. Los cinco valores de XP
3.1.3 Los principios de XP
Hay cinco principios fundamentales que gobiernan el desarrollo de software con XP,
y que toma como base los valores anteriormente explicados. A continuación en Tabla
3 se describe cada uno de ellos.
PRINCIPIO
DESCRIPCIÓN
Retroalimentación rápida
Con retroalimentación rápida, se quiere decir que el
grupo de desarrollo, aplica ciclos pequeños de
retroalimentación para saber si su producto actual
satisface las necesidades del cliente.
Asumir la simplicidad
Es el hecho de tratar a cada problema como si fuera
fácil de resolver. En otras palabras se diseña solo
para la iteración actual sin importar lo que pueda
pasar a futuro.
Cambios incrementales
Aceptar el cambio
Trabajo de calidad
El cambio incremental resuelve problemas con una
serie de cambios pequeños, aplicando planificación,
desarrollo y diseño del sistema en desarrollo.
Con esto XP, sugiere implantar una estrategia que
permita tener varias opciones viables, mientras se
resuelven problemas que son críticos para la
entrega.
La calidad del trabajo en XP no puede ser
comprometida. XP realza la calidad del código y
las pruebas, por medio de la programación que
realiza pruebas antes de codificar (test-first).
Tabla 3. Los principios guiados de XP
28
3.1.4 Las actividades de XP
XP posee cuatro actividades básicas que son ejecutadas dentro del proceso de
desarrollo de software. La tabla 4 muestra cada actividad dentro de XP.
ACTIVIDAD
Escuchar
Codificar
Hacer pruebas
Diseñar
DESCRIPCIÓN
Si vamos a realizar pruebas se tiene que preguntar
si lo obtenido es lo deseado. Tenemos que escuchar
al cliente para que nos pueda manifestar cuáles son
los problemas de su negocio, porque si no
escuchamos no sabemos que se debe codificar peor
aún hacer pruebas.
Es necesario codificar y plasmar nuestras ideas a
través del código, porque sin código no hay
programas.
Las pruebas dan la oportunidad de conocer si lo
desarrollado es lo que en realidad se requería, por
esta razón tenemos que hacer pruebas porque sin
pruebas no sabemos si hemos terminado de
codificar.
El diseño crea una estructura que organiza la lógica
del sistema, un buen diseño permite que el sistema
crezca con cambios en un solo lugar, por lo tanto
hay que diseñar para poder codificar, probar y
escuchar.
Tabla 4. Las actividades de XP
3.1.5 Las prácticas de XP
Ninguna de las prácticas establece algo por sí mismas, requieren de otras prácticas
para poder balancearse. A continuación en la Tabla 5. Se describe brevemente cada
una de ellas.
29
PRÁCTICA
DESCRIPCIÓN
El juego de la planificación
XP es un proceso de desarrollo iterativo. En el
juego de la planificación, el cliente y los
programadores determinan el alcance de la próxima
versión.
Entregas pequeñas
Metáfora
Los programadores construyen el sistema en
pequeñas versiones definidas. Una iteración
demora aproximadamente dos semanas.
La metáfora ofrece una idea o un modelo para el
sistema. Proporciona un contexto para nombrar las
cosas en el software, en otras palabras, expresa los
términos y el lenguaje utilizado para describirlo.
Diseño simple
El diseño en XP se mantiene lo más simple posible
para el conjunto actual de historias implementadas.
Los programadores no construyen los marcos y la
infraestructura para las características que podrían
estar llegando.
Pruebas de aceptación
El cliente escribe pruebas de aceptación. Las
pruebas demuestran que la historia está completa.
Los programadores y los clientes automatizan las
pruebas de aceptación. Los programadores ejecutan
las pruebas varias veces al día.
Refactorización
Programación en parejas
Dado a que los programadores añaden nuevas
características al proyecto, el diseño puede
comenzar a causar problemas. Si esto sigue así, el
diseño se deteriorará. Refactoring es el proceso de
mantener el diseño limpio de forma incremental.
Dos programadores colaboran para resolver un
problema. La programación no es un deporte para
espectadores.
Propiedad colectiva
Cualquier integrante del equipo de desarrollo puede
cambiar cualquier código de cualquier parte del
sistema en cualquier momento.
Integración continua
Cada pieza de código es integrada en el sistema una
vez que esté lista. Los programadores integran y
prueban el software varias veces al día.
Semana de 40 horas de trabajo
Se debe trabajar un máximo de 40 horas por
semana. No se trabajan horas extras en dos semanas
seguidas. Si esto se suscita, probablemente se está
ante un problema que debe corregirse. El trabajo
extra desmotiva al equipo.
Cliente en el sitio
Los equipos tienen a alguien (o un grupo de
personas), que representa los intereses del cliente.
Ellos deciden lo que está o no en el producto.
30
Estándares de codificación
Los desarrolladores escribirán todo el código de
acuerdo a reglas predeterminadas que resaltarán la
comunicación a través del código. El código debe
tener un estilo común para facilitar la comunicación
entre los programadores.
Tabla 5. Las prácticas en XP
3.1.6 Ciclo de vida de un proyecto XP
Se basa en el ciclo de vida iterativo e incremental. De acuerdo con una de las
prácticas que anteriormente se mencionó, se realizan iteraciones cortas de tal manera
que se obtiene una rápida respuesta del cliente. Por lo tanto el desarrollo se adapta
rápidamente a los cambios que pueden surgir a lo largo del proyecto.
En la siguiente Figura 5 se puede apreciar el esquema del ciclo de vida de un
proyecto XP.
Figura 5. Esquema del ciclo de vida de un proyecto XP2
A continuación en la Tabla 6, se resume cada una de las fases.
2
Fuente: Obtenida el 19 de marzo, 2015 de: < http://asier-ares.blogspot.com/2012/04/leccion-9-xp33.html>
31
FASE
Exploración
DESCRIPCIÓN
En esta fase, los clientes bosquejan a grandes
rasgos las historias de usuario que son de interés
para la primera entrega del producto. Al mismo
tiempo el equipo de desarrollo se familiariza con
las herramientas, tecnologías y prácticas que se
utilizarán en el proyecto. Se prueba la tecnología y
se exploran las posibilidades de la arquitectura del
sistema construyendo un prototipo.
Planificación de la entrega
(release)
En esta fase el cliente establece la prioridad de cada
historia de usuario, mientras que, los
programadores realizan una estimación del esfuerzo
necesario de cada una de ellas. Se toman acuerdos
sobre el contenido de la primera entrega y se
determina un cronograma en conjunto con el
cliente.
Iteraciones
Esta fase incluye varias iteraciones sobre el sistema
antes de ser entregado. En la primera iteración se
puede intentar establecer una arquitectura del
sistema que pueda ser utilizada durante el resto del
proyecto. Esto se logra escogiendo las historias que
fuercen la creación de esta arquitectura, sin
embargo, esto no siempre es posible ya que es el
cliente quien decide qué historias se implementarán
en cada iteración. Al final de la última iteración el
sistema estará listo para entrar en producción.
Producción
Mantenimiento
La fase de producción requiere de pruebas
adicionales y revisiones de rendimiento antes de
que el sistema sea trasladado al entorno del cliente.
Mientras la primera versión se encuentra en
producción, el proyecto XP debe mantener el
sistema en funcionamiento al mismo tiempo que
desarrolla nuevas iteraciones. Para realizar esto se
requiere de tareas de soporte para el cliente.
Tabla 6. Las fases en el ciclo de vida XP
Cabe destacar que para este caso, solo se cumplirá el desarrollo de software hasta la
fase de puesta en producción, ya que el mantenimiento lo asumiría el equipo de
desarrollo de la Institución que adquiera el compromiso de realizar dicha actividad.
32
3.1.7 Roles en XP
En la mayoría de las metodologías de desarrollo de software los roles de los
miembros del equipo de desarrollo tienden a ser estáticos, XP se basa en la sinergia
que pueda existir entre los miembros del equipo para crear el éxito. Es así que los
roles en XP no son fijos, por ejemplo, hoy puede ser un desarrollador y más adelante
el encargado del seguimiento del proyecto.
Construir lo que el cliente necesita y conseguir las metas, es el objetivo primordial
del equipo XP, esto no quiere decir que para cumplirlo se deba hacer un sobre
esfuerzo por parte de cada uno de los integrantes del equipo, por el contrario para
XP, las personas en sí son más importantes para el éxito del proyecto que el mismo
proceso.
La Figura 6, muestra los roles que existen en un proyecto XP, al cual lo podemos
definir como un equipo que contiene dos grupos.
Figura 6. Equipo XP
A continuación, se detalla en qué consiste cada uno de los roles que forman parte del
equipo de desarrollo en XP.
3.1.7.1 Cliente
33
El cliente es parte del equipo, cuanto más frecuente sea su participación, mayores
serán las probabilidades de que el proyecto sea todo un éxito. El cliente toma
decisiones sobre el negocio, sus derechos y responsabilidades se derivan de su
conocimiento en el negocio, es quién tiene la autoridad para establecer objetivos y
características del proyecto.
Algunas tareas que tiene el cliente, son:

Determinar qué construir y cuándo.

Escribir historias de usuario.

Escribir o especificar las pruebas de aceptación.

Realizar conjuntamente con el equipo de desarrollo la planificación de las
entregas.
3.1.7.2 Desarrollador
En sí el trabajo de un desarrollador es convertir las historias en código. El papel
promotor en funciones de planificación y ejecución depende de conocer y
comprender las cuestiones técnicas. Los desarrolladores crean y mantienen el sistema
a medida que evoluciona.
Algunas de sus tareas son:

Participar en reuniones para la planificación.

Participar en reuniones diarias con el equipo.

Estimar las historias de usuario.

En XP, los programadores diseñan, programan y realizan las pruebas.
34

Escribir pruebas unitarias (usando herramientas para pruebas).

Escribir código.
3.1.7.3 Gestor (Manager)
El gestor, es quién se encarga de la gestión del proyecto internamente y hacia los
clientes, además se ocupa de aclarar obstáculos e interferencias que obstruya el
trabajo del equipo de desarrollo. Es capaz de mantenerse en un nivel alto de
entendimiento del negocio, pero a la vez está alineado con los valores del equipo.
3.1.7.4 Consultor
Por lo general es un experto externo que solventa inquietudes sobre temas técnicos o
de negocios.
3.1.7.5 Encargado del seguimiento (Tracker)
El encargado de seguimiento proporciona realimentación al equipo en el proceso XP.
Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y
el tiempo real dedicado, comunicando los resultados para mejorar futuras
estimaciones.
También realiza el seguimiento del progreso de cada iteración y evalúa si los
objetivos son alcanzables con las restricciones de tiempo y recursos presentes.
Determina cuándo es necesario realizar algún cambio para lograr los objetivos de
cada iteración.
35
3.1.7.6 Encargado de pruebas (Tester)
Miembro del equipo encargado de realizar las pruebas de aceptación conjuntamente
con el cliente, para certificar que el sistema funcione como se esperaba. La ventaja
del encargado de pruebas está en la probabilidad de no tener muchos inconvenientes
con respecto a errores en el sistema, puesto que el equipo de desarrollo escribe
código de calidad que anteriormente ya ha pasado todas sus pruebas unitarias
exitosamente.
Además ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas
regularmente, difunde los resultados en el equipo y es responsable de las
herramientas de soporte para pruebas.
3.1.7.7 Entrenador (Coach)
Algunos proyectos XP tienen un entrenador que guía y mentaliza al equipo. Su
posición es de respeto, él predica con el ejemplo. XP puede ser difícil de aplicar de
forma coherente, aunque muchas de
sus prácticas son de sentido común, las
habilidades para desarrollar suelen tomar tiempo.
La experiencia es la principal virtud del entrenador, porque así podrá guiar a su
equipo a comprender XP y desarrollar software de calidad. Puede sugerir cambios
en cómo se implementa una práctica, ofrecer ideas para resolver un problema
técnico, o servir de intermediario entre el equipo y la gestión con otros stakeholders.
3.1.8 Visión y metáfora del sistema
Cuando se ha identificado el caso a resolver y basándose en los valores y principios
que suscita la metodología, XP sugiere definir dos términos que serán usados a lo
largo del desarrollo del sistema, y que servirán para aclarar cualquier ambigüedad
con respecto al alcance del proyecto.
36
Visión, es una declaración que describe el alcance general del sistema en términos
del cliente, y que no debe sobrepasar las treinta palabras en longitud, de tal manera
que pueda ser recordado con facilidad por todo el equipo de desarrollo.
La metáfora, es como el equipo conceptualiza al sistema en términos del dominio del
negocio. Para este caso, se trabajó en la Institución conjuntamente con la Dirección
de Teatros y con la Dirección Informática, durante reuniones entre el cliente y el
equipo de desarrollo, se logró aclarar inquietudes que venían de ambas partes.
Luego de estas reuniones se pudo determinar la visión y metáfora del sistema, los
cuales se describen a continuación.
3.1.8.1 Visión del sistema
El propósito del sistema es minimizar el tiempo de consultas y registro de
reservaciones por parte del cliente y empleado.
3.1.8.2 Metáfora del sistema
El sistema propuesto es una aplicación que permite realizar una o varias
reservaciones, entregando información que indique el estado de la misma. Además el
sistema permite administrar los elementos complementarios que serán de importancia
para poder gestionar el proceso de reservas.
Finalmente, el sistema puede generar reportes, indicando tendencias, las cuales
servirá para tomar las medidas necesarias a tiempo.
37
3.1.9 Justificación del uso de Extreme Programming
Se ha seleccionado a esta metodología para el desarrollo de este tema de tesis porque
XP es una metodología ágil que encamina al equipo de desarrollo a enfrentar un
proyecto con requerimientos variables.
Se desarrolla en ciclos de entrega muy pequeños, lo cual permite entregar valor al
negocio rápidamente de modo que el cliente pueda realmente ver el progreso real del
proyecto, requisito que era fundamental para la Institución puesto que se necesitaban
ver resultados lo más pronto posible.
Finalmente, debido a que el proyecto es de corto plazo y que el equipo de desarrollo
está conformado por una persona, el tiempo para la elaboración de documentación
exhaustiva es innecesario, por lo que sólo se documentará lo estrictamente requerido.
3.2 DESARROLLO DEL SISTEMA
3.2.1 Fase I: Exploración
Especificación de requerimientos
La especificación de los requerimientos del sistema se realiza en reuniones del
equipo de desarrollo con el personal que labora en la Dirección de Teatros de la Sede
Nacional de la Casa de la Cultura Ecuatoriana, quienes son las personas que están
relacionadas directamente con los procesos de reserva que realiza dicha Institución,
la descripción de estos requerimientos se detalla en las historias de usuario.
38
Historias de usuario
Es la técnica utilizada en XP para especificar la funcionalidad del sistema desde el
punto de vista del cliente. El tratamiento de las historias de usuario es muy dinámico
y flexible, en un determinado momento las historias de usuario pueden eliminarse,
modificarse o reemplazarse. Cada historia de usuario es lo suficientemente
comprensible y delimitada para que los programadores puedan implementarla en
semanas.
El cliente es quién redacta las historias de usuario, sin embargo y para evitarles
excesivas molestias se llevaron a cabo reuniones con el cliente y luego de ello fue el
equipo de desarrollo quien las redactó, utilizando un lenguaje no técnico, obviando
detalles de implementación y algoritmos.
En este punto, se resalta que pueden existir historias de usuario que son conocidas
como “de valor de negocio cero”, ya que a primera vista no generan ningún beneficio
para el cliente pero que son indispensables para la construcción del sistema.
Tales historias de usuario pueden consistir en la instalación del ambiento de
desarrollo, creación del esquema inicial de la base de datos, creación de usuarios a
aplicativos necesarios para el desarrollo, entre otros.
Es así, como hemos identificado las historias de usuario descritas a continuación, que
servirán para describir la funcionalidad del sistema.
Identificación de las Historias de Usuario
39
Historia de usuario
Número: 01
Usuario: Ing. José Luis Samaniego
Nombre de la historia: Diagrama de flujo
Prioridad en el negocio: ALTA
Riesgo en desarrollo: MEDIO
Descripción: Diseñar un diagrama de flujo para SICCE-TS, para obtener una
descripción visual de las actividades implicadas en el proceso de reservación.
Observaciones: Ninguna
Tabla 7. Descripción Historia de Usuario: Diagrama de flujo
Historia de usuario
Número: 02
Usuario: Ing. José Luis Samaniego
Nombre de la historia: Diagramas de caso de uso
Prioridad en el negocio: ALTA
Riesgo en desarrollo: MEDIO
Descripción: Diseñar diagramas de casos de uso para SICCE-TS, aunque sean
similar a las historias de usuario no deben ser confundidas.
Observaciones: Ninguna
Tabla 8. Descripción Historia de Usuario: Diagrama de casos de uso
Historia de usuario
Número: 03
Usuario: Ing. José Luis Samaniego
Nombre de la historia: Diseño de la base de datos
Prioridad en el negocio: ALTA
Riesgo en desarrollo: ALTO
Descripción: Diseño de la base de datos para SICCE-TS, la cual almacenará
toda la información para poder interactuar con la aplicación.
Observaciones: Ninguna
Tabla 9. Descripción Historia de Usuario: Diagrama de base de datos
40
Historia de usuario
Número: 04
Usuario: Ing. José Luis Samaniego
Nombre de la historia: Diseño de arquitectura
Prioridad en el negocio: ALTA
Riesgo en desarrollo: ALTO
Descripción: Diseño de la arquitectura de datos para SICCE-TS, representa
la estructura del sistema, sirviendo de comunicación entre las personas
involucradas en el desarrollo y ayudando a realizar diversos análisis que
orienten el proceso de toma de decisiones.
Observaciones: Ninguna
Tabla 10. Descripción Historia de Usuario: Diagrama de arquitectura
Historia de usuario
Número: 05
Usuario: Ing. José Luis Samaniego
Nombre de la historia: Módulo para hacer reservas
Prioridad en el negocio: ALTA
Riesgo en desarrollo: ALTO
Descripción: En este módulo se realizará la pre-reservación de una
instalación. La llamamos pre-reservación porque para hacer efectivo el
préstamo de la instalación solicitada el cliente debe cumplir una serie de
requisitos que están determinados por la Dirección de Teatros.
En este módulo el cliente ingresara la información solicitada para asegurar que
las fechas solicitadas se encuentren disponibles para la presentación de su
evento.
Observaciones: Ninguna
Tabla 11. Descripción Historia de Usuario: Módulo reservas
41
Historia de usuario
Número: 06
Usuario: Ing. José Luis Samaniego
Nombre de la historia: Módulo Administración y Reportes
Prioridad en el negocio: ALTA
Riesgo en desarrollo: ALTO
Descripción: Este módulo será creado con la finalidad de que solamente
aquellos empleados que trabajan en la Dirección de Teatros puedan
coordinar de una manera rápida y precisa las actividades que se realizan en
cada una de las instalaciones. Así como la administración de elementos
complementarios que serán de utilidad para un mejor manejo en el proceso
de reservas.
Observaciones: Ninguna
Tabla 12. Descripción Historia de Usuario: Módulo administración y reportes
3.2.1.1 Diagrama de procesos para SICCE-TS
A continuación se presenta el diagrama de flujo para SICCE-TS el cual es intuitivo y
nos permite tener una visión general del proceso de reservas que se lleva a cabo en la
Institución. En este diagrama se emplean símbolos gráficos para representar los
pasos a seguir para completar este proceso.
Figura 7. Diagrama de procesos SICCE-TS
42
3.2.1.2 Diagramas de Casos de Uso
Los diagramas de casos de uso documentan el comportamiento de un sistema desde
el punto de vista del usuario. Por lo tanto los casos de uso representan las funciones
que un sistema puede ejecutar.
Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean
especialmente útiles en la comunicación con el cliente. Los componentes que forman
un diagrama de casos de uso son:
a) Actor, es una entidad externa que interacciona con el sistema participando o
iniciando un caso de uso, no representan a personas físicas o a sistemas, sino
su rol. Esto significa que cuando una persona interactúa con el sistema de
diferentes maneras, estará representado por varios actores.
Figura 8. Representación de un actor en un diagrama de caso de uso
b) Caso de uso, representa una unidad funcional coherente de un sistema,
subsistema o clase. Cada caso de uso debe detallarse, habitualmente mediante
una descripción textual.
Figura 9. Representación de un caso de uso
c) Asociaciones, hay una asociación entre un actor y un caso de uso, si el actor
interactúa con el sistema para llevar a cabo el caso de uso.
Tipos de Relaciones

Asociación, invocación desde un actor o caso de uso a una nueva
operación.
43
Figura 10. Relación de asociación

Inclusión, se puede incluir una relación entre dos casos de uso de tipo
“include” si se desea especificar caso del uso depende del otro.
Figura 11. Relación de inclusión

Extensión, se puede incluir una relación de tipo “extend” si se desea
especificar diferentes variantes del mismo de caso de uso.
Figura 12. Relación de extensión

Generalización, son relaciones de herencia que sirven para mostrar
que diferentes elementos están relacionados como tipos de otros.
Figura 13. Representación Generalización
d) Escenario, es una interacción entre el sistema y los actores, que puede ser
descrito mediante una secuencia de mensajes. Un caso de uso es una
generalización de un escenario.
CASOS DE USO IDENTIFICADOS
Caso de uso Acceso al módulo de administración
44
Figura 14. Diagrama de Caso de Uso: Acceso al módulo de administración
CU-01
Iniciar sesión
Descripción
Validar las credenciales de un usuario para que pueda
ingresar a la administración del sistema.
Administrador
Actor(es)
Pre-Condición
Flujo normal
Abrir un navegador web (Internet Explorer, Mozilla Firefox,
Gogle Chrome), digitar la siguiente url:
http://localhost:8080/CCE/inicio.jsf
Paso Acción
1 Sistema solicita el ingreso de los campos de usuario y
contraseña.
2 Usuario presiona el botón INGRESAR
3 Internamente el sistema valida los datos ingresados.
4 Sistema da acceso al módulo de administración.
Flujo alternativo
Paso Acción
1 Sistema presenta mensaje de error
Post-Condición
Sistema accede a las opciones definidas para el usuario.
Tabla 13. Descripción Caso de Uso CU-01
45
CU-02
Cerrar sesión
Descripción
Finaliza la sección activa.
Actor(es)
Administrador
Pre-Condición
Se debe haber ejecutado CU-01
Flujo normal
Paso Acción
1 Usuario presiona el botón 'Salir'
2 Registra la petición solicitada.
3 Cierra todas las ventanas internas de la aplicación.
4 Termina todas las solicitudes de la instancia actual.
Flujo alternativo Paso Acción
N/A N/A
Post-Condición
Sistema muestra la pantalla de ingreso.
Tabla 14. Descripción Caso de Uso CU-02
CU-03
Reestablecer contraseña
Descripción
Permite reestablecer la contraseña de un usuario.
Actor(es)
Pre-Condición
Flujo normal
Administrador
Haberse ejecutado CU-04
Paso Acción
1 Usuario se dirige a pantalla para reestablecer
contraseña.
2 Usuario ingresa los campos solicitados.
3 Usuario presiona el botón 'REESTABLECER'
Flujo alternativo
Post-Condición
4 Sistema procesa una contraseña temporal y la envía
al correo.
Paso Acción
N/A N/A
Sistema muestra la pantalla de ingreso.
Tabla 15. Descripción Caso de Uso CU-03
46
Caso de uso Gestión de Empleados
Figura 15. Diagrama de Caso de Uso: Gestión Empleados
CU-04
Crear Empleado
Descripción
Permite ingresar los datos al sistema de los empleados que
trabajan en la CCE.
Actor(es)
Administrador
Pre-Condición Haberse ejecutado CU-01
Flujo normal
Paso Acción
1 Usuario se dirige a la pantalla para crear un
empleado.
2 Usuario ingresa todos los datos presentados en
pantalla.
3 Sistema presenta un mensaje satisfactorio de
creación.
Flujo alternativo Paso Acción
1 Cuando los datos ingresados presentan conflicto, el
sistema presentara un mensaje de error.
Post-Condición Usuario puede realizar los cambios que estime conveniente,
sobre un empleado creado.
Tabla 16. Descripción Caso de Uso CU-04
47
CU-05
Actualizar Empleado
Descripción
Permite actualizar los datos ingresados.
Actor(es)
Pre-Condición
Flujo normal
Administrador
Haberse ejecutado CU-04
Paso Acción
1 Usuario se dirige a la pantalla para actualizar un
empleado.
2 Usuario presiona el botón 'Actualizar'
3 Usuario actualiza los datos presentados en pantalla.
4 Sistema presenta un mensaje satisfactorio de
actualización
Flujo alternativo Paso Acción
1 Cuando los datos editados presentan conflicto, el
sistema presentara un mensaje de error.
Post-Condición Usuario puede realizar los cambios que estime conveniente,
sobre un empleado creado.
Tabla 17. Descripción Caso de Uso CU-05
CU-06
Eliminar Empleado
Descripción
Permite eliminar los datos ingresados.
Actor(es)
Pre-Condición
Flujo normal
Administrador
Haberse ejecutado CU-04
Paso Acción
1 Usuario se dirige a la pantalla para eliminar un
empleado.
2 Usuario presiona el botón 'Eliminar'
3 Sistema presenta una alerta de confirmación para
eliminar.
4 Sistema elimina al empleado, presenta mensaje de
eliminación.
5 Sistema refresca la lista de los empleados.
Flujo alternativo Paso Acción
1 Cuando no se puede eliminar un empleado del
sistema, entonces se presentará un mensaje de error.
Post-Condición N/A
Tabla 18. Descripción Caso de Uso CU-06
48
CU-07
Buscar Empleado
Descripción
Permite mostrar los empleados ingresados.
Actor(es)
Pre-Condición
Flujo normal
Administrador
Haberse ejecutado CU-04
Paso Acción
1 Usuario se dirige a la pantalla para buscar un
empleado.
2 Sistema presenta una lista de empleados.
Flujo alternativo Paso Acción
1 Sistema presenta mensaje 'No se encontraron
registros'
Post-Condición Sistema muestra la información más relevante.
Tabla 19. Descripción Caso de Uso CU-07
Caso de uso Gestión de Espacios Físicos
Figura 16. Diagrama de Caso de Uso: Gestión Espacios Físicos
49
CU-08
Crear Espacio Físico
Descripción
Permite ingresar los datos al sistema de los espacios físicos
pertenecientes a la CCE.
Actor(es)
Coordinador
Pre-Condición Haberse ejecutado CU-01
Flujo normal
Paso Acción
1 Usuario se dirige a la pantalla para ingresar un
espacio físico.
2 Usuario ingresa todos los datos presentados en
pantalla.
3 Sistema presenta un mensaje satisfactorio de
creación.
Flujo alternativo Paso Acción
1 Cuando los datos ingresados presentan conflicto, el
sistema presentara un mensaje de error.
Post-Condición Usuario puede realizar los cambios que estime conveniente,
sobre un espacio físico creado.
Tabla 20. Descripción Caso de Uso CU-08
CU-09
Actualizar Espacio Físico
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite actualizar los datos ingresados.
Coordinador
Haberse ejecutado CU-08
Paso Acción
1 Usuario se dirige a la pantalla para actualizar un
espacio físico.
2 Usuario presiona el botón 'Actualizar'
3 Usuario actualiza los datos presentados en pantalla.
4 Sistema presenta un mensaje satisfactorio de
actualización.
5 Sistema refresca la lista de los espacios físicos
almacenados.
Flujo alternativo Paso Acción
1 Cuando los datos editados presentan conflicto, el
sistema presentara un mensaje de error.
Post-Condición Usuario puede realizar los cambios que estime conveniente,
sobre un espacio físico creado.
Tabla 21. Descripción Caso de Uso CU-09
50
CU-10
Eliminar Espacio Físico
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite eliminar los datos ingresados.
Coordinador
Haberse ejecutado CU-08
Paso Acción
1 Usuario se dirige a la pantalla para eliminar un
espacio físico.
2 Usuario presiona el botón 'Eliminar'
3 Sistema presenta una alerta de confirmación para
eliminar.
4 Sistema elimina el espacio físico, presenta mensaje de
eliminación.
5 Sistema refresca la lista de los espacios físicos.
Flujo alternativo Paso Acción
1 Cuando no se puede eliminar un espacio físico del
sistema, entonces se presentará un mensaje de error.
Post-Condición N/A
Tabla 22. Descripción Caso de Uso CU-10
CU-11
Buscar Espacio Físico
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite mostrar los espacios físicos ingresados.
Coordinador
Haberse ejecutado CU-08
Paso Acción
1 Usuario se dirige a la pantalla para buscar un espacio
físico.
2 Sistema presenta una lista de espacios físicos.
Flujo alternativo Paso Acción
1 Sistema presenta mensaje 'No se encontraron
registros'
Post-Condición Sistema muestra la información más relevante.
Tabla 23. Descripción Caso de Uso CU-11
51
Caso de uso Gestión de Clientes
Figura 17. Diagrama de Caso de Uso: Gestión Clientes
CU-12
Crear Cliente
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite ingresar los datos al sistema de los clientes.
Cliente
Ingresar al módulo de reservas.
Paso Acción
1 Usuario se dirige a la pantalla para ingresar un
cliente.
2 Usuario ingresa todos los datos presentados en
pantalla, clic en botón 'GUARDAR'
3 Sistema presenta un mensaje satisfactorio de
creación.
Flujo alternativo Paso Acción
1 Cuando los datos ingresados presentan conflicto, el
sistema presentara un mensaje de error.
2 Si usuario no desea crear cliente, presiona botón
'CANCELAR'
Post-Condición Usuario puede realizar reservas.
Tabla 24. Descripción Caso de Uso CU-12
52
CU-13
Actualizar Cliente
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite actualizar los datos ingresados.
Cliente
Haberse ejecutado CU-12
Paso Acción
1 Usuario se dirige a la pantalla para actualizar un
cliente.
2 Usuario ingresa su número de identificación.
3 Usuario presiona 'BUSCAR'
4 Sistema presenta los datos almacenados.
5 Usuario actualiza la información, clic en
'GUARDAR'
4 Sistema presenta un mensaje satisfactorio de
actualización.
Flujo alternativo Paso Acción
1 Cuando los datos editados presentan conflicto, el
sistema presentara un mensaje de error.
2 Si usuario no desea hacer cambios, presiona botón
'CANCELAR'
Post-Condición Usuario puede realizar reservas.
Tabla 18. Descripción Caso de Uso CU-13
53
CU-14
Eliminar Cliente
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite eliminar clientes.
Coordinador
Haberse ejecutado CU-12
Paso Acción
1 Usuario se dirige a la pantalla para eliminar un
cliente.
2 Usuario presiona el botón 'Eliminar'
3 Sistema presenta una alerta de confirmación para
eliminar.
4 Sistema elimina el cliente, presenta mensaje de
eliminación.
5 Sistema refresca la lista de los clientes almacenados.
Flujo alternativo Paso Acción
1 Cuando no se puede eliminar un cliente del sistema,
entonces se presentará un mensaje de error.
Post-Condición N/A
Tabla 25. Descripción Caso de Uso CU-14
CU-15
Buscar Cliente
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite mostrar los clientes ingresados.
Coordinador
Haberse ejecutado CU-12
Paso Acción
1 Usuario se dirige a la pantalla para buscar un cliente.
2 Sistema presenta una lista de clientes.
Flujo alternativo Paso Acción
1 Sistema presenta mensaje 'No se encontraron
registros'
Post-Condición Sistema muestra la información más relevante.
Tabla 20. Descripción Caso de Uso CU-15
54
Caso de uso Gestión de Estados
Figura 18. Diagrama de Caso de Uso: Gestión Estados
CU-16
Crear Estado
Descripción
Permite ingresar los datos al sistema de los estados que
podrá tener una reservación.
Actor(es)
Coordinador
Pre-Condición Haberse ejecutado CU-01
Flujo normal
Paso Acción
1 Usuario se dirige a la pantalla para ingresar un
estado.
2 Usuario ingresa todos los datos presentados en
pantalla, clic en botón 'GUARDAR'
3 Sistema presenta un mensaje satisfactorio de
creación.
Flujo alternativo Paso Acción
1 Cuando los datos ingresados presentan conflicto, el
sistema presentara un mensaje de error.
2 Si usuario no desea crear un estado presionar botón
'CANCELAR'
Post-Condición El estado ya puede ser asignado a una reservación.
Tabla 26. Descripción Caso de Uso CU-15
55
CU-17
Actualizar Estado
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite actualizar los datos ingresados.
Coordinador
Haberse ejecutado CU-16
Paso Acción
1 Usuario se dirige a la pantalla para actualizar un
estado
2 Usuario presiona el botón 'Actualizar'
3 Usuario actualiza los datos presentados en pantalla,
clic en botón 'GUARDAR'.
4 Sistema presenta un mensaje satisfactorio de
actualización.
5 Sistema refresca la lista de los estados almacenados.
Flujo alternativo Paso Acción
1 Cuando los datos editados presentan conflicto, el
sistema presentara un mensaje de error.
2 Si usuario no desea hacer cambios, presionar botón
'CANCELAR'
Post-Condición El estado ya puede ser asignado a una reservación.
Tabla 27. Descripción Caso de Uso CU-17
56
CU-18
Eliminar Estado
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite eliminar estados.
Coordinador
Haberse ejecutado CU-16
Paso Acción
1 Usuario se dirige a la pantalla para eliminar un estado
2 Usuario presiona el botón 'Eliminar'
3 Sistema presenta una alerta de confirmación para
eliminar.
4 Sistema elimina el estado presenta mensaje de
eliminación.
5 Sistema refresca la lista de los estados almacenados.
Flujo alternativo Paso Acción
1 Cuando no se puede eliminar un estado del sistema,
entonces se presentará un mensaje de error.
Post-Condición N/A
Tabla 28. Descripción Caso de Uso CU-18
CU-19
Buscar Estado
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite mostrar los estados ingresados.
Coordinador
Haberse ejecutado CU-16
Paso Acción
1 Usuario se dirige a la pantalla para buscar un esatdo
2 Sistema presenta una lista de estados.
Flujo alternativo Paso Acción
1 Sistema presenta mensaje 'No se encontraron
registros'
Post-Condición Sistema muestra la información más relevante.
Tabla 29. Descripción Caso de Uso CU-19
57
Caso de uso Gestión de Tipos de Identificación
Figura 19. Diagrama de Caso de Uso: Gestión Tipos de identificación
CU-20
Ingresar Tipo de identificación
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite ingresar los datos al sistema de los diferentes tipos
Coordinador
Haberse ejecutado CU-01
Paso Acción
1 Usuario se dirige a la pantalla para ingresar un tipo de
identificación
2 Usuario ingresa todos los datos presentados en
pantalla, clic en botón 'GUARDAR'
3 Sistema presenta un mensaje satisfactorio de
creación.
Flujo alternativo Paso Acción
1 Cuando los datos ingresados presentan conflicto, el
sistema presentara un mensaje de error.
2 Si usuario no desea ingresar un tipo de identificación,
presionar botón 'CANCELAR'
Post-Condición El estado ya puede ser asignado a un cliente.
Tabla 30. Descripción Caso de Uso CU-20
58
CU-21
Actualizar Tipo de identificación
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite actualizar los datos ingresados.
Coordinador
Haberse ejecutado CU-20
Paso Acción
1 Usuario se dirige a la pantalla para actualizar un tipo
de identificación
2 Usuario presiona el botón 'Actualizar'
3 Usuario actualiza los datos presentados en pantalla,
clic en botón 'GUARDAR'.
4 Sistema presenta un mensaje satisfactorio de
actualización.
5 Sistema refresca la lista de los tipos de identificación
almacenados.
Flujo alternativo Paso Acción
1 Cuando los datos editados presentan conflicto, el
sistema presentara un mensaje de error.
2 Si usuario no desea hacer cambios, presionar botón
'CANCELAR'
Post-Condición Tipo de identificación ya puede ser asignado a un cliente.
Tabla 31. Descripción Caso de Uso CU-21
59
CU-22
Eliminar Tipo de identificación
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite eliminar tipos de identificación.
Coordinador
Haberse ejecutado CU-20
Paso Acción
1 Usuario se dirige a la pantalla para eliminar un tipo de
identificación
2 Usuario presiona el botón 'Eliminar'
3 Sistema presenta una alerta de confirmación para
eliminar.
4 Sistema elimina el tipo de identificación, presenta
mensaje de eliminación.
5 Sistema refresca la lista de los tipos de identificación
almacenados.
Flujo alternativo Paso Acción
1 Cuando no se puede eliminar un tipo de identificación
del sistema, entonces se presentará un mensaje de
error.
Post-Condición N/A
Tabla 32. Descripción Caso de Uso CU-22
CU-23
Buscar Tipo de identificación
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite mostrar los tipos de identificación ingresados.
Coordinador
Haberse ejecutado CU-20
Paso Acción
1 Usuario se dirige a la pantalla para buscar un tipo de
identificación
2 Sistema presenta una lista de tipos de identificación
Flujo alternativo Paso Acción
1 Sistema presenta mensaje 'No se encontraron
registros'
Post-Condición Sistema muestra la información más relevante.
Tabla 33. Descripción Caso de Uso CU-23
60
Caso de uso Gestión Reservas
Figura 20. Diagrama de Caso de Uso: Gestión Reservas
CU-24
Seleccionar Espacio Físico
Descripción
Se presenta una lista de los espaciós físicos, para
seleccionar aquel que sele vaya hacer la reservación.
Cliente
Haberse ejecutado CU-08
Actor(es)
Pre-Condición
Flujo normal
Paso Acción
1 Usuario se dirige a la pantalla para seleccionar un
espacio físico.
2 El sistema presenta toda la información de los
espacios físicos almacenados.
3 Usuario presiona 'Haga su reserva'
Flujo alternativo Paso Acción
1 Si usuario no desea hacer la reserva, presiona el
botón 'CANCELAR'
Post-Condición Ejecutar caso de uso CU-25
Tabla 34. Descripción Caso de Uso CU-25
61
CU-25
Verificar disponibilidad de fechas
Descripción
Permite conocer si las fechas requeridas por el cliente se
encuentran disponibles.
Cliente
Haberse ejecutado CU-24
Paso Acción
1 Usuario ingresa los campos que se presenten en
pantalla.
2 Usuario presiona el botón 'VERIFICAR'
Actor(es)
Pre-Condición
Flujo normal
3 Sistema verifica internamente si las fechas solicitada
están libres.
4 Sistema avanza al siguiente paso.
Flujo alternativo Paso Acción
1 Si existen fechas en conflicto, el sistema presenta un
mensaje de error.
2 Usuario debe ingresar fechas para verificar su
disponibilidad.
Post-Condición Ejecutar caso de uso CU-26
Tabla 35. Descripción Caso de Uso CU-25
CU-26
Asociar Cliente
Descripción
Actor(es)
Pre-Condición
Flujo normal
Asociar cliente a la reservación.
Cliente
Haberse ejecutado CU-25
Paso Acción
1 Usuario ingresa los campos que se presenten en
pantalla.
2 Usuario presiona el botón 'BUSCAR'
3 Sistema busca al cliente y lo asigna a la reservación.
4 Sistema avanza al siguiente paso.
Flujo alternativo Paso Acción
1 Si el cliente no existe, sistema presenta un mensaje
de error.
2 Ejecutar el caso de uso CU-12
Post-Condición Ejecutar caso de uso CU-27
Tabla 36. Descripción Caso de Uso CU-26
62
CU-27
Crear pre-reservación
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite crear una pre-reservación.
Cliente
Haberse ejecutado CU-26
Paso Acción
1 Usuario valida si toda la información de la
reservación que se ha ingresado anteriormente esta
correcta.
2 Usuario ingresa todos los datos presentados en
pantalla, clic en botón 'GUARDAR'
3 Sistema envía un correo electrónico al cliente, en el
cual es una confirmación de que la reservación entra
en proceso.
4 Sistema presenta mensaje de creación y envío
exitoso.
Flujo alternativo Paso Acción
1 Cuando los datos ingresados presentan conflicto, el
sistema presentara un mensaje de error.
2 Si usuario no desea ingresar una pre-reservación,
presionar botón 'CANCELAR'
Post-Condición Ejecutar CU-28
Tabla 37. Descripción Caso de Uso CU-27
63
CU-28
Actualizar reservación
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite la actualización de la reservación.
Coordinador
Haberse ejecutado CU-27
Paso Acción
1 Usuario se dirige a la pantalla de administración de
reservas.
2 Usuario presiona el botón 'Actualizar'
3 Usuario actualiza los datos presentados en pantalla,
clic en botón 'GUARDAR'.
4 Sistema envía un correo electrónico al cliente,
indicándole el estado de su reservación.
5 Sistema presenta un mensaje satisfactorio de
actualización.
Flujo alternativo Paso Acción
1 Cuando los datos ingresados presentan conflicto, el
sistema presentara un mensaje de error.
2 Si usuario no desea actualizar, presionar botón
'CANCELAR'
Post-Condición Una vez que el usuario ha sido informado del estado de su
reservación ya puede continuar con los trámites requeridos
para llevar el evento a cabo.
Tabla 38. Descripción Caso de Uso CU-28
64
CU-29
Eliminar Reservación
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite eliminar una reservación.
Coordinador
Haberse ejecutado CU-27
Paso Acción
1 Usuario se dirige a la pantalla de administración de
reservas para eliminar.
2 Usuario presiona el botón 'Eliminar'
3 Sistema presenta una alerta de confirmación para
eliminar.
4 Sistema elimina la reserva, presenta mensaje de
eliminación.
5 Sistema refresca la lista de reservas.
Flujo alternativo Paso Acción
1 Cuando no se puede eliminar una reserva del sistema,
entonces se presentará un mensaje de error.
Post-Condición N/A
Tabla 39. Descripción Caso de Uso CU-29
CU-30
Buscar Reserva
Descripción
Actor(es)
Pre-Condición
Flujo normal
Permite mostrar las reservas ingresadas.
Coordinador
Haberse ejecutado CU-27
Paso Acción
1 Usuario se dirige a la pantalla para buscar una
reserva.
2 Sistema presenta una lista de reservas.
3 Sistema presenta filtros para realizar la búsqueda.
4 Usuario ingresa datos en los filtros.
Flujo alternativo Paso Acción
1 Sistema presenta mensaje 'No se encontraron
registros'
Post-Condición Sistema muestra la información más relevante.
Tabla 40. Descripción Caso de Uso CU-30
65
Caso de uso Gestión de Reportes
Figura 21. Diagrama de Caso de Uso: Gestión de reportes
CU-31
Generar reporte: Uso de instalaciones
Descripción
Presenta un reporte de uso que han tenido las diferentes
instalaciones.
Administrador
Haberse ejecutado CU-01, CU-27
Paso Acción
1 Usuario se dirige a pantalla de reportes.
Actor(es)
Pre-Condición
Flujo normal
2 Usuario ingresa los campos solicitados.
3 Usuario presiona el botón 'BUSCAR'
4 Sistema presenta un informe de acuerdo a los
criterios ingresados.
Flujo alternativo Paso Acción
N/A N/A
Post-Condición N/A
Tabla 41. Descripción Caso de Uso CU-31
3.2.1.3 Diseño de la base de datos para SICCE-TS
El diseño de una base de datos no es un proceso sencillo, normalmente, la
complejidad de la información y la cantidad de requisitos de los sistemas de
información hacen que sea complicado.
A continuación se descompone el diseño de la base de datos para SICCE-TS en dos
etapas, así se divide el problema y, al mismo tiempo, se simplifica el proceso.
66
1. Etapa del diseño conceptual
En esta etapa se obtiene una estructura de la información de la futura base de
datos independiente de la tecnología que hay que emplear. No se tiene en
cuenta todavía qué tipo de base de datos se utilizará: relacional, orientada a
objetos, jerárquica, etc.; en consecuencia, tampoco se tiene en cuenta con qué
SGBD ni con qué lenguaje concreto se implementará la base de datos.
Así pues, la etapa del diseño conceptual nos permite concentrarnos
únicamente en la problemática de la estructuración de la información, sin
tener que preocuparnos al mismo tiempo de resolver cuestiones tecnológicas.
El resultado de la etapa del diseño conceptual se expresa mediante algún
modelo de datos de alto nivel. El modelo que se nos va a permitir representar
el diseño de base de datos conceptual es el modelo entidad-relación (ER), por
ser uno de los más empleados y fácil de entender.
En la Figura 22, se presenta el diseño conceptual en el cual se basará la base
de datos para esta aplicación.
2. Etapa de diseño físico
En esta etapa se transforma la estructura obtenida en la etapa del diseño
conceptual, con el objetivo de conseguir una mayor eficiencia; además, se
completa con aspectos de implementación física que dependerán del SGBD.
Los aspectos de implementación física que hay que completar consisten
normalmente en la elección de estructuras físicas de implementación de las
relaciones, la selección del tamaño de las memorias intermedias (buffers), etc.
En la etapa del diseño físico, con el objetivo de conseguir un buen
rendimiento de la base de datos, se deben tener en cuenta las características
de los procesos que consultan y actualizan la base de datos, como por
ejemplo los caminos de acceso que utilizan y las frecuencias de ejecución.
67
También es necesario considerar los volúmenes que se espera tener de los
diferentes datos que se quieren almacenar.
En la Figura 23, se muestra el diseño físico que llevará SICCE-TS.
68
Figura 22. Diseño conceptual de la base de datos SICCE-TS
69
Figura 23. Diseño físico de la base de datos SICCE-TS
70
3.2.1.4 Diseño de la arquitectura para SICCE-TS
En el diseño de sistemas informáticos actual se suele usar las arquitecturas multinivel
o programación por capas. En dichas arquitecturas a cada nivel se le confía una
misión simple, lo que permite el diseño de arquitecturas escalables, esto quiere decir
que pueden ampliarse con facilidad en caso de que las necesidades aumenten.
Cabe mencionar que el objetivo principal de esta arquitectura es la separación de la
lógica de negocios de la lógica de diseño. Por esta razón al SICCE-TS se le aplicará
una solución tres capas y dos niveles, puesto que en caso de que ocurra algún
cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado.
En la Figura 24, se ilustra las tres capas que SICCE-TS seguirá desde el punto de
vista lógica:
Figura 24. Distribución de tres capas3

Una capa de cliente, es la que ve el usuario, le comunica la información y
captura la información del usuario en un mínimo de proceso. También es
conocida como interfaz gráfica y debe tener la característica de ser
"amigable" (entendible y fácil de usar) para el usuario. Esta capa se comunica
únicamente con la capa de negocio.

Una capa de lógica de negocio o intermedia, es aquí donde se establecen
todas las reglas que deben cumplirse. Esta capa se comunica con la capa de
3
Fuente:
Obtenida
el
22
de
<http://docente.ucol.mx/sadanary/public_html/bd/cs.htm>
71
marzo,
2015
de:
presentación, para recibir solicitudes y presentar resultados. Además también
se comunica con la capa de datos, para solicitar al gestor de base de datos
almacenar o recuperar datos de él.

Una capa de datos o persistencia, donde residen los datos y es la encargada de
acceder a los mismos. Está formada por uno o más gestores de bases de datos
que realizan todo el almacenamiento de datos, reciben solicitudes de
almacenamiento o recuperación de información desde la capa de negocio.
El término "nivel" corresponde a la forma en que las capas lógicas se encuentran
distribuidas de forma física. Dicho esto, las lógicas de SICCE-TS serán distribuidas
en dos ordenadores. El primero contendría la capa de presentación y lógica del
negocio y el segundo contendría los datos de la aplicación.
En la Figura 25, se muestra los dos niveles de la arquitectura SICCE-TS.
Figura 25. Distribución de dos niveles4
4
Fuente:
Obtenida
el
26
de
marzo,
<http://matrujillojim.blogspot.com/2011/11/arquitectura-en-tres-capas.html>
72
2015
de:
3.2.2 Fase II: Planificación de la entrega
A continuación se muestra el plan de entrega a seguir para la construcción del
sistema, aquí se establece el tiempo que tomará realizar cada una de las tareas
tomando en cuenta la prioridad que estableció el cliente en las historias de usuario.
Figura 26. Plan de entrega para SICCE-TS
73
3.2.3 Fase III: Iteraciones
Posterior a la obtención del plan de la entrega, el equipo de desarrollo está en la
capacidad de empezar con la implementación del sistema. Las iteraciones a
implementar son:
3.2.3.1 Diseño de capas
La realización del sistema propuesto sigue como modelo de arquitectura JEE, la cual
es una obra diseñada en capas, con cada una de sus funcionalidades propias, que
permiten edificar de forma modular el desarrollo del sistema.
Dicho esto SICCE-TS se basa en el uso de componentes ampliamente modulares,
para lo cual se utiliza tres capas: acceso a datos, lógica de negocio, presentación. La
descomposición de SICCE-TS en capas se representa a continuación:
Figura 27. Capas SICCE-TS
Capa de presentación/vista
En esta capa se utilizan páginas Web las cuales son archivos xhtml, siendo estas
interpretadas por el navegador para que pueda existir comunicación entre el usuario y
el sistema.
74
Capa de presentación/controlador
En la capa de presentación se tiene clases controladores, estas son archivos java y
son las responsables de ejecutar y responder acciones solicitadas por el usuario a
través del navegador Web.
Los controladores realizan validaciones de los datos ingresados por el usuario,
ocultan y muestran los componentes del navegador a través de las acciones del
usuario.
Capa lógica de negocio
Esta capa está construida con EJB, usando el patrón de diseño Facade, éste muestra
los servicios transparentemente hacia la capa de presentación y estos son consumidos
por las clases controladores.
Capa de persistencia
La capa de persistencia realiza el acceso a los datos con el patrón de diseño DAO
(Data Access Object) que permite la interactuar con los objetos de base de datos.
3.2.3.2 Codificación
Para ilustrar la codificación se utiliza el caso de uso “Crear Espacio Físico”.
Construcción de la página Web
Se utiliza una plantilla la cual tiene elementos que son comunes en todas las páginas
xhtml, esta será la base para la construcción de las restantes páginas. El código de la
plantilla utilizada en todo el proyecto es:
75
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:p="http://primefaces.org/ui"
xmlns:a4j="http://richfaces.org/a4j"
xmlns:rich="http://richfaces.org/rich">
<h:head>
<title><ui:insert name="tituloPagina">Coloque el titulo de la
pagina</ui:insert>
</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css"
href="#{request.contextPath}/css/sicce_ts.css" />
<script type="text/javascript"
src="#{request.contextPath}/js/util.js"></script>
<link rel="stylesheet"
href="#{request.contextPath}/css/slider/1140_.css" />
<link rel="stylesheet"
href="#{request.contextPath}/css/slider/flexslider_.css" />
<link rel="stylesheet"
href="#{request.contextPath}/css/slider/style_.css" />
<script type="text/javascript"
src="#{request.contextPath}/js/jquery.flexslidermin.js"></script>
<script type="text/javascript" charset="utf-8">
$(window).load(function() {
$('.flexslider').flexslider({
controlsContainer : '.flex-container'
});
});
</script>
<script type="text/javascript">
// <![CDATA[
var curDt = new Date();
disableBeforeToday = function(day) {
return (curDt.getTime() - day.date.getTime() < 0 );
}
// ]]>
</script>
</h:head>
<body>
<a4j:outputPanel ajaxRendered="true">
<script type="text/javascript">
var sessionTimeOut =
'${facesContext.externalContext.request.session.maxInactiveInterval}';
var sessionTimeOutMillis = parseInt(sessionTimeOut) * 1000;
setTimeout("window.location.href='#{facesContext.externalContext.request.con
textPath}/pages/error/sesionCaducada.jsf';", sessionTimeOutMillis);
</script>
</a4j:outputPanel>
<div id="main">
<!-- header begins -->
<div id="header">
<div id="text-header">
<h1>Direcci&oacute;n de Teatros</h1>
<h1>Casa de la Cultura Ecuatoriana
Benjam&iacute;n Carri&oacute;n"</h1>
</div>
<div class="logo">
<div id="slider">
<div class="flex-container">
<div class="flexslider">
76
<ul class="slides">
<li><img
src="#{request.contextPath}/images/logo_cce.png" /></li>
<li><img
src="#{request.contextPath}/images/sicce.jpg" /></li>
<li><img
src="#{request.contextPath}/images/ecuador_ama_la_vida.jpg" /></li>
<li><img
src="#{request.contextPath}/images/uce.jpeg" /></li>
</ul>
</div>
</div>
</div>
</div>
<div class="clr"></div>
</div>
<!-- content begins -->
<div id="bar">
<div id="bar_salir">
<a4j:commandLink
action="#{loginBacking.cerrarSesion}"
value="#{botones['salir']}"
execute="@this"></a4j:commandLink>
</div>
<div id="bar_ayuda">
<a
href="http://localhost:8080/CCE/resources/doc/ManualUsuario.pdf"
target="_blank">Ayuda</a>
</div>
</div>
<div id="content">
<a4j:status id="status1"
onstart="#{rich:component('statusDialog')}.show()"
onstop="#{rich:component('statusDialog')}.hide()"
/>
<rich:popupPanel id="statusDialog" autosized="true"
modal="true">
<h:graphicImage value="/images/gif-load.gif" />
</rich:popupPanel>
<div id="right">
<ui:insert name="contenido">Aqui va el
contenido</ui:insert>
</div>
<div id="left">
<div id="sidebar" class="sidebar">
<div class="gadget">
<h2>#{etiquetas['menu']}</h2>
<div class="clr"></div>
<ul class="sb_menu">
<ui:include
src="menubar2.xhtml" />
</ul>
</div>
</div>
<div class="clr"></div>
</div>
<div style="clear: both"></div>
</div>
<!-- content ends -->
</div>
<!-- footer begins -->
<div id="footer">
<p>
77
Copyright &copy; 2014.<a href="#"
title="UCE">Universidad Central
del Ecuador</a>
</p>
</div>
<!-- footer ends -->
</body>
</html>
Tabla 42. Template: template_con_sesion.xhtml
Utilizando la página template_con_sesion.xhtml se diseña la interfaz de usuario de
“Crear Espacio Físico” en la página IngresarEspacioFisico.xhtml.
<ui:composition template="/templates/template_ts.xhtml"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:a4j="http://richfaces.org/a4j"
xmlns:rich="http://richfaces.org/rich"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:p="http://primefaces.org/ui">
<ui:define
name="tituloPagina">#{etiquetas['espacio.fisico']}</ui:define>
<ui:define name="contenido">
<h:form id="formEspacioFisico" enctype=" multipart/form-data">
<rich:panel id="pnlAllEspacioFisico"
style="width: 760px;border-radius: 12px;">
<h2>#{etiquetas['espacio.fisico']}</h2>
<rich:messages />
<fieldset id="fsIngresoDatos">
<legend>
<h3>#{etiquetas['ingresar.datos']}</h3>
</legend>
<h:panelGroup id="pnlIngresoDatos">
<h:panelGrid columns="6"
cellpadding="16px">
<h:outputText id="lblId"
value="#{etiquetas['id']}:(*)"
styleClass="label" />
<h:selectOneMenu id="txtId"
value="#{espacioFisicoBacking.espacioFisico.idEspacioFisico}"
required="true"
requiredMessage="#{etiquetas['id']} Obligatorio">
<f:selectItem
itemLabel="Seleccione" noSelectionOption="true" />
<f:selectItem
itemLabel="1" itemValue="1" />
<f:selectItem
itemLabel="2" itemValue="2" />
</h:selectOneMenu>
<rich:message for="txtId"
ajaxRendered="true" />
<h:outputText
id="lblCapacidad" value="#{etiquetas['butacas']}:"
styleClass="label" />
<h:inputText id="txtButacas"
78
style="font-size:13px!important;"
size="5" maxlength="4"
value="#{espacioFisicoBacking.espacioFisico.efCapacidad}"
required="false"
onkeypress="return permite(event, 'num')" />
<rich:message
for="txtButacas" ajaxRendered="true" />
</h:panelGrid>
<h:panelGrid columns="3">
<h:outputText
id="lblNombreEspacioFisico"
value="#{etiquetas['nombre']}(*):" styleClass="label" />
<h:inputText
id="txtNombreEspacioFisico"
style="fontsize:13px!important;" size="60" maxlength="50"
value="#{espacioFisicoBacking.espacioFisico.efNombre}"
required="true"
requiredMessage="#{etiquetas['nombre']} Obligatorio" />
<rich:message
for="txtNombreEspacioFisico" ajaxRendered="true" />
<h:outputText
id="lblDescripcion"
value="#{etiquetas['descripcion']}(*):" styleClass="label" />
<h:inputTextarea
id="txtDescripcion"
style="fontsize:13px!important;"
value="#{espacioFisicoBacking.espacioFisico.efDescripcion}"
required="true"
cols="70" rows="2"
requiredMessage="#{etiquetas['descripcion']} Obligatorio" />
<rich:message
for="txtDescripcion" ajaxRendered="true" />
<h:outputText
id="lblImagen" value="#{etiquetas['imagen']}:(*)"
styleClass="label" />
<p:fileUpload
id="fulEspacioFisico" immediate="true"
fileUploadListener="#{espacioFisicoBacking.subirImagen}"
sizeLimit="512000" allowTypes="/(\.|\/)(gif|jpe?g|png)$/"
label="#{botones['elegir']}" mode="advanced" auto="true"
invalidFileMessage="Archivos aceptados: PNG,JPE,JPEG,GIF"
invalidSizeMessage="Archivo excede el tama\u00F1o" />
<p:message
for="fulEspacioFisico" />
<h:outputText
id="lblRaider" value="#{etiquetas['raider']}:(*)"
styleClass="label" />
<p:fileUpload
id="fulRaider" immediate="true"
fileUploadListener="#{espacioFisicoBacking.subirRaider}"
79
sizeLimit="512000"
label="#{botones['elegir']}" mode="advanced" auto="true"
invalidSizeMessage="Archivo excede el tama\u00F1o" />
<p:message
for="fulRaider" />
</h:panelGrid>
<br />
<h:outputText
id="lblCamposRequeridos"
value="#{etiquetas['campos.requeridos']}"
styleClass="label_small" />
</h:panelGroup>
<h:panelGrid columns="2">
<a4j:commandButton id="btnGuardar"
value="#{botones['guardar']}"
styleClass="btn"
action="#{espacioFisicoBacking.guardar}"
render="pnlListaEspaciosFisicos,pnlIngresoDatos"></a4j:commandButton>
<a4j:commandButton id="btnLimpiar"
value="#{botones['cancelar']}"
styleClass="btn"
action="#{loginBacking.cerrarSesion}"
render="pnlIngresoDatos"
execute="@this"></a4j:commandButton>
</h:panelGrid>
</fieldset>
<br />
<fieldset id="fsListaDatos">
<legend>
<h3>#{etiquetas['lista.datos']}</h3>
</legend>
<h:panelGrid id="pnlListaEspaciosFisicos"
style="textalign:center;background:#f0f0f0;">
<rich:dataTable id="dtEspacioFisico"
rows="3"
noDataLabel="No se
encontraron registros"
value="#{espacioFisicoBacking.espacioFisicoBean.espaciosFisicos}"
var="espacioFisico">
<f:facet
name="header">#{etiquetas['espacio.fisico']}</f:facet>
<rich:column id="cmlId"
style="text-align:center">
<f:facet
name="header">#{etiquetas['id']}</f:facet>
<h:outputText
id="lblId"
value="#{espacioFisico.idEspacioFisico}"
styleClass="colums_text" />
</rich:column>
<rich:column id="cmlNombre"
style="text-align:left;">
<f:facet
name="header">#{etiquetas['nombre']}</f:facet>
<h:outputText
id="lblNombre" value="#{espacioFisico.efNombre}"
styleClass="colums_text" />
</rich:column>
80
<rich:column
id="cmlDescripcion" style="text-align:center">
<f:facet
name="header">#{etiquetas['descripcion']}</f:facet>
<h:outputText
id="lblTipo" styleClass="colums_text"
value="#{espacioFisico.efDescripcion}" />
</rich:column>
<rich:column
id="cmlCapacidad"
style="textalign:center;font-size:12px!important;">
<f:facet
name="header">#{etiquetas['butacas']}</f:facet>
<h:outputText
id="lblCapacidad" styleClass="colums_text"
value="#{espacioFisico.efCapacidad}" />
</rich:column>
<rich:column id="cmlEliminar"
headerText="Eliminar"
style="textalign:center;">
<a4j:commandLink
id="btnEliminar" styleClass="no-decor"
oncomplete="#{rich:component('confirmPane')}.show()"
execute="@this">
<h:graphicImage
value="/images/delete.gif" />
<f:setPropertyActionListener value="#{espacioFisico}"
target="#{espacioFisicoBacking.espacioFisico}" />
</a4j:commandLink>
</rich:column>
<rich:column
id="cmlModificar" headerText="Modificar"
style="textalign:center">
<a4j:commandLink
id="btnActualizar" styleClass="no-decor"
action="#{espacioFisicoBacking.actualizar}" execute="@this"
render="pnlIngresoDatos">
<h:graphicImage
value="/images/edit.gif" />
<f:setPropertyActionListener value="#{espacioFisico}"
target="#{espacioFisicoBacking.espacioFisico}" />
</a4j:commandLink>
</rich:column>
</rich:dataTable>
<rich:dataScroller
for="dtEspacioFisico"
render="pnlListaEspaciosFisicos" />
</h:panelGrid>
</fieldset>
<a4j:jsFunction name="remove"
action="#{espacioFisicoBacking.eliminar}"
render="pnlLista,pnlIngresoDatos"
execute="@this"
81
oncomplete="#{rich:component('confirmPane')}.hide();" />
<rich:popupPanel id="confirmPane"
autosized="true">#{etiquetas['eliminar.mensaje']}
<h:panelGrid columns="2">
<a4j:commandButton
value="#{botones['cancelar']}"
onclick="#{rich:component('confirmPane')}.hide(); return false;" />
<a4j:commandButton
value="#{botones['eliminar']}"
onclick="remove(); return
false;" />
</h:panelGrid>
</rich:popupPanel>
</rich:panel>
</h:form>
</ui:define>
</ui:composition>
Tabla 43. IngresarEspacioFisico.xhtml
Programación de la lógica del negocio.
Para implementar la lógica del negocio se utilizan las clases controladoras. Estas a su
vez, utilizan las clases que se encuentran en el paquete ejb/servicios para ingresar o
modificar los datos en la base de datos.
Para el ejemplo propuesto se utiliza las siguientes clases: EspacioFisicoBacking.java,
EspacioFisicoBean.java, EspacioFisicoImpl.java.
/*
* Copyright 2014 UNIVERSIDAD CENTRAL DEL ECUADOR
* Todos los derechos reservados
*/
package ec.gob.casadelacultura.sistemaintegralcce.web.bean;
import java.util.ArrayList;
import java.util.List;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import
ec.gob.casadelacultura.sistemaintegralcce.core.entidades.EspacioFisico;
/**
* <b> Incluir aqui la descripcion de la clase. </b>
*
* @author Jenny Pucha
* @version $Revision: 1.0 $
*
<p>
*
[$Author: Jenny Pucha $, $Date: 12/11/2014 $]
*
</p>
*/
82
@ManagedBean(name = "espacioFisicoBean")
@SessionScoped
public class EspacioFisicoBean {
private List<EspacioFisico> espaciosFisicos;
private String formato;
/**
* @return the espaciosFisicos
*/
public List<EspacioFisico> getEspaciosFisicos() {
if (espaciosFisicos == null) {
espaciosFisicos = new ArrayList<EspacioFisico>();
}
return espaciosFisicos;
}
/**
* @param espaciosFisicos
*
the espaciosFisicos to set
*/
public void setEspaciosFisicos(List<EspacioFisico> espaciosFisicos)
{
this.espaciosFisicos = espaciosFisicos;
}
/**
* @return the formato
*/
public String getFormato() {
return formato;
}
/**
* @param formato
*
the formato to set
*/
public void setFormato(String formato) {
this.formato = formato;
}
}
Tabla 44. EspacioFisicoBean.java
/*
* Copyright 2014 UNIVERSIDAD CENTRAL DEL ECUADOR
* Todos los derechos reservados
*/
package ec.gob.casadelacultura.sistemaintegralcce.web.backing;
import java.io.IOException;
import
import
import
import
import
import
javax.annotation.PostConstruct;
javax.ejb.EJB;
javax.faces.bean.ManagedBean;
javax.faces.bean.ManagedProperty;
javax.faces.bean.ViewScoped;
javax.faces.context.FacesContext;
import org.apache.log4j.Logger;
import org.primefaces.event.FileUploadEvent;
import
83
ec.gob.casadelacultura.sistemaintegralcce.core.entidades.EspacioFisico;
import
ec.gob.casadelacultura.sistemaintegralcce.ejb.servicios.excepciones.ServiceE
xception;
import
ec.gob.casadelacultura.sistemaintegralcce.ejb.servicios.saltea.impl.EspacioF
isicoImpl;
import
ec.gob.casadelacultura.sistemaintegralcce.ejb.servicios.saltea.impl.EstadoIm
pl;
import ec.gob.casadelacultura.sistemaintegralcce.utilidades.Constantes;
import ec.gob.casadelacultura.sistemaintegralcce.utilidades.JsfUtils;
import ec.gob.casadelacultura.sistemaintegralcce.utilidades.Mensajes;
import ec.gob.casadelacultura.sistemaintegralcce.utilidades.MensajesBak;
import ec.gob.casadelacultura.sistemaintegralcce.web.base.ControladorBase;
import ec.gob.casadelacultura.sistemaintegralcce.web.bean.EspacioFisicoBean;
import
ec.gob.casadelacultura.sistemaintegralcce.web.reporte.ConstantesReportes;
import
ec.gob.casadelacultura.sistemaintegralcce.web.saltea.reporte.EspacioFisicoRe
porte;
/**
* <b> Incluir aqui la descripcion de la clase. </b>
*
* @author Jenny Pucha
* @version $Revision: 1.0 $
*
<p>
*
[$Author: Jenny Pucha $, $Date: 11/11/2014 $]
*
</p>
*/
@ManagedBean(name = "espacioFisicoBacking")
@ViewScoped
public class EspacioFisicoBacking extends ControladorBase {
private static final Logger LOG =
Logger.getLogger(EspacioFisicoBacking.class);
private boolean modificar;
private String imagenEspFisico;
private EspacioFisico;
private String destino;
@ManagedProperty(value = "#{espacioFisicoBean}")
private EspacioFisicoBean;
@EJB
private EspacioFisicoImpl;
@EJB
private EstadoImpl;
@PostConstruct
public void cargar() {
cargarEspacioFisico();
cargarImagenes();
}
public void guardar() throws IOException {
try {
if (modificar) {
espacioFisicoImpl.actualizarEspacioFisico(getEspacioFisico());
addInfoMessage(Mensajes.getString("actualizar.correcto"));
} else {
espacioFisicoImpl.ingresarEspacioFisico(getEspacioFisico());
addInfoMessage(Mensajes.getString("crear.correcto"));
}
84
cargarEspacioFisico();
setEspacioFisico(new EspacioFisico());
} catch (ServiceException e) {
addErrorMessage(e.getMessage());
}
}
public void eliminar() {
try {
espacioFisicoImpl.eliminarEspacioFisico(getEspacioFisico());
addInfoMessage(MensajesBak.ELIMINACION_CORRECTO);
setEspacioFisico(null);
cargarEspacioFisico();
} catch (Exception e) {
addInfoMessage(MensajesBak.ERROR_ELIMINACION);
}
}
public void cargarEspacioFisico() {
try {
getEspacioFisicoBean().setEspaciosFisicos(espacioFisicoImpl.obtenerEs
pacioFisicoOrder());
} catch (Exception e) {
addErrorMessage(e.getMessage());
}
}
public void actualizar() {
setModificar(true);
}
public void limpiar() {
setEspacioFisico(null);
}
/**
*
* <b> Metodo para subir a la imagen al servidor. </b>
* <p>
* [Author: Jenny Pucha, Date: 10/12/2014]
* </p>
*
* @param event
*/
public void subirImagen(FileUploadEvent event) {
LOG.info("entro al metodo subirImagen");
try {
getEspacioFisico().setEfImagen(event.getFile().getContents());
imagenEspFisico = Constantes.RUTA_IMAGENES +
event.getFile().getFileName();
getEspacioFisico().setEfRutaImagen(imagenEspFisico);
LOG.info("Documento " +
getEspacioFisico().getEfRutaImagen());
LOG.info("Imagen subida exitosamente");
addInfoMessage("Imagen subida exitosamente");
} catch (Exception e) {
LOG.info("Problemas al subir la imagen");
addErrorMessage("Problemas al subir la imagen");
}
}
/**
85
*
* <b> Metodo que extrae de la BD la imagen y la aloja en un
directorio
* temporal para que pueda ser visualizada. </b>
* <p>
* [Author: Jenny Pucha, Date: 19/12/2014]
* </p>
*
*/
public void cargarImagenes() {
for (EspacioFisico espacioFisicoVer :
espacioFisicoBean.getEspaciosFisicos()) {
LOG.info("espacioFisicoVer lst\n" +
espacioFisicoVer.getEfImagen());
JsfUtils.guardarByteEnficheroTemporal(espacioFisicoVer.getEfImagen(),
espacioFisicoVer.getEfNombreImagen(),
Boolean.TRUE);
JsfUtils.guardarByteEnficheroTemporal(espacioFisicoVer.getEfRaider(),
espacioFisicoVer.getEfNombreRaider(),
Boolean.FALSE);
}
}
/**
*
* <b> Permite la redirecion de la pagina </b>
* <p>
* [Author: Jenny Pucha, Date: 07/01/2015]
* </p>
*
* @return
*/
public String hacerReservacionBtn() {
return "/pages/Reservacion?faces-redirect=true";
}
public void imprimirReportePdf() {
try {
StringBuilder url = new StringBuilder();
url.append(FacesContext.getCurrentInstance().getExternalContext().get
RequestContextPath());
url.append(Constantes.REPORTE_SERVLET_URL_PATTERN +
ConstantesReportes.REPORTE_PARAMETRO_NOMBRE_CLASE_IMPL);
url.append(Constantes.CADENA_IGUAL +
EspacioFisicoReporte.class.getName());
espacioFisicoBean.setFormato(ConstantesReportes.REPORTE_PARAMETRO_FOR
MATO_PDF);
FacesContext.getCurrentInstance().getExternalContext().redirect(url.t
oString());
} catch (IOException e) {
}
}
public void imprimirReporteXls() {
try {
System.out.println("imprimir excel");
StringBuilder url = new StringBuilder();
url.append(FacesContext.getCurrentInstance().getExternalContext().get
RequestContextPath());
url.append(Constantes.REPORTE_SERVLET_URL_PATTERN +
ConstantesReportes.REPORTE_PARAMETRO_NOMBRE_CLASE_IMPL);
86
url.append(Constantes.CADENA_IGUAL +
EspacioFisicoReporte.class.getName());
espacioFisicoBean.setFormato(ConstantesReportes.REPORTE_PARAMETRO_FOR
MATO_XLS);
FacesContext.getCurrentInstance().getExternalContext().redirect(url.t
oString());
} catch (IOException e) {
}
}
public void subirRaider(FileUploadEvent event) {
LOG.info("entro al metodo subirRaider");
try {
getEspacioFisico().setEfRaider(event.getFile().getContents());
getEspacioFisico().setEfRutaRaider(Constantes.RUTA_DOCUMENTO +
event.getFile().getFileName());
LOG.info("Documento " +
getEspacioFisico().getEfRutaRaider());
LOG.info("Documento subido exitosamente");
addInfoMessage("Documento subido exitosamente");
} catch (Exception e) {
LOG.info("Problemas al subir el documento");
addErrorMessage("Problemas al subir el documento");
}
}
public void descargarRaider() {
LOG.info("entro al metodo ------->descargarRaider()");
StringBuilder url = new StringBuilder();
url.append(getContextPath());
url.append(getEspacioFisico().getEfRutaRaider());
System.out.println("1\n" + url.toString());
try {
FacesContext.getCurrentInstance().getExternalContext().redirect(url.t
oString());
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
/**
* @return the modificar
*/
public boolean isModificar() {
return modificar;
}
/**
* @param modificar
*
the modificar to set
*/
public void setModificar(boolean modificar) {
this.modificar = modificar;
}
/**
* @return the espacioFisicoBean
*/
public EspacioFisicoBean getEspacioFisicoBean() {
return espacioFisicoBean;
87
}
/**
* @param espacioFisicoBean
*
the espacioFisicoBean to set
*/
public void setEspacioFisicoBean(EspacioFisicoBean espacioFisicoBean)
{
this.espacioFisicoBean = espacioFisicoBean;
}
/**
* @return the imagenEspFisico
*/
public String getImagenEspFisico() {
return imagenEspFisico;
}
/**
* @param imagenEspFisico
*
the imagenEspFisico to set
*/
public void setImagenEspFisico(String imagenEspFisico) {
this.imagenEspFisico = imagenEspFisico;
}
/**
* @return the espacioFisico
*/
public EspacioFisico getEspacioFisico() {
if (espacioFisico == null) {
espacioFisico = new EspacioFisico();
}
return espacioFisico;
}
/**
* @param espacioFisico
*
the espacioFisico to set
*/
public void setEspacioFisico(EspacioFisico espacioFisico) {
this.espacioFisico = espacioFisico;
}
/**
* @return the destino
*/
public String getDestino() {
return destino;
}
/**
* @param destino
*
the destino to set
*/
public void setDestino(String destino) {
this.destino = destino;
}
}
Tabla 45. EspacioFisicoBacking.java
88
/*
* Copyright 2014 UNIVERSIDAD CENTRAL DEL ECUADOR
* Todos los derechos reservados
*/
package ec.gob.casadelacultura.sistemaintegralcce.ejb.servicios.saltea.impl;
import java.util.ArrayList;
import java.util.List;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import org.apache.log4j.Logger;
import
ec.gob.casadelacultura.sistemaintegralcce.core.entidades.EspacioFisico;
import
ec.gob.casadelacultura.sistemaintegralcce.core.saltea.dao.EspacioFisicoJpa;
import
ec.gob.casadelacultura.sistemaintegralcce.ejb.servicios.excepciones.ServiceE
xception;
import ec.gob.casadelacultura.sistemaintegralcce.utilidades.Constantes;
import ec.gob.casadelacultura.sistemaintegralcce.utilidades.MensajesBak;
/**
* @author Jenny Pucha
*
*/
@Stateless
public class EspacioFisicoImpl {
private static final Logger log =
Logger.getLogger(EspacioFisicoImpl.class);
@EJB
private EspacioFisicoJpa espacioFisicoJpa;
public void ingresarEspacioFisico(EspacioFisico espacioFisico) throws
ServiceException {
try {
espacioFisicoJpa.insertar(espacioFisico);
} catch (Exception e) {
log.error(Constantes.ERROR_INSERTAR_ENTIDAD +
espacioFisico, e);
throw new ServiceException(MensajesBak.ERROR_INGRESO);
}
}
public void actualizarEspacioFisico(EspacioFisico espacioFisico)
throws ServiceException {
try {
espacioFisicoJpa.actualizar(espacioFisico);
} catch (Exception e) {
log.error(Constantes.ERROR_ACTUALIZAR_ENTIDAD +
espacioFisico, e);
throw new
ServiceException(MensajesBak.ERROR_ACTUALIZACION);
}
}
public void eliminarEspacioFisico(EspacioFisico espacioFisico) throws
ServiceException {
try {
espacioFisicoJpa.eliminar(espacioFisico);
} catch (Exception e) {
log.error(Constantes.ERROR_ELIMINAR_ENTIDAD +
espacioFisico, e);
throw new
ServiceException(MensajesBak.ERROR_ELIMINACION);
89
}
}
public List<EspacioFisico> buscarEspacioFisico() throws
ServiceException {
List<EspacioFisico> espaciosFisicos = new
ArrayList<EspacioFisico>();
try {
espaciosFisicos = espacioFisicoJpa.buscarTodos();
} catch (Exception e) {
log.error(Constantes.ERROR_BUSCAR_ENTIDADES +
espaciosFisicos, e);
throw new
ServiceException(MensajesBak.ERROR_BUSCAR_CABEZA);
}
return espaciosFisicos;
}
public EspacioFisico buscarPorIdEspacioFisico(int id) throws
ServiceException {
EspacioFisico espacioFisico = new EspacioFisico();
try {
espacioFisico = espacioFisicoJpa.buscarPorId(id);
} catch (Exception e) {
log.error(Constantes.ERROR_BUSCAR_ENTIDAD_POR_ID +
espacioFisico, e);
throw new
ServiceException(MensajesBak.ERROR_BUSCAR_CUENTA);
}
return espacioFisico;
}
public List<EspacioFisico> obtenerEspacioFisicoOrder() throws
ServiceException {
List<EspacioFisico> instalaciones = new
ArrayList<EspacioFisico>();
try {
instalaciones =
espacioFisicoJpa.obtenerEspacioFisicoOrder();
} catch (Exception e) {
// TODO: handle exception
log.error(Constantes.ERROR_BUSCAR_ENTIDADES +
instalaciones, e);
throw new
ServiceException(MensajesBak.ERROR_BUSCAR_CUENTA);
}
return instalaciones;
}
}
Tabla 46. EspacioFisicoImpl.java
Programación de la persistencia.
Para implementar la capa de persistencia se utiliza las clases que está en el paquete
core/entidades, estas son clase java las cuales persisten los datos.
Para el ejemplo presentado se muestra a continuación como está formada la clase
EspacioFisico.java.
90
package ec.gob.casadelacultura.sistemaintegralcce.core.entidades;
import java.io.Serializable;
import java.util.List;
import
import
import
import
import
import
javax.persistence.Column;
javax.persistence.Entity;
javax.persistence.Id;
javax.persistence.OneToMany;
javax.persistence.Table;
javax.persistence.Transient;
/**
* The persistent class for the espacio_fisico database table.
*
*/
@Entity
@Table(name = "espacio_fisico")
public class EspacioFisico implements Serializable {
private static final long serialVersionUID = 1L;
@Id
@Column(name = "id_espacio_fisico")
private Integer idEspacioFisico;
@Column(name = "ef_capacidad")
private Integer efCapacidad;
@Column(name = "ef_descripcion")
private String efDescripcion;
@Column(name = "ef_imagen")
private byte[] efImagen;
@Column(name = "ef_nombre")
private String efNombre;
@Column(name = "ef_ruta_imagen")
private String efRutaImagen;
@Transient
@Column(name = "ef_nombre_imagen")
private String efNombreImagen;
@Column(name = "ef_raider")
private byte[] efRaider;
@Column(name = "ef_ruta_raider")
private String efRutaRaider;
@Transient
@Column(name = "ef_nombre_raider")
private String efNombreRaider;
// bi-directional many-to-one association to Reservacion
@OneToMany(mappedBy = "espacioFisico")
private List<Reservacion> reservacions;
public EspacioFisico() {
}
public Integer getIdEspacioFisico() {
return this.idEspacioFisico;
}
public void setIdEspacioFisico(Integer idEspacioFisico) {
this.idEspacioFisico = idEspacioFisico;
}
91
public Integer getEfCapacidad() {
return this.efCapacidad;
}
public void setEfCapacidad(Integer efCapacidad) {
this.efCapacidad = efCapacidad;
}
public String getEfDescripcion() {
return this.efDescripcion;
}
public void setEfDescripcion(String efDescripcion) {
this.efDescripcion = efDescripcion;
}
public String getEfNombre() {
return this.efNombre;
}
public void setEfNombre(String efNombre) {
this.efNombre = efNombre;
}
public List<Reservacion> getReservacions() {
return this.reservacions;
}
public void setReservacions(List<Reservacion> reservacions) {
this.reservacions = reservacions;
}
/**
* @return the efImagen
*/
public byte[] getEfImagen() {
return efImagen;
}
/**
* @param efImagen
*
the efImagen to set
*/
public void setEfImagen(byte[] efImagen) {
this.efImagen = efImagen;
}
/**
* @return the efRutaImagen
*/
public String getEfRutaImagen() {
return efRutaImagen;
}
/**
* @param efRutaImagen
*
the efRutaImagen to set
*/
public void setEfRutaImagen(String efRutaImagen) {
this.efRutaImagen = efRutaImagen;
}
/**
* @return the efNombreImagen
*/
public String getEfNombreImagen() {
efNombreImagen = efRutaImagen.substring(21);
return efNombreImagen;
92
}
/**
* @param efNombreImagen
*
the efNombreImagen to set
*/
public void setEfNombreImagen(String efNombreImagen) {
this.efNombreImagen = efNombreImagen;
}
/**
* @return the efRaider
*/
public byte[] getEfRaider() {
return efRaider;
}
/**
* @param efRaider
*
the efRaider to set
*/
public void setEfRaider(byte[] efRaider) {
this.efRaider = efRaider;
}
/**
* @return the efRutaRaider
*/
public String getEfRutaRaider() {
return efRutaRaider;
}
/**
* @param efRutaRaider the efRutaRaider to set
*/
public void setEfRutaRaider(String efRutaRaider) {
this.efRutaRaider = efRutaRaider;
}
/**
* @return the efNombreRaider
*/
public String getEfNombreRaider() {
return efNombreRaider;
}
/**
* @param efNombreRaider the efNombreRaider to set
*/
public void setEfNombreRaider(String efNombreRaider) {
this.efNombreRaider = efNombreRaider;
}
}
Tabla 47. EspacioFisico.java
3.2.3.3 Seguimiento de las iteraciones
93
Primera iteración
Cuando se empezó con la implementación de los casos de uso, tomó más tiempo del
estimado; esto se debió a que el equipo de desarrollo no tenía la suficiente
experiencia en el uso del Framework JSF y tuvo que aprender esta tecnología, por
esta razón se produjo un incremento en el tiempo estimado para la realización de la
primera iteración.
Segunda iteración
Durante toda la iteración el esfuerzo real de los casos de uso fue mayor al estimado;
debido a que, en esta iteración se planificó la realización de los casos de uso más
complejos, como por ejemplo el del módulo de reservas; se consideran complejos por
su grado de dependencia con los casos de uso implementados en la primera iteración.
Tercera iteración
En esta iteración se observó que el esfuerzo real es menor al estimado durante toda la
iteración. Esto se debe a que el equipo de desarrollo adquirió experiencia en el uso de
la tecnología de desarrollo, se mejoró la comunicación con el cliente y se reutilizó
gran parte del código que se desarrolló en las anteriores iteraciones.
3.2.4 Fase IV: Producción
En esta fase se realizará pruebas de aceptación por parte del usuario final con la
finalidad de corregir cualquier error que haya surgido durante la construcción del
sistema.
94
3.2.4.1 Pruebas de aceptación
A continuación se presentan las versiones finales de las pruebas de aceptación diseñadas
para la implantación del sistema.
Número de prueba: 01
Caso de uso: CU-01
Precondiciones: Usuario debe haberse registrado en el sistema.
Entrada:
Ingresar a la página de login del sistema.
Digitar usuario y contraseña.
Presionar el botón 'INGRESAR'
Resutado esperado 1:
Se comprueba si los datos ingresados coinciden con los almacenados.
Ingresar al módulo de administración.
Resutado esperado 2:
Si los datos ingresados no coinciden con los almacenados, se muestra un mensaje
de error.
Usuario no puede ingresar al módulo de administración.
Tabla 48. Prueba de aceptación CU-01
Número de prueba: 02
Caso de uso: CU-02
Precondiciones: Usuario debe haber ingresado mediante el login al sistema.
Entrada:
Presionar el botón 'Salir'
Resutado esperado 1:
Sistema cierra todas las sesiones abiertas.
Se dirige a la pantalla del login.
Tabla 49. Prueba de aceptación CU-02
95
Número de prueba: 03
Caso de uso: CU-03
Precondiciones: Usuario debe haberse logueado correctamente.
Entrada:
Administrador se dirige a la pantalla de administración de empleados.
Administrador busca la empleado el cual va a reestablecer su contraseña
Administrador edita los datos.
Administrador guarda los datos editados.
Resutado esperado 1:
Sistema hace el cambio de contraseña exitoso.
Sistema presenta mensaje de cambio exitoso.
Resultado esperado 2:
Sistema no realiza el cambio de contraseña.
Sistema presenta mensaje de error.
Tabla 50. Prueba de aceptación CU-03
Número de prueba: 04
Caso de uso: CU-04
Precondiciones:
Usuario debe tener el rol de ADMINISTRADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario se dirige a la pantalla de crear empleados mediante el menú de
administración.
Usuario ingresa los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Administrador presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que el ingreso de los campos sea correcto.
Sistema presenta mensaje de éxito.
Resutado esperado 2:
Sistema verifica que uno o todos los campos obligatorios no están ingresados.
Sistema presenta mensaje de error.
Tabla 51. Prueba de aceptación CU-04
96
Número de prueba: 05
Caso de uso: CU-05
Precondiciones:
Usuario debe tener el rol de ADMINISTRADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Mediante el menú de administración, usuario se dirige a la pantalla donde
actualizará empleados .
Sistema presenta una tabla en la cual se disponen todos los empleados
registrados.
Usuario presiona el botón 'Actualizar' .
Sistema carga los datos y los presenta en pantalla.
Usuario modifica los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Administrador presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que la modificación de los campos sea correcto.
Sistema presenta mensaje de éxito, cuando los datos se han guardado sin
problemas.
Resutado esperado 2:
De existir algún problema con la edición de los datos, sistema presenta mensaje
de error.
Tabla 52. Prueba de aceptación CU-05
97
Número de prueba: 06
Caso de uso: CU-06
Precondiciones:
Usuario debe tener el rol de ADMINISTRADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Mediante el menú de administración, usuario se dirige a la pantalla donde
eliminará empleados.
Sistema presenta una tabla en la cual se disponen todos los empleados
registrados.
Usuario presiona el botón 'Eliminar' .
Sistema presenta mensaje de confirmación para eliminar el registro.
Usuario presiona botón 'Aceptar'.
Resutado esperado 1:
Sistema elimina empleado.
Sistema refresca la tabla de empleados.
Sistema presenta mensaje de éxito, cuando los datos se han eliminado.
Resutado esperado 2:
De existir algún problema con la eliminación de los datos, sistema presenta
mensaje de error.
Tabla 53. Prueba de aceptación CU-06
Número de prueba: 07
Caso de uso: CU-07
Precondiciones:
Usuario debe tener el rol de ADMINISTRADOR.
Usuario debe haberse logueado correctamente.
Usuario debe situarse en la pantalla de actualización y eliminación de empleados.
Entrada:
Sistema presenta una tabla en la cual se disponen todos los empleados
registrados.
Resutado esperado 1:
Si existen registros almacenados, se presentan en la tabla.
Resutado esperado 2:
Si no existen registros la tabla muestra el mensaje 'No se encontraron registros'
Tabla 54. Prueba de aceptación CU-07
98
Número de prueba: 08
Caso de uso: CU-08
Precondiciones:
Usuario debe tener el rol de COORDINADOR
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Complementarios', sub sub ítem ' Instalación'
Usuario ingresa los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Usuario presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que el ingreso de los campos sea correcto.
Sistema presenta mensaje de éxito.
Resutado esperado 2:
De existir al inconveniente al momento de registrar los datos, el sistema presenta
mensaje de error.
Tabla 55. Prueba de aceptación CU-08
Número de prueba: 09
Caso de uso: CU-09
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Complementarios', sub sub ítem ' Instalación'
Sistema presenta una tabla en la cual se disponen todos las instalaciones
registradas.
Usuario presiona el botón 'Actualizar' .
Sistema carga los datos y los presenta en pantalla.
Usuario modifica los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Administrador presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que la modificación de los campos sea correcto.
Sistema presenta mensaje de éxito, cuando los datos se han guardado sin
problemas.
Resutado esperado 2:
De existir algún problema con la edición de los datos, sistema presenta mensaje
de error.
Tabla 56. Prueba de aceptación CU-09
99
Número de prueba: 10
Caso de uso: CU-10
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', subítem
'Administración Complementarios', sub sub ítem ' Instalación'
Sistema presenta una tabla en la cual se disponen todos las instalaciones
registradas.
Usuario presiona el botón 'Eliminar'.
Sistema presenta mensaje de confirmación para eliminar el registro.
Usuario presiona botón 'Aceptar'.
Resutado esperado 1:
Sistema elimina la instalación
Sistema refresca la tabla Espacios Físicos.
Sistema presenta mensaje de éxito, cuando los datos se han eliminado.
Resutado esperado 2:
De existir algún problema con la eliminación de los datos, sistema presenta
mensaje de error.
Tabla 57. Prueba de aceptación CU-10
Número de prueba: 11
Caso de uso: CU-11
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', subítem
'Administración Complementarios', sub sub ítem ' Instalación'
Sistema presenta una tabla en la cual se disponen todas las instalaciones
registradas.
Resutado esperado 1:
Si existen registros almacenados, se presentan en la tabla.
Resutado esperado 2:
Si no existen registros la tabla muestra el mensaje 'No se encontraron registros'
Tabla 58. Prueba de aceptación CU-11
100
Número de prueba: 12
Caso de uso: CU-12
Precondiciones:
Cliente se dirige a la pantalla de inicio.
Entrada:
Cliente da clic en el menú ítem 'Hacer Reservaciones', sub ítem 'Proceso de
Reservación', sub sub ítem ' Registrar/Actualizar Cliente'
Cliente ingresa tipo y número de identificación.
Cliente presiona el botón BUSCAR'.
Sistema presenta los campos vacíos.
Cliente ingresa los datos que se presentan en la pantalla.
Cliente debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Cliente presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que el ingreso de los campos sea correcto.
Sistema presenta mensaje de éxito.
Resutado esperado 2:
De existir al inconveniente al momento de registrar los datos, el sistema presenta
mensaje de error.
Tabla 59. Prueba de aceptación CU-12
Número de prueba: 13
Caso de uso: CU-13
Precondiciones:
Cliente se dirige a la pantalla de inicio.
Entrada:
Cliente da clic en el menú ítem 'Hacer Reservaciones', sub ítem 'Proceso de
Reservación', sub sub ítem ' Registrar/Actualizar Cliente'
Cliente ingresa tipo y número de identificación.
Cliente presiona el botón BUSCAR'.
Sistema carga los datos y los presenta en pantalla.
Usuario modifica los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Administrador presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que la modificación de los campos sea correcto.
Sistema presenta mensaje de éxito, cuando los datos se han guardado sin
problemas.
Resutado esperado 2:
De existir algún problema con la edición de los datos, sistema presenta mensaje
de error.
Tabla 60. Prueba de aceptación CU-13
101
Número de prueba: 14
Caso de uso: CU-14
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Reservaciones', sub sub ítem 'Clientes'
Sistema presenta una tabla en la cual se disponen todos los clientes registrados.
Usuario presiona el botón 'Eliminar'.
Sistema presenta mensaje de confirmación para eliminar el registro.
Usuario presiona botón 'Aceptar'.
Resutado esperado 1:
Sistema elimina el cliente
Sistema refresca la tabla de Clientes
Sistema presenta mensaje de éxito, cuando los datos se han eliminado.
Resutado esperado 2:
De existir algún problema con la eliminación de los datos, sistema presenta
mensaje de error.
Tabla 61. Prueba de aceptación CU-14
Número de prueba: 15
Caso de uso: CU-15
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Reservaciones', sub sub ítem 'Clientes'
Sistema presenta una tabla en la cual se disponen todas los clientes registrados.
Resutado esperado 1:
Si existen registros almacenados, se presentan en la tabla.
Resutado esperado 2:
Si no existen registros la tabla muestra el mensaje 'No se encontraron registros'
Tabla 62. Prueba de aceptación CU-15
102
Número de prueba: 16
Caso de uso: CU-16
Precondiciones:
Usuario debe tener el rol de COORDINADOR
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Complementarios', sub sub ítem 'Estados'
Usuario ingresa los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Usuario presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que el ingreso de los campos sea correcto.
Sistema presenta mensaje de éxito.
Resutado esperado 2:
De existir al inconveniente al momento de registrar los datos, el sistema presenta
mensaje de error.
Tabla 63. Prueba de aceptación CU-16
Número de prueba: 17
Caso de uso: CU-17
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', subítem
'Administración Complementarios', sub sub ítem 'Estados'
Sistema presenta una tabla en la cual se disponen todos los estados registrados.
Usuario presiona el botón 'Actualizar'.
Sistema carga los datos y los presenta en pantalla.
Usuario modifica los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Administrador presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que la modificación de los campos sea correcto.
Sistema presenta mensaje de éxito, cuando los datos se han guardado sin
problemas.
Resutado esperado 2:
De existir algún problema con la edición de los datos, sistema presenta mensaje
de error.
Tabla 64. Prueba de aceptación CU-17
103
Número de prueba: 18
Caso de uso: CU-18
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Complementarios', sub sub ítem 'Estados'
Sistema presenta una tabla en la cual se disponen todos los estados registrados.
Usuario presiona el botón 'Eliminar' .
Sistema presenta mensaje de confirmación para eliminar el registro.
Usuario presiona botón 'Aceptar'.
Resutado esperado 1:
Sistema elimina el estado.
Sistema refresca la tabla Estados.
Sistema presenta mensaje de éxito, cuando los datos se han eliminado.
Resutado esperado 2:
De existir algún problema con la eliminación de los datos, sistema presenta
mensaje de error.
Tabla 65. Prueba de aceptación CU-18
Número de prueba: 19
Caso de uso: CU-19
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Complementarios', sub sub ítem 'Estados'
Sistema presenta una tabla en la cual se disponen todos los estados registrados.
Resutado esperado 1:
Si existen registros almacenados, se presentan en la tabla.
Resutado esperado 2:
Si no existen registros la tabla muestra el mensaje 'No se encontraron registros'
Tabla 66. Prueba de aceptación CU-19
104
Número de prueba: 20
Caso de uso: CU-20
Precondiciones:
Usuario debe tener el rol de COORDINADOR
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Complementarios', sub sub ítem 'Tipo Identificación'
Usuario ingresa los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Usuario presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que el ingreso de los campos sea correcto.
Sistema presenta mensaje de éxito.
Resutado esperado 2:
De existir al inconveniente al momento de registrar los datos, el sistema presenta
mensaje de error.
Tabla 67. Prueba de aceptación CU-20
Número de prueba: 21
Caso de uso: CU-21
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Complementarios', sub sub ítem 'Tipo Identificación'
Sistema presenta una tabla en la cual se disponen todos los tipo de identificación
registrados.
Usuario presiona el botón 'Actualizar'.
Sistema carga los datos y los presenta en pantalla.
Usuario modifica los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Administrador presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que la modificación de los campos sea correcto.
Sistema presenta mensaje de éxito, cuando los datos se han guardado sin
problemas.
Resutado esperado 2:
De existir algún problema con la edición de los datos, sistema presenta mensaje
de error.
Tabla 68. Prueba de aceptación CU-21
105
Número de prueba: 22
Caso de uso: CU-22
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Complementarios', sub sub ítem 'Tipo Identificación'
Sistema presenta una tabla en la cual se disponen todos los tipos de identificación
registrados.
Usuario presiona el botón 'Eliminar'.
Sistema presenta mensaje de confirmación para eliminar el registro.
Usuario presiona botón 'Aceptar'.
Resutado esperado 1:
Sistema elimina el tipo de identificación.
Sistema refresca la tabla Tipos de identificación.
Sistema presenta mensaje de éxito, cuando los datos se han eliminado.
Resutado esperado 2:
De existir algún problema con la eliminación de los datos, sistema presenta
mensaje de error.
Tabla 69. Prueba de aceptación CU-22
Número de prueba: 23
Caso de uso: CU-23
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Complementarios', sub sub ítem 'Tipo Identificación'
Sistema presenta una tabla en la cual se disponen todos los tipo de identificación
registrados.
Resutado esperado 1:
Si existen registros almacenados, se presentan en la tabla.
Resutado esperado 2:
Si no existen registros la tabla muestra el mensaje 'No se encontraron registros'
Tabla 70. Prueba de aceptación CU-23
106
Número de prueba: 24
Caso de uso: CU-24
Precondiciones:
Cliente se situa en la página de inicio
Entrada:
Usuario da clic en el menú ítem 'Hacer reservaciones', sub ítem 'Proceso de
reservación', sub sub ítem 'Reservar'.
Sistema presenta pantalla en la cual se muestra información de los espacios
físicos que se tienen almacenados, con la finalidad que el cliente se informe y
pueda seleccionar el espacio físico que mejor se adapte a sus necesidades.
Para continuar con el proceso de reservación, cliente debe hacer clic en el botón
'Haga su reserva'
Resutado esperado 1:
Si existen registros almacenados, se presentan en la tabla.
Resutado esperado 2:
Si no existen registros la tabla muestra el mensaje 'No se encontraron registros'
Tabla 71. Prueba de aceptación CU-24
Número de prueba: 25
Caso de uso: CU-25
Precondiciones:
Cliente debe haber seleccionado una instalación.
Entrada:
Sistema muestra en la parte superior de la pantalla el nombre de la instalación
que se seleccionó en el paso anterior.
Cliente debe ingresar los campos de fecha.
Cliente presiona el botón 'VERIFICAR'.
Resutado esperado 1:
Si las fechas ingresadas no presentan conflicto con otras fechas que ya están
almacendas, el sistema permite continuar con el siguiente paso.
Resutado esperado 2:
Si las fechas ingresadas presentan conflicto con otras fechas almacenadas, el
sistema presenta un mensaje de error.
Sistema presenta una tabla en la cual se presentan las fechas con las cuales tiene
conflicto.
Tabla 72. Prueba de aceptación CU-25
107
Número de prueba: 26
Caso de uso: CU-26
Precondiciones:
Cliente debe haber seleccionado fechas las cuales no tengan conflicto con
aquellas que ya están en proceso.
Entrada:
Sistema muestra campos para asociar el cliente quién se hará responsable de la
reservación.
Cliente debe ingresar los campos.
Cliente presiona el botón 'BUSCAR'.
Resutado esperado 1:
Si el cliente ya existe almacenado en la base de datos, se asocia a la reservación.
Sistema permite continuar con el siguiente paso.
Resutado esperado 2:
Si el cliente no es encontrado, se presenta un mensaje de error.
Cliente debe ir a crearlo primero.
Tabla 73. Prueba de aceptación CU-26
Número de prueba: 27
Caso de uso: CU-27
Precondiciones:
Cliente debe haber asociado un cliente a la reservación.
Entrada:
Sistema muestra la información que se ha ingresado en los pasos anteriores, en la
parte superior de la pantalla.
Sistema muestra los campos que deben ser ingresados y son complementarios
para la reservación.
Cliente debe ingresar los campos.
Cliente presiona el botón 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que el ingreso de los campos sea correcto.
Sistema presenta mensaje de éxito.
Sistema envía un mensaje de correo electrónico, que será la confirmación de que
la reservación se encuentra creada, a la espera de contestación por parte de la
Dirección de teatros.
Resutado esperado 2:
De existir al inconveniente al momento de registrar los datos, el sistema presenta
mensaje de error.
Tabla 74. Prueba de aceptación CU-27
108
Número de prueba: 28
Caso de uso: CU-28
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Reservaciones', sub sub ítem 'Reservaciones'
Sistema presenta una tabla en la cual se disponen todos las reservaciones
registradas.
Se presentan filtros para realizar búsquedas.
Usuario presiona el botón 'Actualizar'.
Sistema carga los datos y los presenta en pantalla.
Usuario modifica los datos que se presentan en la pantalla.
Usuario debe ingresar todos campos que están marcados como obligatorios.
Sistema realiza las validaciones.
Administrador presiona 'GUARDAR'.
Resutado esperado 1:
Sistema verifica que la modificación de los campos sea correcto.
Sistema presenta mensaje de éxito, cuando los datos se han guardado sin
problemas.
Resutado esperado 2:
De existir algún problema con la edición de los datos, sistema presenta mensaje
de error.
Tabla 75. Prueba de aceptación CU-28
Número de prueba: 29
Caso de uso: CU-29
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Reservaciones', sub sub ítem 'Reservaciones'
Sistema presenta una tabla en la cual se disponen todas las reservaciones
registradas.
Usuario presiona el botón 'Eliminar'.
Sistema presenta mensaje de confirmación para eliminar el registro.
Usuario presiona botón 'Aceptar'.
Resutado esperado 1:
Sistema elimina la reservación.
Sistema refresca la tabla Reservaciones.
Sistema presenta mensaje de éxito, cuando los datos se han eliminado.
Resutado esperado 2:
De existir algún problema con la eliminación de los datos, sistema presenta
mensaje de error.
Tabla 76. Prueba de aceptación CU-29
109
Número de prueba: 30
Caso de uso: CU-30
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem
'Administración Reservaciones', sub sub ítem 'Reservaciones'
Sistema presenta una tabla en la cual se disponen todos las reservaciones
registradas.
Resutado esperado 1:
Si existen registros almacenados, se presentan en la tabla.
Resutado esperado 2:
Si no existen registros la tabla muestra el mensaje 'No se encontraron registros'
Tabla 77. Prueba de aceptación CU-30
Número de prueba: 31
Caso de uso: CU-31
Precondiciones:
Usuario debe tener el rol de COORDINADOR.
Usuario debe haberse logueado correctamente.
Entrada:
Usuario da clic en el menú ítem 'Coordinar Reservaciones', sub ítem 'Reportes',
sub sub ítem 'Uso Instalaciones'
Sistema muestra una pantalla y en la parte superior esta los criterios, los cuales
nos sirven para realizar la búsqueda.
Cliente ingresa los filtros.
Cliente presiona el botón 'BUSCAR'
Sistema presenta una tabla en la cual se presentan los resultados de la búsqueda.
El sistema presenta un botón el cual nos sirve para exportar los datos consultados
en formato PDF.
Resutado esperado 1:
Si existen registros almacenados, se presentan en la tabla.
Resutado esperado 2:
Si no existen registros la tabla muestra el mensaje 'No se encontraron registros'
Tabla 78. Prueba de aceptación CU-31
110
3.2.4.2 Planificación de la implantación
Después de culminar con el desarrollo del sistema en su totalidad, el equipo de desarrollo
y el cliente se reúnen para planificar su implantación.
Para la implantación se planifica las siguientes actividades:
1. Definición de los requisitos de software y hardware para la instalación del
sistema SICCE-TS.
2. Configuración de los componentes de software que se requieren para instalar la
aplicación.
3. Publicar la aplicación web.
Definición de Requisitos de instalación

Hardware
o Servidor Web.

Procesador de servidor, se recomienda Línea Intel(R) Xeon(R)

Memoria RAM mínima de 4 GB

Disco Duro mínimo de 100 GB

Mínimo un puerto de red Ethernet.
o Computadoras cliente.


Capacidad para soportar visualización XHTML.
Software
o Servidor

Sistema operativo: Linux, CentOS 6.5

Motor de Base de Datos PostgreSQL 9.0 ó superior

jdk1.6.0_29

Servidor de Aplicaciones JBoss AS 7.1.1 Final
o Cliente

Navegador Web con soporte para javascript, pueden ser:
111

Mozilla Firefox 10.0 o superior

Google Chrome 10.0 o superior

Internet Explorer 8 o superior
Configuración del ambiente de instalación.

Motor de Base de Datos.
o Descargar el paquete de instalación de PostgreSQL de la página del
proveedor.
o Instalar PostgreSQL en el Sistema Operativo (Linux).
o Configurar los parámetros del servidor de Base de Datos.


IP del Servidor.

Puerto de comunicación.

Número máximo de conexiones al servidor.
Servidor de Aplicaciones.
o
Descargar el jdk1.6.0_29 de la página del proveedor.
o Instalar el jdk1.6.0_29
o Descargar el paquete de instalación del Servidor JBoss de la página del
proveedor.
o Crear el directorio del Servidor JBoss con el contenido obtenido del
paquete de instalación.
o Configurar los parámetros del Servidor de Aplicaciones.

IP del Servidor

Puerto de Comunicaciones

Las variables de ubicación de la aplicación web.
Publicación de la aplicación web del sistema SICCE-TS.

Crear la base de datos para el sistema.

Crear las tablas de la base de datos.
112

Ingresar los valores por defecto en las tablas de la Base de Datos del sistema.

Configurar en la aplicación web los parámetros de conexión con la base de datos
del sistema.

Iniciar el Servidor de Aplicaciones JBoss

Publicar la aplicación web en el servidor JBoss
Vista de despliegue
La vista de despliegue representa la disposición de componentes de ejecución en
instancias de nodos conectados por enlaces de comunicación. En este punto se presentó
la siguiente solución.
Figura 28. Vista de despliegue SICCE-TS
113
CAPÍTULO 4
4.1 RESPALDOS DE INFORMACIÓN
Una vez que el sistema entre en producción será de suma importancia realizar un
respaldo de los datos y la información que genere SICCE-TS. En este capítulo se
pretende mostrar cómo llevar a cabo un proceso preventivo denominado “respaldo” o
“backup” el cuál nos garantiza que la Institución pueda disponer de la información en
el momento que sea requerida cuando se presente una eventualidad.
Incendios
3,5% 3,5% 2,9%
Terrrismo/Sabotaje
5,3%
Agentes atmosféricos
17,5%
Terremotos
7,0%
17,5%
8,8%
Caídas Eléctricas
Errores de Software
9,5%
10,5%
14,0%
Inundaciones
Errores de Hardware
Rotura de conducción
Fallo de red
Otros
Figura 29.Riesgos que se encuentran inmersos en los sistemas5
4.1.1 Backup
Un backup se puede definir como una réplica de información, sin ningún tipo de
arreglo sobre la misma. Dicho duplicado debe almacenarse en un medio distinto al
que se encuentra la información original, ya que si ocurriera algún inconveniente en
5
Fuente:
Obtenida
el
01
de
abril,
2015
<http://www.monografias.com/trabajos14/respaldoinfo/respaldoinfo.shtml >
114
de:
el medio donde se encuentra almacenada la información original (rotura, robo, fallo
software, etc.) el backup realizado no se podría recuperar.
Dado que el objetivo de un respaldo es garantizar la recuperación de la información,
en caso de que haya sido eliminada, dañada o alterada al presentarse alguna
contingencia.
Por esta razón es recomendable que los respaldos se lleven a cabo en unidades de
almacenamiento secundario, como discos duros externos, discos compactos e incluso
en la nube (Internet) o en otros equipos de cómputo, locales o remotos.
4.1.2 Tipos de respaldos

Respaldo global (full back-up)
Se realiza un respaldo completo del disco, se respalda la totalidad de las bases
de datos y la totalidad de las operaciones que se mantienen en línea (on–line).
Al realizarlo a diario, ante cualquier problema solamente se debe recuperar el
respaldo del día anterior.

Respaldo parcial
Hay varios criterios para elegir qué parte respaldar por ejemplo una
aplicación, una plataforma, los datos críticos o las bases de datos. Se respalda
sólo una parte de la información.

Respaldo incremental
Es la combinación de respaldos globales o parciales. Se respalda únicamente
las modificaciones que han ocurrido desde el último respaldo. Para realizar
una recuperación se debe adicionar al último respaldo global todos los
respaldos incrementales sucesivos. Es un procedimiento de respaldo ágil y
que ocupa poco espacio. El procedimiento de recuperación es complejo.

Respaldo diferencial
Similar al anterior. Se respalda las modificaciones que han ocurrido desde el
último respaldo global o parcial. Para hacer una recuperación se debe
115
adicionar al último respaldo global solamente el último respaldo diferencial.
Es un procedimiento de respaldo relativamente ágil y que ocupa poco
espacio, con un procedimiento de recuperación de sólo dos etapas.

Respaldo simultáneo
Se realiza una copia exactamente igual al mismo tiempo de todos los datos
procesados, por ejemplo con un sistema de discos espejados. Recuperar los
datos es simplemente direccionarse a otra unidad de disco.
Como se puede evidenciar, todos los tipos de respaldo descritos anteriormente tienen
sus ventajas y sus desventajas.
El respaldo global es el más seguro ya que se tiene la totalidad de los datos, pero
también es el que insume mayor cantidad de tiempo y capacidad del soporte
magnético.
El respaldo incremental es el más rápido, pero tiene una cantidad de información
limitada a un período de tiempo. Para recuperar un sistema determinado o el disco
completo, se debe partir del último respaldo parcial o completo y cargar en secuencia
cada uno de los respaldos incrementales. En general, se suele hacer un respaldo
completo una vez por semana y para cada día de la semana se hace el incremental.
En cuanto al respaldo parcial, está limitado a cierto tipo de información. Se suele
hacer respaldos globales con menor frecuencia que los parciales. Por ejemplo, una
vez por semana se puede hacer respaldo parcial por aplicación (combinado con los
incrementales o diferenciales, en forma diaria) y una vez por mes se hace un respaldo
completo del, o los, discos.
Por último, el respaldo simultáneo es el más rápido y tiene la totalidad de la
información actualizada, sin embargo interfiere con el procesamiento de los datos y
los datos se encuentran en el mismo lugar físico que los datos origen.
En general los diferentes tipos de respaldo son usados en forma complementaria,
para definir el tipo o tipos de respaldo a utilizar. Se debe tener en cuenta la criticidad
116
de los datos, capacidad de almacenamiento, tiempo disponible para realizarlos y
tiempo necesario para recuperarlos.
4.1.3 Periodicidad
Para determinar cuándo se realizará el respaldo se debe conocer los tiempos
incurridos en desarrollar la tarea y las ventanas de tiempo disponible para realizar
tareas que no afecte a los procesos habituales de procesamiento de datos.
Los tiempos incurridos en desarrollar la tarea varían dependiendo del soporte
utilizado por ejemplo a mayor velocidad de transferencia menor tiempo incurrido. El
tipo de respaldo utilizado (el full back-up es el que lleva mayor cantidad de tiempo) y
la cantidad de datos a respaldar (a mayor cantidad mayor tiempo de respaldo).
Durante las reuniones mantenidas con el cliente de la Institución, se evidenció que
las ventanas de tiempo disponibles durante la semana son escasas y la importancia de
los datos que se manejan, por lo que usualmente, y como recomendable:

Los respaldos incrementales o diferenciales se realizarán diariamente.

Una vez por semana se realizarán respaldos completos parciales.

Una vez al mes respaldos completos totales.
Van a existir momentos en los cuales será necesario realizar respaldos
extraordinarios, tales como una nueva instalación de una aplicación, migración de
bases de datos e incluso traslado del equipamiento. En estas circunstancias deben
realizarse un respaldo global, para estar totalmente cubierto.
117
CAPÍTULO 5
5.1 CONCLUSIONES

La socialización del sistema es un factor clave para un mejor uso, al conocer
todas las funcionalidades disponibles a las que pueden acceder los usuarios
finales.

Los cambios que surgieron en los requerimientos durante la construcción del
sistema fueron adaptados rápida y exitosamente, esto sucedió gracias a que
XP sugiere realizar un desarrollo incremental de pequeñas partes funcionales,
por lo tanto, cuando se implementa una modificación en una parte funcional
no se produce un impacto grande sobre el resto del sistema.

Como señala la metodología XP, el cliente fue parte trascendental en la
construcción de este proyecto gracias a su conocimiento sobre las reglas del
negocio. Durante las reuniones sostenidas aportó con los requerimientos del
sistema, la decisión en el diseño de las interfaces de usuario, además del
diseño y aceptación de las pruebas de cada una de las pequeñas partes
funcionales entregadas.

El esfuerzo del equipo de desarrollo se encaminó a implementar solamente lo
que el usuario solicitó, esto fue posible gracias a que XP sugiere realizar
pruebas continuas, en las cuales el cliente es el que las diseña y ejecuta, por
lo tanto, controla que el equipo de desarrollo realice solamente lo necesario.

Al ser SICCE-TS una solución Web, el sistema puede ser accedido a través
de diversos dispositivos, como lo son computadores de escritorio, teléfonos
inteligentes, tablets, entre otros, siempre y cuando, estos cuenten con un
navegador Web con las especificaciones mínimas para un óptimo
funcionamiento de la aplicación.
118
5.2 RECOMENDACIONES

Luego de que la construcción de sistema finalizó, entra en vigencia la fase de
mantenimiento, se recomienda utilizar un sistema de control de versiones del
código, con el fin de establecer etapas donde el software en desarrollo es estable
y tener un histórico en el desarrollo en el caso de construir componentes nuevos.

La comunicación dentro del equipo de desarrollo es importante, porque evita
conflictos de codificación, por ello se recomienda que exista un rol encargado de
gestionar las relaciones interpersonales dentro del equipo de desarrollo.

Se recomienda estudiar casos de uso exitosos de la metodología XP, con el
objetivo de recolectar información que sea útil para ordenar las actividades a
realizarse, teniendo en cuenta las características del proyecto y de la Institución.

Se recomienda el uso de herramientas de software libre, para no incurrir en
costos adicionales de licenciamiento.

Una vez que el proyecto esté establecido se recomienda que se considere
implementar funcionalidades adicionales que en el alcance de esta tesis no
fueron consideradas. Se sugiere la las siguientes:

Creación de un módulo el cuál permita vía Web, gestionar la venta de
entradas a los espectáculos a realizarse.

Creación del módulo para enlazar la gestión de reservas con el
departamento de finanzas y el departamento jurídico.
119
GLOSARIO
A
Anotaciones (Java): son marcas que se insertan en el código fuente, el nombre de
cada anotación es precedido del símbolo “@”.
API: interfaz de programación de aplicaciones, es el conjunto de funciones y
procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta
biblioteca para ser utilizado por otro software como una capa de abstracción.
B
Base de datos: es un conjunto de datos pertenecientes a un mismo contexto y
almacenados sistemáticamente para su posterior uso.
BSD: es la licencia de software otorgada principalmente para los sistemas BSD
(Berkeley Software Distribution). Esta licencia tiene menos restricciones en
comparación con otras como la GPL estando muy cercana al dominio público.
Bytecode: es el tipo de instrucciones que la máquina virtual Java ejecuta.
Usualmente es el resultado de utilizar un compilador del lenguaje de programación
Java (como javac), pero puede ser generado desde otros lenguajes.
C
CRUD: abreviatura usada para hacer referencia a operaciones de creación,
actualización, eliminación y lectura de registros en una base de datos, viene del
inglés (Create, Read, Update, Delete).
CSS: hojas de Estilos en Cascada, conjunto de reglas de formato que determinan el aspecto
del contenido de una página Web. La utilización de estilos CSS para aplicar formato a una
página permite separar el contenido de la presentación.
D
DAO: patrón de diseño que encapsula toda la lógica de acceso a datos, tales como
consultas y operaciones CRUD.
120
F
Facade: patrón de diseño que permite encapsular la complejidad del negocio en una
sola capa, que permite modular y simplificar el desarrollo de un sistema de software.
Framework: (marco de trabajo) define, en términos generales, un conjunto
estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática
particular que sirve como referencia, para enfrentar y resolver nuevos problemas de
índole similar.
G
GUI: (interfaz gráfica de usuario) es un programa informático que actúa de interfaz
de usuario, utilizando un conjunto de imágenes y objetos gráficos para representar la
información y acciones disponibles en la interfaz. Su principal uso, consiste en
proporcionar un entorno visual sencillo para permitir la comunicación con el sistema
operativo de una máquina o computador.
H
Hardware: es la parte que puedes ver del computador, es decir todos los
componentes de su estructura física.
HTML: (HyperText Markup Language) hace referencia al lenguaje de marcado para
la elaboración de páginas Web. Es un estándar que sirve de referencia para la
elaboración de páginas Web en sus diferentes versiones, define una estructura básica
y un código (denominado código HTML) para la definición de contenido de una
página web, como texto, imágenes, videos, entre otros.
I
Internet: es un conjunto descentralizado de redes de comunicación interconectadas
que utilizan la familia de protocolos TCP/IP, lo cual garantiza que las redes físicas
heterogéneas que la componen funcionen como una red lógica única, de alcance
mundial.
J
JavaDoc: es una utilidad de Oracle para la generación de documentación de APIs en
formato HTML a partir de código fuente Java. Javadoc es el estándar de la industria
121
para documentar clases de Java. La mayoría de los IDEs los generan
automáticamente.
JSP: (JavaServer Pages) es una tecnología que ayuda a los desarrolladores de
software a crear páginas Web dinámicas basadas en HTML, XML, entre otros tipos
de documentos. JSP es similar a PHP, pero usa el lenguaje de programación Java.
JSTL: (JavaServer Pages Standard Tag Library) es un componente de la plataforma
de desarrollo de aplicaciones Web Java EE. Extiende de la especificación JSP
mediante la adición de una biblioteca de etiquetas JSP para tareas comunes , tales
como el procesamiento de XML de datos , ejecución condicional, el acceso de base
de datos , los bucles y la internacionalización.
M
Microprocesador: es el circuito integrado central y más complejo de un sistema
informático; a modo de ilustración, se le suele llamar por analogía el «cerebro» de un
computador.
MVC: es un patrón de arquitectura de software que separa los datos y la lógica de
negocio de una aplicación de la interfaz de usuario y el módulo encargado de
gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción
de tres componentes distintos que son el modelo, la vista y el controlador, es decir,
por un lado define componentes para la representación de la información, y por otro
lado para la interacción del usuario.
P
POJO: (Plain Old Java Objects) objetos instanciados de una clase java que se
caracteriza por tener atributos, estos son leídos y modificados vía “getters” y
“setters”.
Popup: ventana emergente, a menudo se usa para mensajes de confirmación con el
usuario.
S
SGBD: (sistema de gestión de bases de datos) es un conjunto de programas que
permiten el almacenamiento, modificación y extracción de la información en una
122
base de datos, además de proporcionar herramientas para añadir, borrar, modificar y
analizar los datos.
SICCE-TS: Sistema Integral Casa de la Cultura Ecuatoriana – Teatros y Salas.
Sistema operativo: es un programa o conjunto de programas de un sistema
informático que gestiona los recursos de hardware y provee servicios a los programas
de aplicación, ejecutándose en modo privilegiado respecto de los restantes.
Singleton: el patrón de diseño singleton (instancia única) está diseñado para
restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un
único objeto. Su intención consiste en garantizar que una clase sólo tenga una
instancia y proporcionar un punto de acceso global a ella.
Skin: se utilizan con el framework RichFaces para cambiar la apariencia de una
solicitud mediante el establecimiento de los colores, decoración de los controles y
componentes. Por lo general la aparición de aplicaciones web se maneja a través de
CSS (Cascading Style Sheet). Skin consisten en un pequeño conjunto, generalizado
de los parámetros de fuente y color que se puede aplicar a varios estilos diferentes.
Software libre: es la denominación del software que respeta la libertad de todos los
usuarios que adquirieron el producto y, por tanto, una vez obtenido el mismo, puede
ser usado, copiado, estudiado, modificado, y redistribuido libremente de varias
formas.
SOA: (Service Oriented Architecture) es un paradigma de arquitectura para diseñar y
desarrollar sistemas distribuidos. Las soluciones
SOA
han sido creadas para
satisfacer los objetivos de negocio las cuales incluyen facilidad y flexibilidad de
integración con sistemas legados, alineación directa a los procesos de negocio
reduciendo costos de implementación, innovación de servicios a clientes y una
adaptación ágil ante cambios incluyendo reacción temprana ante la competitividad.
Stakeholder: se refiere a quienes pueden afectar o son afectados por las actividades
de una empresa
Sun Microsystems: fue una empresa informática que se dedicaba a vender
estaciones de trabajo, servidores, componentes informáticos, software y servicios
informáticos.
123
T
Tecnología: es el conjunto de conocimientos técnicos, científicamente ordenados,
que permiten diseñar y crear bienes y servicios que facilitan la adaptación al medio
ambiente y satisfacer tanto las necesidades esenciales como los deseos de la
humanidad.
Theme: proporciona varios temas por defecto y también permite crear diferentes
temas para mejorar la interfaz de usuario en cuento a visión se refiere.
Tableta: es una computadora portátil de mayor tamaño que un teléfono inteligente o
un PDA, integrada en una pantalla táctil (sencilla o multitáctil) con la que se
interactúa primariamente con los dedos, sin necesidad de teclado físico ni ratón.
U
UML: (Lenguaje Unificado de Modelado) es un lenguaje gráfico para visualizar,
especificar, construir y documentar un sistema. UML ofrece un estándar para
describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales
como procesos de negocio, funciones del sistema, y aspectos concretos como
expresiones de lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.
W
Web: es una colección de páginas de internet relacionadas y comunes a un dominio
de Internet o subdominio en la World Wide Web.
124
BIBLIOGRAFÍA
1. LAUDON, Kenneth C. y LAUDON, Jane P. Sistemas de Información
Gerencial décima edición. Pearson Educación, México, 2008.
2. KEITH, Mike and SCHINCARIOL Merrick. 2ds Edición. USA. Apress,
2009, 538 páginas.
3. BIEN, Adam: Real world Java EE night hacks. 1ra edición. USA. Apress,
2011, 167 páginas.
4. RUBINGER, Andrew Lee and BURKE Bill. Enterprise JavaBeans 3.1. 6ta
Edición. USA. O’really 2010, 764 páginas.
5. LEONARD, Anghel JSF 2.0 Cookbook, 1ra Edición. USA. Packt Publishing
2010, 396 páginas.
6. Showcase de Richfaces 4.0. Recuperado el 27 de Noviembre, 2014, de
<http://showcase.richfaces.org/>
7. Configure JAAS for JBOSS 7.1. Recuperado el 12 de Diciembre, 2014, de
<http://www.thejavageek.com/2013/09/18/configure-jaas-jboss-7-1-mysql/>.
8. Free Software Foundation. La Definición de Software Libre. Recuperado el
03 de Marzo, 2015, de <http://www.gnu.org/philosophy/free-sw.es.html>.
9. Respaldos de información. Recuperado el 01 de Abril, 2015, de
<http://www.iingen.unam.mx/esmx/Publicaciones/GacetaElectronica/GacetaMayo2014/Paginas/Respaldosdei
Respaldosd.aspx>
125
10. Buenas Prácticas en el uso de RichFaces. Recuperado el 10 de Diciembre,
2014, de <http://www.juntadeandalucia.es/servicios/madeja/contenido/libropautas/29#Roles_de_seguridad>
11. Página Web de la Casa de la Cultura Ecuatoriana “Benjamín Carrión”.
Recuperado
el
21
de
Noviembre,
2014,
de
<http://www.casadelacultura.gob.ec/>
12. Extreme Programming.
Recuperado el
30
de Octubre, 2014,
<http://extremeprogramming.host56.com/ARTICULO9.php>
126
de
ANEXO A
MANUAL DE INSTALACIÓN
INTRODUCCIÓN
________________________________________________________________
La elaboración de este manual tiene como objetivo proporcionar los pasos necesarios a
seguir para completar la instalación del sistema dentro de un ambiente Windows.
Empezando con la instalación de todas las herramientas necesarias para el levantamiento
de la aplicación hasta la instalación del sistema.
REQUISITOS
________________________________________________________________
Para empezar el proceso de instalación es necesario un ordenador con el mínimo de las
siguientes características:

2 GB de Memoria RAM

10 GB de espacio en disco duro

Inter Core 2 Duo

Windows XP, Windows 7, Windows 8

Sistema operativo de 64 bits, procesador x64
INSTALACIÓN DEL JDK Y JRE VERSIÓN 6U29
________________________________________________________________
El archivo ejecutable se encuentra en el DVD de instalación en el directorio “Instaladores”.
Se debe ejecutar el instalador como administrador del sistema esto se logra haciendo clic
127
derecho sobre el ejecutable y al igual que en cualquier instalación de un programa en un
entorno Windows, permitir que el programa realice cambios sobre el equipo.
Aparecerá la siguiente pantalla:
128
Una vez que termina la instalación se muestra la siguiente pantalla, clic en Finish.
INSTALACIÓN DE JBOSS-AS-7.1.1.FINAL
________________________________________________________________
La instalación de JBoss es bastante sencilla puesto que no requiere mayor interacción con
el usuario. En el directorio “C:” vamos a crear una carpeta con nombre “Java” y pegaremos
en este lugar el instalador de JBoss provisto, el en DVD de instalación.
Dirigirse al directorio modules\org y creamos la carpeta postgresql\main y colocamos los
archivos siguientes:
129
module.xml: es el archivo que contiene el path de la versión del jdbc para conectarse a la
base de datos.
postgresql-9.0-802.jdbc4: (Java Database Connectivity) es una API que permite la ejecución
de operaciones sobre bases de datos desde el lenguaje de programación Java,
independientemente del sistema operativo donde se ejecute o de la base de datos a la cual
se accede, utilizando el dialecto SQL del modelo de base de datos que se utilice.
Ahora
ingresar
al
directorio
C:\Java\jboss-as-7.1.1.Final\standalone\configuration,
modificar el archivo standalone.xml, de la siguiente manera.
130
y
INSTALACIÓN POSTGRESQL
________________________________________________________________
El archivo ejecutable se encuentra en el DVD de instalación en el directorio “Instaladores”.
Se debe ejecutar el instalador como administrador del sistema esto se logra haciendo clic
derecho sobre el ejecutable:
Se muestra la siguiente pantalla:
El siguiente paso es seleccionar la carpeta de instalación de PostgreSQL.
131
También se indica la carpeta donde se guardarán los datos por defecto de PostgreSQL:
Ingresar la contraseña para el superusuario "postgres" que será con el que iniciemos sesión
para administrar la base de datos:
132
Ingresar el puerto para la conexión con el servidor PostgreSQL, por defecto el 5432:
Seleccionar la configuración regional:
133
Pulsar "Siguiente" para iniciar la instalación definitiva del servidor PostgreSQL en Windows:
Se iniciará el asistente para instalar el motor de base de datos PostgreSQL, que creará las
carpetas necesarias, copiará los ficheros necesarios y creará el servicio Windows para
iniciar de forma automática el motor de base de datos:
134
Una vez que se termina de instalar, el asistente nos dará la posibilidad de ejecutar Stack
Builder, dejamos sin seleccionar y pulsar “Terminar”.
CREACIÓN DE LA BASE DE DATOS PARA SICCE-TS
________________________________________________________________
Clic en el botón “Inicio” de Windows, clic en el siguiente ícono:
135
Se presenta la siguiente pantalla:
Desplegar "Server Groups", "Servers" y clic con el botón derecho del ratón sobre
"PostgreSQL 9.0(x86) (localhost:5432), en el menú emergente seleccionaremos "Connect":
136
Ingresar la contraseña para el super usuario postgres (la contraseña introducida en la
instalación en este caso root):
Si no existe problema alguno, se conectará al servidor PostgreSQL, entonces desde
pgAdmin podremos configurar y administrar el servidor de PostgreSQL. Para la
administración de la PostgreSQL se utilizará el administrador que viene por defecto con el
motor de base de datos.
137
Clic derecho sobre Database  New Database, se presenta la siguiente pantalla, donde se
solicita el nombre de la base (casadelaculturabd), se establecerá como propietario de la
base de datos (postgres) y para este caso se tomara todos los demás parámetros por
defecto.
138
Finalmente clic en OK.
Una vez creada la base de datos se procede a subir el backup de la aplicación el cual se
encuentra en el DVD de instalación directorio “Backup”, para ello se empieza por restaurar
la base de datos.
Clic derecho sobre “casadelaculturabd” y del menú desplegable seleccionar Restore:
139
Buscar el archivo ccebd.backup.
Clic en Open, clic en OK, si la base se ha restaurado con éxito clic en Done y la base estará
lista para ser utilizada.
140
CREACIÓN DE LAS VARIABLES DE ENTORNO
________________________________________________________________
Presionamos el botón de Windows,
Clic derecho en Computer (Equipo), luego Properties (Propiedades)
141
Presionamos en la opción Advanced system settings (Configuración avanzada del
sistema).
Seleccionamos la pestaña Advanced (Opciones avanzadas), y presionamos Enviroment
Variables (Variables de entorno).
En el panel de variables de entorno presionamos Nueva, y creamos la variable
JAVA_HOME con la ruta donde se instaló el JDK y JRE cómo se muestra en la figura
acontinuación,
142
Después se debe buscar la variable path en la parte inferior. Pulsar Editar y agregar al final
la siguiente línea %JAVA_HOME\bin%, tal y como se muestra en la siguiente figura.
PUESTA EN PRODUCCIÓN
________________________________________________________________
Una vez que se ha terminado de realizar todos los pasos anteriormente descritos se puede
ya iniciar el proceso de puesta en producción del sistema, para esto se abre la consola de
Windows, acto seguido escribir la siguiente línea: cd C:\Java\jboss-as-7.1.1.Final \bin,
presionar Enter en el teclado.
Ahora para levantar el servidor, escribir lo siguiente: standalone.bat, presionar Enter en el
teclado. Si el servidor no tuvo ningún problema al levantarse y deployar la aplicación se
tiene el siguiente resultado.
143
144
ANEXO B
MANUAL DE EJECUCIÓN DE CÓDIGO FUENTE
INTRODUCCIÓN
________________________________________________________________
A continuación se detallan los pasos necesarios para cargar el código fuente del proyecto
SICCE-TS, en el entorno de desarrollo Eclipse Indigo, así como la compilación y despliegue
de la aplicación con ayuda de una tarea Ant.
CARGA Y COMPILACIÓN DEL PROYECTO SICCE-TS EN ECLIPSE
________________________________________________________________
Dentro del DVD de instalación en la carpeta “Instaladores”, subcarpeta “eclipse indigo”,
copiar la subcarpeta y su contenido copiarla en cualquier ruta que deseemos, por ejemplo
en este caso dentro de C:/java.
145
Dentro de esta carpeta encontraremos el icono que permite abrir el entorno de desarrollo, a
la cual hacemos doble clic.
Al terminar de abrirse, nos pedirá que seleccionemos el espacio de trabajo que contendrá
todos los proyectos java, para el ejemplo se muestra C: /workspaceTesis.
Dentro del DVD de instalación en la carpeta “CodigoFuente” se encuentra el proyecto Java
llamado SistemaIntegralCCE, al cual se copia y pega en el espacio de trabajo creado
anteriormente.
Concluido estos pasos se observa que en la parte superior izquierda el menú principal en
donde seleccionamos dentro de File  Import.
146
Escogemos proyecto nuevo ubicado dentro del mismo espacio de trabajo.
147
Aparecerá una nueva ventana que nos solicita que busquemos que proyecto Java
deseamos abrir, en nuestro caso es el SistemaIntegralCCE el cual se encuentra en el DVD
de instalación en la carpeta “CodigoFuente”
A continuación se configuran ciertas variables para poder desplegar la aplicación. En la
parte superior en el menú principal seleccionamos Window  Preferences la cual abrirá una
nueva ventana, entonces ubicarse en la opción que dice Java  InstalledJREs.
148
Presionar Add (Añadir) y seleccionamos Standard VM.
Buscamos la ruta de instalación de nuestro Kit de desarrollo de Java JDK, en este caso
C:\Program Files\Java\jdk1.6.0_29.
149
Presionar Finish y luego OK en las demás ventanas. A continuación en la parte superior en
el menú principal escojer Window  Preferences la cual abrirá una nueva ventana y
ubicarse en la opción Server  RuntimeEnvironments.
Seleccionar Añadir (Add), seleccionar el servidor de aplicaciones Jboss Comunity la versión
Jboss 7.1 Runtime y al finalizar direccionaremos a nuestro servidor de aplicaciones Jboss
7.1.1, en el ejemplo ubicado en la siguiente ruta C:\Java\jboss-as-7.1.1.Final.
150
Como observamos debemos seleccionar el entorno de ejecución de java JRE, para este
caso el jdk1.6.0_29.
151
Presionar Finish y con esto se ha finalizado la creación de variables necesarias para evitar
problemas y el aparecimiento de errores en el proyecto SistemaIntegralCCE.
152
En el menú principal seleccionar Window  Show View  Others  seleccionar la vista
Ant, y aceptar. Esto lo que hará es que aparezca en la parte inferior la opción Ant.
Ubicamos dentro del proyecto el archivo build.xml ubicado en la carpeta ant, el cual
arrastraremos hasta la vista de Ant y nos permitirá realizar el despliegue de la aplicación.
Para el despliegue de la aplicación hacer doble clic en la tarea Ant denominada deploy y
listo está desplegada la aplicación en el servidor de aplicaciones Jboss 7.1.1.
Ahora nos dirigimos al servidor de aplicaciones accediendo a la línea de comandos (tecla de
Windows + r), ubicarse en la ruta C:\Java\jboss-as-7.1.1.Final\, e ingresar a la carpeta bin
donde ejecutaremos el comando standalone.bat.
153
Para verificar el correcto funcionamiento ingresamos en cualquier navegador la siguiente
dirección: http://localhost:8080/CCE/inicio.jsf.
154
ANEXO C
MANUAL DE USUARIO
INTRODUCCIÓN
________________________________________________________________
Una vez iniciado el servidor podemos abrir un navegador web e ingresar la URL:
http://localhost:8080/CCE/inicio.jsf
Y tendremos una página como la que se muestra a continuación:
En esta página se puede distinguir tres enlaces.
REGISTRAR/ ACTUALIZAR CLIENTE RESPONSABLE DE LA RESERVACIÓN
________________________________________________________________
155
Registrar Cliente: Este caso se presenta cuando el cliente no se encuentra almacenado en
la base de datos.
Paso1
Ingresar tipo y número de identificación para que el sistema pueda validar si no existe el
cliente, además de validar si el número ingresado es correcto.
Paso2
Ingresar los datos, teniendo en cuenta de no dejar de llenar aquellos que son obligatorios.
Paso3
Presionar GUARDAR, si no existe problema se presenta el siguiente mensaje.
156
Actualizar Cliente: Este caso se presenta cuando el cliente ya se ha registrado con
anterioridad en la base de datos y requiere cambiar la información almacenada.
Paso1
Ingresar tipo y número de identificación para que el sistema pueda validar si el cliente
existe, además de validar si el número ingresado es correcto.
Paso2
Usuario debe actualizar la información, clic en GUARDAR. Si no existe problema alguno al
almacenar los datos se presentará el siguiente mensaje.
157
PROCESO DE RESERVACIÓN DE INSTALACIONES
________________________________________________________________
Paso1
Inicia mostrándole al cliente las principales características e imagen de las instalaciones.
El cliente debe seleccionar la instalación, hacer clic en
Se mostrara la siguiente pantalla:
158
Paso2
Se prosigue a verificar si las fechas requeridas por el cliente se encuentran disponibles, es
decir no tiene cruce con otra reservación, para ello debe ingresar Fecha y Hora Inicio y
Fecha y Hora Fin, hacer clic en VERIFICAR.
Si no existe ninguna reservación que se cruce con las fechas solicitadas, seguirá el proceso.
159
Por el contrario si las fechas ingresadas coinciden con algunas otras que ya están
registradas, no podrá continuar con el proceso. Se muestra una tabla con las fechas las
cuales tienen conflicto, con el fin de informar al cliente que fechas ya están ocupadas para
que pueda seleccionar otras fechas.
Paso3
Si las fechas seleccionadas están disponibles, prosigue atar al cliente quién se hará
responsable de dicha reservación, para ello debe seleccionar el tipo de identificación e
ingresar el número de identificación, clic en BUSCAR. Si el cliente existe almacenado en la
base de datos continuará el proceso.
160
Por el contrario si el cliente aún no se ha registrado en el sistema, el proceso se interrumpe.
Se muestra el siguiente mensaje.
Entonces debe ir a registrarse, en la siguiente pantalla.
Paso4
Si se ha asignado el cliente a la reservación, lo siguiente es ingresar los datos
complementarios de la reservación.
161
Cabe recalcar en el campo Solicitud: * lo pasos a seguir para subir el documento que
contiene la solicitud de préstamo de la instalación que la deberá redactar el cliente. Sólo se
aceptan documentos con formato PDF. Clic en “Elegir”
Seleccionar el archivo a cargar, clic en “Abrir”.
162
Una vez ingresados todos los campos obligatorios hacer clic en GUARDAR.
Si el ingreso es correcto, se recibirá enseguida un correo de notificación de registro.
163
VER CALENDARIO DE ACTIVIDADES
________________________________________________________________
Se presenta una pantalla con un calendario que permitirá una mejor visualización de las
reservaciones que se hayan registrado. Este calendario presenta las reservaciones por mes,
por semana y por día.
164
165
Una vez que se encuentre dentro del sistema, existe un módulo al cual sólo pueden acceder
el personal que labore en la CCE y que se encuentre debidamente registrado.
166
ADMINISTRACIÓN Y COORDINACIÓN
________________________________________________________________
Este módulo está dirigido solo para los empleados de la Casa de la Cultura Ecuatoriana
quienes estén registrados en el sistema.
Es así como para poder ingresar a las páginas de administración y coordinación de
reservaciones se presenta una página de logueo, en la cual se debe ingresar Usuario y
Contraseña y luego hacer clic en INGRESAR.
167
COORDINACIÓN DE RESERVACIONES
________________________________________________________________
Al ingresar a esta página se muestra la siguiente pantalla, la cual consta de una sección de
filtros los cuales nos sirven para hacer más rápida la búsqueda de reservaciones y otra
sección de la cual se listan todas las reservaciones que han sido registradas con
anterioridad.
168
La tabla Lista de reservaciones muestra la información más relevante de las reservaciones,
y al final de cada reservación presenta dos opciones.
1. Eliminar
Esta opción nos permite eliminar el registro de la base de datos, permitiendo así liberar
las fechas seleccionas.
2. Actualizar
Esta opción, presenta una pantalla en la cual se puede realizar los cambios respectivos
para tener una buena coordinación en el préstamo de las instalaciones.
169
Es importante ponerle especial atención a este ícono,
pues al hacer clic sobre él
podremos descargar la solicitud que envió el cliente.
Se realiza los cambios requeridos hacer clic en GUARDAR, si todo esta correcto se
presenta el siguiente mensaje.
Se almacenan los datos en la base de datos y paralelamente se envía un correo electrónico
al cliente para indicarle el estado en que se encuentra la reservación.
170
ADMINISTRACIÓN DE INSTALACIONES
________________________________________________________________
La pantalla para la administración de instalaciones es la siguiente:
171
Esta página consta de dos secciones. Ingresar datos, la cual contiene los campos que
deben ser llenados para almacenar en la base de datos y otra sección, Listar Datos, esta
contiene una tabla la cual presenta los espacios físicos que han sido registrados con
anterioridad.
La tabla Espacio Físico muestra la información más relevante, y al final de cada registro
presenta dos opciones.
1. Eliminar
Esta opción nos permite eliminar el registro de la base de datos.
172
2. Actualizar
Esta opción, presenta en la sección Ingreso Datos, los campos almacenados
posibilitando así un cambio rápido en cualquiera de los campos.
Se realiza los cambios requeridos hacer clic en GUARDAR, si todo esta correcto se
presenta el siguiente mensaje.
ADMINISTRACIÓN DE ESTADOS PARA LAS RESERVACIONES
________________________________________________________________
La pantalla para la administración de estados es la siguiente:
173
Esta página consta de dos secciones. Ingresar datos, la cual contiene los campos que
deben ser llenados para almacenar en la base de datos y otra sección, Listar Datos, esta
contiene una tabla la cual presenta los estados que han sido registrados con anterioridad.
La tabla Estado muestra la información más relevante, y al final de cada registro presenta
dos opciones.
1. Eliminar
Esta opción nos permite eliminar el registro de la base de datos.
2. Actualizar
Esta opción, presenta en la sección Ingreso Datos, los campos almacenados
posibilitando así un cambio rápido en cualquiera de los campos.
174
Se realiza los cambios requeridos hacer clic en GUARDAR, si todo esta correcto se
presenta el siguiente mensaje.
ADMINISTRACIÓN DE REPORTES
________________________________________________________________
Para obtener el reporte de la frecuencia de uso de las instalaciones, hay que dirigirse al
menú.
175
Se presenta la siguiente pantalla, en la cual tenemos una sesión de criterios con los que se
busca los datos requeridos. Ingresar los criterios, clic en BUSCAR.
Para exportar los datos de la tabla a PDF, hacer clic en 1. Se muestra la siguiente ventana,
aquí se distingue dos opciones una para abrir y la otra para guardar el documento.
Clic en Aceptar, se abre el documento de la siguiente manera.
176
177

Arion 1012YR Digital

NO TENGO SEÑAL

Java Server Faces Inicio: 28 de Marzo Horario

CATALOGO FORMATIVO_MDD_SEPE_Ene

Requisitos para la firma electrónica en este Ministerio

INGRESO AL PORTAL DOCUMENTOSWEB.COM 1. INGRESO A

PROCESO: - esfot-epn

March 28 - Class Size Matters

Instrucciones - Credicentro-Coop

Por favor haga click para leer el manual aquí