universidad central del ecuador facultad de …de museo de la casa de la cultura ecuatoriana (cce),...
TRANSCRIPT
UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA CIENCIAS FÍSICAS Y MATEMÁTICA
CARRERA DE INGENIERÍA INFORMÁTICA
DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GESTIÓN DEL
DEPARTAMENTO DE RESTAURACIÓN Y CONSERVACIÓN DEL ÁREA
MUSEO DE LA CASA DE LA CULTURA ECUATORIANA (CCE).
TRABAJO DE GRADUACIÓN PREVIO LA OBTENCIÓN DEL TITULO DE
INGENIERO INFORMÁTICO
AUTOR: WILMER IVÁN LÓPEZ CARRERA
TUTOR: ING. RENE ALFONSO CARRILLO FLORES
QUITO -14 DE JULIO
2016
ii
DEDICATORIA
Primero a Dios por los la familia que me regalo y por la bendiciones recibidas a lo
largo de mi vida.
A mis padres, quienes con su confianza y amor han sido mi guía y mi soporte en
los momentos buenos y malos.
A mis hermanos parte importante de este logro personal, por su ayuda sobretodo
moral, insertando en mi fuerza para seguir con mis estudios.
A la Universidad Central del Ecuador, quien con sus excelentes docentes fueron
guía en esta etapa de mi vida.
Wilmer Iván López Carrera
iii
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL
Yo, WILMER IVÁN LÓPEZ CARRERA en calidad de autor del trabajo de Titulación
modalidad Proyecto Integrador: DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA
PARA LA GESTIÓN DEL DEPARTAMENTO DE RESTAURACIÓN Y
CONSERVACIÓN DEL ÁREA DE MUSEO DE LA CASA DE LA CULTURA
ECUATORIANA (CCE), autorizo a la Universidad Central del Ecuador hacer uso
de todos los contenidos que me/nos pertenecen o parte de los que contiene esta
obra, con fines estrictamente académicos o de investigación.
Los derechos que como autores me/nos corresponden, con excepción de la
presente autorización, seguirán vigentes a mi/nuestro 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.
Asimismo, autorizo a la Universidad Central del Ecuador para que realice la
digitalización y publicación de este trabajo de investigación en el repositorio
virtual, de conformidad a lo dispuesto en el Art. 144 de la Ley Orgánica de
Educación Superior.
En la ciudad de Quito a los 14 día del mes Julio de 2016.
Wilmer Iván López Carrera
C.I: 1714406962
Telf. : 0984030680
iv
CERTIFICACIÓN DEL TUTOR
Yo, RENE ALFONSO CARRILLO FLORES en calidad de tutor del trabajo de
titulación DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GESTIÓN
DEL DEPARTAMENTO DE RESTAURACIÓN Y CONSERVACIÓN DEL ÁREA
DE MUSEO DE LA CASA DE LA CULTURA ECUATORIANA (CCE), elaborado
por el estudiante WILMER IVÁN LÓPEZ CARRERA de la Carrera de Ingeniería
Informática, Facultad de Ingeniería Ciencias Físicas y Matemática de la
Universidad Central del Ecuador, considero que el mismo reúne los requisitos y
méritos necesarios en el campo metodológico y en el campo epistemológico, para
ser sometido a la evaluación por parte del jurado examinador que se designe, por
lo que lo APRUEBO, a fin de que en trabajo integrador sea habilitado para
continuar con el proceso de titulación determinado por la Universidad Central del
Ecuador.
En la ciudad de Quito, a los 14 días del mes de Julio de 2016.
ING. RENE ALFONSO CARRILLO FLORES
C.C. 1709140378
v
RESUTADO DE TRABAJO DE GRADUACIÓN
vi
CALIFICACIÓN
vii
CONTENIDO
Pág.
DEDICATORIA .................................................................................................... ii
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL ............................................. iii
CERTIFICACIÓN DEL TUTOR ........................................................................... iv
RESUTADO DE TRABAJO DE GRADUACIÓN ................................................... v
CALIFICACIÓN .................................................................................................. vi
CONTENIDO ...................................................................................................... vii
LISTA FIGURAS .................................................................................................. x
LISTA DE DIAGRAMAS ..................................................................................... xii
RESUMEN ......................................................................................................... xiii
ABSTRACT ....................................................................................................... xiv
INTRODUCCIÓN ................................................................................................. 1
1. DEFINICIÓN DEL PROBLEMA ................................................................. 3
1.1. Antecedentes del problema ................................................................ 3
1.2. Planteamiento del problema ............................................................... 3
1.3. Formulación del problema .................................................................. 4
1.4. Preguntas directrices ......................................................................... 4
1.5. Objetivo de la investigación ................................................................ 5
1.5.1. Objetivo General ......................................................................... 5
1.5.2. Objetivos Específicos .................................................................. 5
1.6. Justificación ....................................................................................... 6
2. MARCO TEÓRICO ................................................................................... 7
2.1. Antecedentes ..................................................................................... 7
2.2. Fundamentación teórica ..................................................................... 7
2.2.1. Sistemas de información ............................................................. 7
2.2.2. Software ...................................................................................... 8
2.2.3. Aplicación web ............................................................................ 9
2.2.4. Arquitectura de una aplicación web ............................................. 9
2.2.5. Independencia de capas ........................................................... 10
2.2.6. Metodología .............................................................................. 12
2.2.7. Lenguaje de Modelado Unificado .............................................. 12
2.2.7.1. UML 2.0 ............................................................................... 13
viii
2.2.8. Lenguaje de programación Java ............................................... 13
2.2.9. Base de Datos .......................................................................... 14
2.2.10. Servidor de aplicaciones ........................................................... 14
2.2.11. Arquitectura del sistema desde el punto de vista lógico ............ 15
2.2.12. Entorno de desarrollo ................................................................ 15
2.2.13. Plataforma ................................................................................ 16
2.2.14. Sistema operativo Centos ......................................................... 16
2.2.15. Java Platform, Enterprise Edition (JEE) .................................... 16
3. METODOLOGIA DE DESARROLLO ...................................................... 18
3.1. Etapas de desarrollo ........................................................................ 18
3.1.1. Identificación de problemas, oportunidades y objetivos ............. 18
3.1.2. Determinación de requerimientos de la información .................. 18
3.1.3. Análisis de necesidades del sistema ......................................... 19
3.1.4. Diseño del sistema recomendado ............................................. 19
3.1.5. Desarrollo del software ............................................................. 19
3.1.6. Prueba y mantenimiento del sistema ........................................ 19
3.1.7. Implementación del sistema ...................................................... 20
3.2. Metodología de desarrollo modelo en cascada ................................ 20
3.2.1. Actividades ............................................................................... 22
3.2.1.1. Ingeniería y Análisis del Sistema .......................................... 22
3.2.1.2. Análisis de los requisitos del software .................................. 22
3.2.1.3. Diseño .................................................................................. 22
3.2.1.4. Codificación .......................................................................... 22
3.2.1.5. Prueba ................................................................................. 23
3.2.1.6. Mantenimiento ...................................................................... 23
3.2.2. Desventajas .............................................................................. 23
3.3. Desarrollo de investigación .............................................................. 24
3.3.1. Análisis de requerimientos ........................................................ 24
3.3.1.1. Requerimientos Específicos ................................................. 26
3.3.2. Diseño del sistema .................................................................... 31
3.3.2.1. Diagramas caso de uso ........................................................ 31
3.3.2.2. Diagramas de secuencia ...................................................... 46
3.3.3. Diseño de Base de datos .......................................................... 57
3.3.3.1. Modelo Entidad – relación .................................................... 59
3.3.3.2. Distribución física de la base de datos .................................... 60
ix
3.3.3.3. Distribución lógica de la base de datos ................................... 61
3.3.4. Codificación .............................................................................. 62
3.3.4.1. Estructura principal de codificación del sistema.................... 62
3.3.4.2. Deployment Descriptor ......................................................... 63
3.3.4.3. Web Resources .................................................................... 63
3.3.4.4. JAX-WS Web Services ......................................................... 63
3.3.4.5. Java Resources.................................................................... 64
DISCUSIÓN ....................................................................................................... 69
CONCLUSIONES .............................................................................................. 70
RECOMENDACIONES ...................................................................................... 71
BIBLIOGRAFÍA .................................................................................................. 72
ANEXOS ........................................................................................................... 73
x
LISTA FIGURAS
Pág.
Figura 1: Arquitectura tradicional de una Aplicación Web .................................. 10
Figura 2: Ejemplo Capa de presentación ........................................................... 10
Figura 3: Capa de negocios ............................................................................... 11
Figura 4: Capa de datos .................................................................................... 12
Figura 5: Estructura del Lenguaje Java .............................................................. 14
Figura 6: Etapas de desarrollo del sistema ........................................................ 20
Figura 7: Modelo en Cascada ............................................................................ 21
Figura 8: Caso de uso inicio de sesión .............................................................. 33
Figura 9: caso de uso Ingresar Bien .................................................................. 36
Figura 10: Caso de uso Diagnóstico .................................................................. 36
Figura 11: Caso de uso proceso de restauración ............................................... 40
Figura 12: Caso de uso modificar información ................................................... 42
Figura 13: IDE eclipse ....................................................................................... 62
Figura 14: Estructura de proyecto JEE .............................................................. 62
Figura 15: Deployment Descriptor ..................................................................... 63
Figura 16: Web Resources ................................................................................ 63
Figura 17: JAX-WS Web Services ..................................................................... 64
Figura 18: Java Resources ................................................................................ 64
Figura 19: Entidades .......................................................................................... 65
Figura 20: Servicios para entidades ................................................................... 65
Figura 21: Excepciones ..................................................................................... 66
Figura 22: Interfaces .......................................................................................... 66
Figura 23: Implementar métodos abstractos ...................................................... 66
Figura 24: Backing Beans .................................................................................. 67
Figura 25: Managed Beans ................................................................................ 67
Figura 26: Paginas ............................................................................................. 68
xi
LISTA DE TABLAS
Pág.
Tabla 1: Actores ................................................................................................ 25
Tabla 2: Gestión de login ................................................................................... 27
Tabla 3: Gestión de Bienes Culturales Internos ................................................. 27
Tabla 5: Gestión de Bienes Culturales activos ................................................... 29
Tabla 6: Gestión diagnóstico ............................................................................. 29
Tabla 7: Gestión procesos ................................................................................. 30
Tabla 8: Gestión administración de Bien Cultural............................................... 30
Tabla 9: Gestión seguimiento de bienes culturales ............................................ 31
Tabla 10: Caso de uso inicio de sesión .............................................................. 34
Tabla 11: Caso de uso recuperar contraseña .................................................... 35
Tabla 12: Caso de uso ingresar bien interno ...................................................... 37
Tabla 13: Casos de uso ingresar bien externo ................................................... 38
Tabla 14: casos de uso diagnóstico ................................................................... 39
Tabla 15: Casos de uso selección de procesos de tratamiento.......................... 41
Tabla 16: Casos de uso registro de tratamiento ................................................. 42
Tabla 17: Casos de uso modificar cliente .......................................................... 43
Tabla 18: Casos de uso modificar bien cultural .................................................. 44
Tabla 19: Casos de uso historial bien cultural .................................................... 45
xii
LISTA DE DIAGRAMAS
Pág.
Diagrama 1: Diagrama de secuencia inicio de sesión ........................................ 47
Diagrama 2: Diagrama de secuencia recuperar contraseña .............................. 48
Diagrama 3: Diagrama de secuencia ingresar Bien Cultural interno ................. 49
Diagrama 4: Diagrama de secuencia ingresar Bien Cultural externo ................ 50
Diagrama 5: Diagrama de secuencia diagnostico Bien Cultural ......................... 51
Diagrama 6: Diagrama de secuencia selección procesos de tratamiento .......... 52
Diagrama 7: Diagrama de secuencia registro de tratamiento ............................. 53
Diagrama 8: Diagrama de secuencia modificar cliente ...................................... 54
Diagrama 9: Diagrama de secuencia modificar información de bien cultural ...... 55
Diagrama 10: Diagrama de secuencia Bienes tratados al día ............................ 56
Diagrama 11: Modelo entidad-relación .............................................................. 59
Diagrama 12: Distribución física de la base de datos ......................................... 60
Diagrama 13: Distribución lógica de la base de datos ........................................ 61
xiii
RESUMEN
DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GESTIÓN DEL
DEPARTAMENTO DE RESTAURACIÓN Y CONSERVACIÓN DEL ÁREA
MUSEO DE LA CASA DE LA CULTURA ECUATORIANA (CCE).
Autor: Wilmer Iván López Carrera
Tutor: Rene Alfonso Carrillo Flores
El departamento de Restauración y Conservación tiene como misión la
conservación de los bienes culturales de la Casa de la Cultura Ecuatoriana.
El Departamento de Restauración y Conservación del Área de Museos de la Casa
de la Cultura Ecuatoriana no dispone de un sistema informático para la gestión de
procesos.
Es por eso que surge la necesidad de desarrollar un sistema informático para la
automatización de procesos con el fin de colocar a la disposición de los usuarios
del Departamento de Restauración y Conservación.
El sistema informático solucionará los problemas de gestión de procesos de
ingreso, análisis, tratamiento, seguimiento y consultas de los bienes culturales que
ingresan al departamento de Restauración y Conservación, además, disponer de
una base de datos central que permita almacenar toda la información y la
disponibilidad de estos cuando el usuario requiera.
PALABRAS CLAVE: APLICACIÓN WEB/ PROGRAMACIÓN JAVA/ SERVIDOR
DE APLICACIONES/ POSTGRESQL/ CASOS DE USO/ JBOSS
xiv
ABSTRACT
DESIGN AND IMPLEMENTATION OF A SYSTEM FOR THE MANAGEMENT OF
THE DEPARTMENT OF CONSERVATION AREA RESTORATION AND
MUSEUM OF THE CASA DE LA CULTURA ECUATORIANA (CCE).
Author: Wilmer Iván López carrera
Tutor: Rene Alfonso Carrillo Flores
The Restoration and Conservation Department's mission is the conservation of
cultural property of the Casa de la Cultura Ecuatoriana.
The Department of Restoration and Conservation Area Museums of the Casa de
la Cultura Ecuatoriana not have a computer system for managing processes.
That's why arises the need to develop a computer system for process automation
in order to place at the disposal of users of Restoration and Conservation
Department.
The computer system will solve the problems of process management income,
analysis, treatment, monitoring and consultation of cultural property entering the
department of Restoration and Conservation, also have a central database that
lets you store all the information and availability of these when the user requires.
KEYWORDS: WEB APPLICATION/ PROGRAMATION JAVA/ APPLICATION
SERVER/ POSTGRESQL/ USE CASE/ JBOO
I certify that I have done and revised the translation of the abstract for work
titulation
----------------------------------
Alejandra Belén Clavijo Cadena
Certifiel Traslator
C.I: 1716927585
Senescyt 1005-14-1302990
1
INTRODUCCIÓN
El 9 de agosto de 1944, el Presidente de la República del Ecuador, doctor José
María Velasco Ibarra, promulgó el Decreto Ejecutivo Nº 707, mediante el cual se
crea la Casa de la Cultura Ecuatoriana; Institución orientada a fortalecer el devenir
histórico de la patria y cuyo fundamental propósito busca "...dirigir la cultura con
espíritu esencialmente nacional, en todos los aspectos posibles a fin de crear y
robustecer el pensamiento científico, económico, jurídico y la sensibilidad artística
de la colectividad ecuatoriana".
La Casa de la Cultura Ecuatoriana (CCE) “Benjamín Carrión” tiene como visión
para el 2016 ser referente cultural a nivel nacional e internacional, en la afirmación
y fortalecimiento de la identidad nacional, identidades diversas, plurinacionalidad
e interculturalidad, desde los derechos culturales alineados al Sumak Kawsay.
Además Casa De la Cultura Ecuatoriana (CCE) “Benjamín Carrión” para el 2016
tiene los siguientes objetivos.
Objetivos Operativos:
Incrementar la ejecución de eventos públicos culturales-artísticos de
calidad.
Incrementar el posicionamiento de la Casa de la Cultura Ecuatoriana
(CCE).
Objetivos Estratégicos:
Incrementar el fortalecimiento, la consolidación y afirmación de la
identidad nacional, identidades diversas, plurinacionalidad e
interculturalidad.
Entre las distintas áreas en que se divide la Casa de la Cultura Ecuatoriana se
encuentra el área de Museos, en esta se encuentra el departamento de
Restauración y Conservación, esta es la encargada de la protección y
conservación de los bienes patrimoniales que tienen a su cargo.
2
El cumplimiento de los objetivos de la Casa de la Cultura Ecuatoriana (CCE) va
de la mano con la implementación de nuevas tecnologías informáticas, estas
ayudaran a mejorar las diferentes entidades que hacen uso de estas tecnologías,
aumentando así su productividad y tiempo de respuesta a las nuevas necesidades
que se pueden presentar en un determinado momento.
Actualmente el departamento de Restauración y Conservación de la Casa de la
Cultura Ecuatoriana (CCE) carece de la tecnología adecuada para el manejo
correcto de la información y de los distintos procesos que se realizan en el
departamento.
3
1. DEFINICIÓN DEL PROBLEMA
1.1. Antecedentes del problema
La Casa de la Cultura Ecuatoriana (CCE) se encuentra en un proceso de
automatización de los procesos que manejan las distintas áreas de las que se
encuentra conformada esta institución.
El departamento de Restauración y Conservación tiene como misión proteger y
conservar los bienes culturales de la Casa de la Cultura Ecuatoriana a través de
desarrollar planes de conservación preventiva, así como concienciar y sensibilizar
sobre la importancia de nuestro legado artístico y cultural para garantizar su
transmisión a las generaciones futuras. .
El departamento de Restauración y Conservación del área de museos es una de
las áreas que no ha sido intervenida, motivo por el que el manejo de la información
de este departamento y los distintos procesos realizados en el departamento son
manejado por herramientas informáticas obsoletas o poco óptimas para el manejo
eficiente de la información, esto ha dado origen al interés de crear una herramienta
informática que optimice los distintos procesos del departamento de restauración
y el manejo eficiente de la información.
1.2. Planteamiento del problema
El manejo de la información y de la gestión de procesos es una pieza clave para
que una organización sea eficiente y productiva
El museo de la Casa de la Cultura Ecuatoriana (CCE) consta del departamento de
restauración y conservación, quien es responsable de preservar el patrimonio
museográfico de la Casa de la Cultura Ecuatoriana (CCE), este carece de una
herramienta adecuada para el manejo de los procesos, actualmente utilizan el
editor de texto de Microsoft WORD para plasmar los distintos eventos como
ingresos y salidas de los bienes culturales al departamento y para ingresar
4
observaciones inherentes a los trabajos y técnicas utilizadas para la restauración
o conservación de los bienes culturales para luego imprimirlos y guardarlos en un
archivador, esto ha dado origen a las siguientes consecuencias.
Falta de competitividad del departamento.
Aumento en los tiempos de respuesta de los distintos procesos que
opera el departamento.
Acceso a la información de una forma ineficiente y poco veraz o
desactualizada.
1.3. Formulación del problema
¿Cómo se puede mejorar el manejo de la información y la gestión de procesos
que ejecuta el departamento de Restauración y Conservación del Área de Museos
de la Casa de la Cultura Ecuatoriana?
1.4. Preguntas directrices
¿De qué manera se puede organizar adecuadamente la información
de los bienes culturales ingresados en el departamento?
¿Cómo realizar el seguimiento a los bienes culturales ingresados en el
departamento?
¿Cómo manejar eficientemente la información que posee el
departamento?
¿Cómo manejar la información histórica de los bienes ingresados en el
departamento?
¿Qué herramientas de desarrollo de tecnologías informáticas son
idóneas para la elaboración del sistema informático?
¿Cuáles son las características del entorno en el que se implementará
el sistema informático?
5
1.5. Objetivo de la investigación
1.5.1. Objetivo General
Obtener un sistema informático para la administración de los procesos que maneja
el departamento de Restauración y Conservación del Área Museos de la Casa de
la Cultura Ecuatoriana.
1.5.2. Objetivos Específicos
Identificar los procesos que requieren ser automatizados para el
manejo de la información del departamento de Restauración y
Conservación del Área Museos de la Casa de la Cultura Ecuatoriana.
Describir los procesos identificados.
Desarrollar un sistema informático para automatizar los procesos
identificados.
Implementar el sistema informático desarrollado en el servidor de
aplicaciones del departamento de tecnología de la Casa de la Cultura
Ecuatoriana.
Realizar un análisis del funcionamiento y las necesidades del sistema
actual, para mejorar el manejo de la información y los procesos del
departamento de Restauración y conservación.
Diseñar un sistema que cumpla con las necesidades del personal del
departamento con una interfaz de fácil comprensión, aprendizaje y uso.
Gestionar el proceso de ingreso y salida de las obras de arte
pertenecientes a las distintas colecciones que posee la CCE al
departamento de Restauración y conservación del área de Museos de
la Casa de la Cultura Ecuatoriana (CCE).
Registrar los tratamientos de Restauración y Conservación de las
obras de arte pertenecientes a las distintas colecciones que posee la
CCE.
Mejorar la gestión de los bienes culturales del Museo que se
encuentran en el departamento de Restauración y Conservación con
la digitalización de los distintos reportes que se realizan en el
6
departamento, así como con la documentación administrativa y la
documentación fotográfica.
Capacitar a los usuarios para el uso correcto del sistema.
1.6. Justificación
Una empresa pública como la Casa de la Cultura Ecuatoriana, en este caso el
departamento de Restauración y Conservación del área de Museos necesita de
una herramienta que permita la gestión y conservación de los bienes culturales
que permita manejar los proceso que hoy en día se consideran como la base
operativa de las organizaciones de una forma ágil y eficiente.
Actualmente la mayor parte de los procesos realizados en el departamento de
Restauración y Conservación se realizan manualmente o con herramientas poco
recomendables para una empresa pública como la Casa de La Cultura
Ecuatoriana.
Una vez analizadas las necesidades que presenta el departamento de
Restauración y Conservación del Área de Museos de la Casa de la Cultura
Ecuatoriana, en lo que se refiere al manejo de la información y procesos de los
bienes ingresados en el departamento, se ha visto la necesidad de la creación de
un sistema integro, que permita el manejo óptimo y eficiente de la información
apoyado en las tecnologías actuales que dan respuestas a la demanda de
información a través del uso de tecnología en forma rápida y segura.
Dar cumplimiento al decreto 1014 emitido en el año 2008 por parte de la
presidencia del Ec. Rafael Correa Delgado que promueve el uso de software libre
(Open Sourse) en las instituciones públicas.
7
2. MARCO TEÓRICO
2.1. Antecedentes
Se pretende desarrollar un sistema informático utilizando las tecnologías actuales
que pueda ser aplicado como una herramienta útil para la administración de
procesos y manejo de la información eficientemente en el departamento de
Restauración y conservación del Área de Museos de la Casa De la Cultura
Ecuatoriana, de acuerdo a la implementación de las actuales tecnologías cada vez
se vuelve más usual que organizaciones como la Casa de la Cultura Ecuatoriana
utilicen este tipo de plataformas como solución.
En vista de la gran necesidad de responder a las necesidades del departamento
de Restauración y Conservación del Área de Museos de la Casa de la Cultura
Ecuatoriana y luego de las visitas frecuentes para elaborar el levantamiento de
requerimientos, se observaron las falencias en la administración de la información
y las razones de los inconvenientes, Se implementara un Sistema para la
inserción de información de los bienes culturales y dar seguimiento a estos
eficientemente, dejando de lado procesos que actualmente son realizados
manualmente.
Para el desarrollo del sistema resulta indispensable conocer conceptos básicos
relacionados con el desarrollo de sistemas y tecnologías de la información.
En éste capítulo abordaremos los conceptos computacionales tomados en cuenta
durante el proceso de elaboración del sistema informático de este proyecto.
2.2. Fundamentación teórica
2.2.1. Sistemas de información
Un sistema de información es un conjunto de elementos que interactúan entre sí
con el fin de apoyar las actividades de una empresa o negocio.
8
Un sistema de información es el conjunto total de procedimientos, operaciones,
funciones y difusión de datos o información en una organización.
Las tres partes fundamentales de un sistema de procesamiento electrónico de
datos son el sistema de computación, el sistema de numeración y el sistema
Operativo.
Estos elementos son de naturaleza diversa y normalmente incluyen:
El equipo computacional, es decir, el hardware es necesario para que el
sistema de información pueda operar. Lo constituyen las computadoras y el
equipo periférico que puede conectarse a ellas.
El recurso humano que interactúa con el Sistema de Información, el cual
está formado por las personas que utilizan el sistema, alimentándolo con datos
o utilizando los resultados que genere.
Los datos o información fuente que son introducidos en el sistema, son
todas las entradas que necesita él sistema de información para generar como
resultado la información que se desea.
Los programas que son procesados y producen diferentes tipos de
resultados. Los programas son la parte del software del sistema de información
que hará que los datos de entrada introducidos sean procesados
correctamente y generen los resultados que se esperan.
Fuente: http://fccea.unicauca.edu.co/old/siconceptosbasicos.htm
2.2.2. Software
Según, wiki –software, define:
El software es un elemento del sistema que es lógico, en lugar de físico. Por lo
tanto el software tiene unas características considerables distintas a las del
hardware:
El software se desarrolla, no se fabrica en un sentido clásico.
El software no se estropea
9
Aunque la industria tiende a ensamblar componentes, la mayoría del software se
construye a medida
2.2.3. Aplicación web
Según, El Departamento de Lenguajes y Sistemas Informáticos de la Universidad
de Sevilla. (2010), define:
Una aplicación web es una aplicación informática distribuida cuya interfaz de
usuario10 es accesible desde un cliente web, normalmente un navegador11 web.
Las aplicaciones web son cada vez más populares debido a lo práctico del
navegador web como cliente ligero así como a la independencia del sistema
operativo.
Dentro de sus características habituales se puede destacar:
Comunicación mediante HTTP13 sobre TCP/IP14.
Procesamiento en el servidor de aplicaciones.
Acceso permanente a una base de datos.
Arquitectura por capas (generalmente 3 capas).
Distintos tipos de usuarios cada uno con su respectivo rol.
2.2.4. Arquitectura de una aplicación web
Según, El Departamento de Lenguajes y Sistemas Informáticos de la Universidad
de Sevilla. (2010), define:
La arquitectura de una aplicación web define como se organizan los distintos
módulos que la componen. En una aplicación web se suelen distinguir tres niveles:
Interfaz de usuario (capa de presentación), lógica de negocio y capa de datos.
10
Figura 1: Arquitectura tradicional de una Aplicación Web
Fuente: Autor
2.2.5. Independencia de capas
Capa de presentación
Es la capa que ve el usuario, presenta el sistema del departamento de
Restauración y Conservación al usuario, le comunica la información y
captura la información del usuario en un mínimo proceso.
Figura 2: Ejemplo Capa de presentación
Fuente: Propia
Capa de negocio
11
Esta es la capa que recibe la petición del usuario que administra el sistema del
departamento de Restauración y Conservación y envía la respuesta tras el
proceso. Se denomina capa de negocio (e incluso de lógica e negocio), porque
es aquí donde se establecen todas las reglas que deben cumplirse.
Figura 3: Capa de negocios
Fuente: Propia
Capa de datos
Esta capa se encarga de acceder a la base de datos del departamento de
Restauración y Conservación de la Casa de la Cultura Ecuatoriana, se debe usar
la capa de datos para almacenar y recuperar toda la información de
sincronización del sistema.
12
Figura 4: Capa de datos
Fuente: Propia
2.2.6. Metodología
Según el Departamento de Sistemas Informáticos y Computación Universidad
Politécnica de Valencia.
Un proceso de software detallado y completo suele denominarse Metodología. Las
metodologías se basan en una combinación de modelos de proceso genéricos,
los más utilizados son el modelo en cascada, modelo incremental, modelo
evolutivo, modelo en espiral. Además una metodología debe especificar las
actividades involucradas, junto con las guías de adaptación de la metodología al
proyecto, guías para uso de las herramientas de apoyo, entre otros.
2.2.7. Lenguaje de Modelado Unificado
El UML (Unified Modeling Language) tiene sus orígenes en la necesidad que se
había generado en la industria para construir modelos orientados a objetos. Nace
en el año 1994 por iniciativa de Grady Booch y Jim Rumbaugh para combinar dos
famosos métodos: el de Booch y el OMT (Object Modeling Technique). Más tarde
se les unió Ivar Jacobson, creador del método OOSE (Object-Oriented Software
Engineering). En respuesta a una petición de OMG (Object Management Group),
para definir un lenguaje y una notación estándar del lenguaje de construcción de
modelos, en 1997 propusieron el UML como candidato. UML es ante todo un
lenguaje, lenguaje que se centra en representación gráfica de un sistema. Es un
lenguaje visual estándar empleado para la especificación, construcción y
13
documentación de software orientado a objetos, por medio de diversos elementos
y procesos que interactúan de alguna forma con el software.
2.2.7.1. UML 2.0
Ésta versión del lenguaje UML incorpora nuevos símbolos que hacen más fácil el
modelado del comportamiento dinámico del sistema, razón por la cual es usada
en el desarrollo de este proyecto para modelar el diagrama de actividades. Los
Diagramas de Actividades capturan las acciones de una actividad y sus
resultados, es decir muestran el flujo de trabajo desde el punto de inicio hasta el
punto final. Su utilidad en el Modelado de Negocios permite detallar el proceso
involucrado en las actividades del negocio. Pueden ser atribuidas algunas
características como:
a) Enfatizan la secuencia de acciones de una actividad.
b) Modelan el flujo de control y/o el flujo de objetos de una actividad.
2.2.8. Lenguaje de programación Java
Según, Universidad Complutense de Madrid –Java. (2013), define:
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.
Java es un lenguaje orientado a objetos de propósito general. Aunque Java
comenzó a ser reconocido como un lenguaje de programación de Applets que se
ejecutan en el entorno de un navegador web, se puede utilizar para el desarrollo
de cualquier tipo de proyecto.
14
Figura 5: Estructura del Lenguaje Java
Fuente: Propia
2.2.9. Base de Datos
Fuente http://www.postgresql.org.es/sobre_postgresql
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. Es el sistema de
gestión de bases de datos de código abierto más potente e incorpora muchas de
las funciones que contienen las bases de datos comerciales.
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de
multihilos para garantizar la estabilidad del sistema. Si un proceso presenta un
fallo esto no afectará al resto y el sistema seguirá funcionando.
2.2.10. Servidor de aplicaciones
Según, wiki –software, define:
JBoss
Es un servidor de aplicaciones Java Enterprise Edition de código abierto
implementado en Java puro. JBoss implementa todo el paquete de servicios de
JEE.
15
Al estar basado en Java, puede utilizarse en cualquier sistema operativo para el
que esté disponible la máquina virtual de Java.
2.2.11. Arquitectura del sistema desde el punto de vista lógico
El sistema informático para el departamento de Restauración y Conservación
desde el punto de vista lógico se compone:
Capa Cliente
En esta capa a través de un computador el usuario accede al sistema con la ayuda
de un navegador web para ingresar la información del bien ingresado al sistema y
para los distintos procesos que en él se ejecutan.
Servidor de aplicaciones
Herramienta que ayuda a desplegar la aplicación web desarrollada en Java.
Capa Web
Son paginas XHTML que con el uso del Framework JSF y con la librería de
componentes para JSF RichFaces se elaboran las vistas que el usuario observa
en el computador.
MVC (Modelo-Vista-Controlador)
Es un patrón de arquitectura de software que propone la construcción de tres
componentes distintos los cuales son el modelo donde se almacenan los datos, el
controlador donde se encuentra toda la lógica de negocio y la vista donde se
encuentra la interfaz de usuario. Este patrón de arquitectura de software se basa
en la reutilización de código y la distribución de conceptos, características que
buscan facilitar la tarea de desarrollo de aplicaciones y su futuro mantenimiento.
2.2.12. Entorno de desarrollo
16
Eclipse
Es un entorno de desarrollo integrado compuesto por una colección de
herramientas de programación de código abierto multiplataforma para desarrollar
“Aplicaciones de Cliente Enriquecido”, opuesto a las aplicaciones basadas en
navegadores denominadas de “Cliente-liviano".
2.2.13. Plataforma
La Plataforma sobre la cual se implanta el Sistema es:
Hardware
CPU x86_64
Software
2.2.14. Sistema operativo Centos Es un sistema operativo basado en Linux y que se distribuye como software libre,
el cual brinda seguridad y estabilidad al servidor.
2.2.15. Java Platform, Enterprise Edition (JEE)
Es una plataforma de programación para el desarrollo y ejecución de aplicaciones
en el lenguaje de programación Java. Permite la utilización de arquitecturas de N
capas distribuidas y se apoya en componentes de software.
Java Enterprise Edition tiene varias especificaciones para las interfaces de
programación de aplicaciones (APIs), tales como JDBC, RMI, e-mail, JMS, Web
Services, XML, entre otros y define la manera de coordinarlos. Java Enterprise
Edition también posee algunas especificaciones únicas para sus componentes los
cuales son los llamados Enterprise JavaBeans.
17
Mediante la implementación del Sistema Informático para la Gestión del Área de
Museos de la Casa de la Cultura Ecuatoriana los funcionarios reducen los tiempos
de respuesta en los procesos que ejecutan, además, asegura el seguimiento de
las bienes culturales que poseen en bodega y en las salas de exhibición
permanentes y temporales.
18
3. METODOLOGIA DE DESARROLLO
3.1. Etapas de desarrollo
Las distintas etapas para el desarrollo de software muestran ligeras variaciones
según la metodología usada para el desarrollo, pero en su conjunto las etapas son
las mismas. Si se desea desarrollar un sistema esta se realizara a través de etapas
en el que se identifica el sistema a crear, se modelan los componentes del sistema,
analizan las necesidades del sistema, desarrolla el software, realizan pruebas de
funcionamiento y se pone a disposición del usuario el sistema.
3.1.1. Identificación de problemas, oportunidades y objetivos
En esta etapa se debe descubrir lo que la organización intenta realizar,
identificando los problemas, las oportunidades y los objetivos, para entender lo
que se desea conseguir se debe realizar el levantamiento de requerimientos
correctamente, el departamento de Restauración y Conservación del Área de
Museos de la casa de la cultura pretende utilizar la información y manejar sus
procesos eficientemente con un sistema intuitivo y fácil de usar para el usuario.
En esta fase debe existir una estrecha colaboración entre el usuario y el
desarrollador del sistema a través de entrevistas continuas con los usuarios del
departamento de Restauración y Conservación para entender lo que el usuario
desea.
3.1.2. Determinación de requerimientos de la información
Las actividades de esta fase consisten en entrevistas a los usuarios, sintetizar el
conocimiento Obtenido, estimar el alcance del proyecto y documentar los
resultados.
El resultado de esta fase es un informe de viabilidad que incluye una definición del
problema y un resumen de los objetivos.
19
Los implicados en esta fase son los analistas y el usuario.
3.1.3. Análisis de necesidades del sistema
Las necesidades propias del sistema son analizadas en esta fase, es
recomendable el uso de diagramas de flujo para graficar las entradas, los procesos
y as salidas de las funciones del negocio en una forma gráfica estructurada.
3.1.4. Diseño del sistema recomendado
En esta fase se utiliza la información recolectada en faces antecesoras para
elaborar el diseño lógico del sistema a desarrollar, se diseñan procedimientos
puntuales para la recepción de datos que aseguran que los datos que ingresen al
sistema sean correctos.
Dentro de esta fase también se encuentra el diseño de la base de datos que
almacenarán la información que el usuario utilizara para la toma de decisiones ya
que una base de datos bien organizada el cimiento de cualquier sistema de
información.
3.1.5. Desarrollo del software
El programador desempeña un rol importante en esta fase porque diseña, codifica
y elimina los errores sintácticos y semánticos de los programas de cómputo no sin
antes definir las herramientas a ser utilizadas para la programación.
3.1.6. Prueba y mantenimiento del sistema
Todo sistema debe ser probado antes de utilizarlo, se pretende identificar las
posibles fallas del sistema. El costo de encontrar los problemas antes de la
implementación de es menor acostó que resultaría encontrarlas después de la
implementación.
Todos los sistemas deben realizar un mantenimiento continuo para estar seguro
que los equipos estén en perfectas condiciones cuando sean utilizados.
20
3.1.7. Implementación del sistema
Es la última fase del desarrollo de sistemas, se implementa el sistema sobre la
plataforma de producción y se pone en marcha diferentes estrategias para el
entrenamiento de los usuarios.
Figura 6: Etapas de desarrollo del sistema
Fuente: Propia
3.2. Metodología de desarrollo modelo en cascada
Para el desarrollo del sistema para la gestión de procesos y manejo de la
información del departamento de Restauración y Conservación se ha tomado la
decisión de utilizar el modelo de desarrollo en cascada cómo metodología de
desarrollo.
Modelo de Cascada (Bennington 1956, Modificado por Royce en 1970, Pressman
lo presenta como ciclo de vida clásico). La característica principal del modelo de
cascada es que mientras no se termina una fase, no se puede comenzar la
siguiente fase.
Identificación de problemas
oportunidades y objetivos
Determinación de requerimientos
de la información
Análisis de necesidades del
sistema
Diseño del sistema
Desarrollo del software
Pruebas y mantenimiento
del sistema
Implementación del sistema
21
El modelo de cascada también conocido como modelo lineal secuencial sugiere
un enfoque sistemático, secuencial para el desarrollo del software que comienza
en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y
mantenimiento.
El primer paso es conseguir las especificaciones completa, exactas, no ambiguas
de los requisitos del sistema software que debe ser desarrollado. Estas
especificaciones son transformadas en un documento de análisis, supuestamente
alejado de la máquina. Una vez culminada la fase de análisis, empezamos con la
siguiente fase que es el diseño. El siguiente paso es la programación. Una de las
etapas más importantes es la fase de pruebas, esta sirve para asegurar que no se
introducen equivocaciones ni errores e la lógica de programación. Las pruebas
son planificadas desde el principio y se documentan como se vayan realizando.
Antes de la entrega del sistema software, se valida que satisface los requisitos
definidos en el documento inicial.
La metodología modelo en cascada, tiene las siguientes actividades que se
muestran en la siguiente figura.
Figura 7: Modelo en Cascada
Fuente: Propia
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento
22
3.2.1. Actividades
3.2.1.1. Ingeniería y Análisis del Sistema
Debido a que el software es siempre parte de un sistema mayor, el trabajo
comienza estableciendo los requisitos de todos los elementos del sistema y luego
asignando algún subconjunto de estos requisitos al software.
3.2.1.2. Análisis de los requisitos del software
Análisis: Se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada
SRD (Documento de Especificación de Requisitos), que contiene la especificación
completa de lo que debe hacer el sistema sin entrar en detalles internos (debe
comprender el ámbito de la información del software, así como la función, el
rendimiento y las interfaces requeridas).
3.2.1.3. Diseño
El diseño del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz. El proceso de diseño traduce los requisitos en una
representación del software con la calidad requerida antes de que comience la
codificación. Como resultado surge el SDD (Documento de Diseño del Software),
que contiene la descripción de la estructura global del sistema y la especificación
de lo que debe hacer cada una de sus partes, así como la manera en que se
combinan unas con otras.
3.2.1.4. Codificación
Es la fase de programación. Aquí se desarrolla el código fuente, el diseño debe
traducirse en una forma legible para la maquina, haciendo uso de prototipos así
como pruebas y ensayos para corregir errores. El paso de codificación realiza esta
tarea. Si el diseño se realiza de una manera detallada la codificación puede
realizarse mecánicamente.
23
3.2.1.5. Prueba
Una vez que se ha generado el código comienza la prueba del programa. La
prueba se centra en la lógica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren. Se comprueba que funciona correctamente antes de
ser puesto en explotación.
3.2.1.6. Mantenimiento
El software sufrirá cambios después de que se entrega al cliente. Los cambios
ocurrirán cuando se hayan encontrado errores, esto en lugar de que el software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.
3.2.2. Desventajas Los proyectos reales raramente siguen el flujo secuencial que propone el
modelo, siempre hay iteraciones y se crean problemas en la aplicación del
paradigma.
Normalmente, es difícil para el cliente establecer explícitamente al principio
todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades
en acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.
El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto, no estará disponible una versión operativa del programa. Un
error importante no detectado hasta que el programa esté funcionando
puede ser desastroso.
Se tiene un Alto riesgo en sistemas nuevos debido a problemas en las
especificaciones y en el diseño. Bajo riesgo para desarrollos bien
comprendidos utilizando tecnología conocida
Este modelo, que se lleva a cabo de forma descendente, exige que para
pasar a la siguiente fase hay que concluir correctamente la anterior, de
manera que los posibles errores sean fácilmente detectables. Así, la salida
de una fase es la entrada de la siguiente.
24
La Ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos
necesarios a la hora de desarrollar el software.
3.3. Desarrollo de investigación
Se trata de realizar un sistema que permita que permita gestionar los bienes
culturales tanto interno (bienes en custodia de la Casa de la Cultura Ecuatoriana)
como de los bienes externos (bienes culturales de otras organizaciones) que
ingresa al departamento de restauración y Conservación.
3.3.1. Análisis de requerimientos
Para esta etapa se recopilo la información necesaria a través de entrevistas
permanentes con el personal del departamento de Restauración y Conservación,
así como con los representantes del departamento de tecnología de la Casa de la
Cultura Ecuatoriana y a través de la recuperación de información de los bienes
culturales ingresados en herramientas utilizadas actualmente.
Este análisis se realiza para identificar las necesidades de los actores (usuarios)
y su interacción con el sistema que se pretende desarrollar, para dar solución a
los problemas actuales que la organización desea solucionar.
Este análisis es realizado mediante diagramas conocidos como casos de uso
Entre los requerimientos básicos que se definieron con los actores (usuarios del
departamento de Restauración y Conservación que intervendrán en la
administración del sistema) están:
El sistema debe solucionar los inconvenientes actuales en el manejo de la
información de los bienes culturales que ingresan en el departamento.
El sistema contará con tres módulos bien definidos, para los actores que
fueron identificados para el uso del sistema, estos módulos son: Modulo
Administrador, Modulo Analista y Modulo Restaurador.
25
Actor Descripción Responsabilidad
Administrador Persona del
departamento de
Restauración y
Conservación de la Casa
de la Cultura Ecuatoriana
con la facultad asignada
a la administración del
sistema
El administrador tendrá
acceso libre a todas las
funcionalidades como gestión
de usuarios del sistema,
ingreso de datos de los
bienes culturales, registro de
bienes tratados diariamente
entre otras.
Analista Persona del
departamento de
Restauración y
Conservación encargada
del análisis de estado de
los bienes culturales
requiere hacer uso del
sistema para guardar la
información resultante de
sus análisis.
El analista registrará y
actualizará en el sistema los
resultados del análisis de
estado de los bienes
culturales para ser utilizados
en la selección de los
procesos de tratamiento de
los bienes culturales.
Restaurador Persona del
Departamento de
Restauración y
Conservación encargada
del tratamiento que los
bienes culturales
requiere, hará uso del
sistema para guardar
información de los
procesos de tratamiento
realizados en el bien
cultural.
El restaurador registrará y
actualizará en el sistema la
información sobre el
tratamiento realizado en los
bienes culturales.
Tabla 1: Actores
Fuente: Propia
26
El sistema será desarrollado en un entorno web lo que posibilita el ingreso
al sistema desde cualquier computador que se encuentre conectado a una
red de servicio de internet.
Ofrece la posibilidad de dar seguimiento a los bienes culturales
permitiendo saber qué día fue intervenido un bien cultural con la finalidad
de llevar reportes y estadísticas.
3.3.1.1. Requerimientos Específicos
Interfaz de usuario
El sistema tendrá una interfaz de usuario intuitiva y fácil de usar para los usuarios
finales permitiéndole familiarizarse rápidamente con este, de tal manera que no
exista inconveniente alguno con el uso, con una navegabilidad básica, similar a la
de otras aplicaciones de entorno web y con disponibilidad de acceso a opciones
dependiendo de los roles que cumplan los usuarios.
Usuario y contraseña
Con la finalidad de proteger la información de los datos ingresados en el sistema,
para acceder al sistema se llevará a cabo llenando los campos de usuario y
contraseña que identificara al usuario que desea ingresar, previo al registro en la
base de datos como usuario del sistema por parte del Administrador, cada usuario
con los permisos de accesibilidad dependiente de su rol.
A continuación se detallan los requerimientos de cada uno de los módulos
existentes en el sistema para el departamento de Restauración y Conservación
del Área de Museos.
27
Req.01 Gestión de login
Descripción El sistema permitirá el ingreso de los usuarios a las opciones que
cada usuario tiene permiso.
Requisitos 1 El sistema debe permitir el ingreso de las credenciales del
usuario para acceder al sistema.
2 El sistema debe permitir realizar el cambio de contraseña del
usuario como medida de seguridad.
3 El sistema debe permitir el cierre de sesión.
4 El sistema debe realizar el cierre de sesión automático al
detectar la inactividad del usuario en el sistema como medida
de seguridad.
Tabla 2: Gestión de login
Fuente: Propia
Req.02 Gestión de bienes culturales internos ingresados al
departamento de Restauración y Conservación.
Descripción El sistema permitirá registrar la información que se genera al
ingresar un bien cultural en custodia del Área de Museo.
Requisitos 1 El sistema debe permitir buscar los bienes culturales en
custodia del Área de Museos dela casa de la cultura de su
base de datos interna a través del código interno de la Casa
de la Cultura Ecuatoriana para extraer la información
relevante del bien.
2 El sistema debe permitir asignar el tipo de bien al que
pertenece(pintura caballete, escultura, alto relieve entre
otros)
3 El sistema debe permitir ingresar la información de los
elementos relacionados del bien en caso de poseer.
4 El sistema debe permitir el ingreso de datos
complementarios como fecha de ingreso, datos de personas
que entregan y reciben el bien cultural.
5 El sistema debe permitir la creación de un número de
expediente, este permitirá realizar el seguimiento a los
bienes culturales desde su entrada al departamento hasta su
finalización y su posterior salida.
Tabla 3: Gestión de Bienes Culturales Internos
28
Req.03 Gestión de bienes culturales externos ingresados al
departamento de Restauración y Conservación.
Descripción El sistema permitirá registrar la información que se genera al
ingresar un bien cultural de organizaciones, autores y clientes
no relacionados con la institución.
Requisitos 1 El sistema debe permitir registrar la información básica de
los bienes culturales que ingresan al departamento de
Restauración y conservación.
2 El sistema debe permitir asignar el tipo de bien al que
pertenece(pintura caballete, escultura, alto relieve entre
otros)
3 El sistema debe permitir ingresar la información de los
elementos relacionados del bien en caso de poseer.
4 El sistema debe permitir el ingreso de la información
básica de los clientes(nombre, organización a la que
pertenece)
5 El sistema debe permitir la creación de un número de
expediente, este permitirá realizar el seguimiento a los
bienes culturales desde su entrada al departamento hasta
su finalización y su posterior salida.
Tabla 4: Gestión de Bienes Culturales externos
Fuente: Propia
Req.04 Gestión de bienes culturales activos(en proceso de
tratamiento)
Descripción El sistema permitirá dar seguimiento a los bienes culturales
en proceso de tratamiento.
Requisitos 1 El sistema debe permitir identificar los bienes culturales
que se encuentran en proceso activo de tratamiento
mediante los distintos tipos de búsqueda (Expediente,
código CCE, INPC, autor, cliente entre otros).
29
2 El sistema debe permitir seleccionar el bien cultural que
será manipulado
3 El sistema debe mostrar las distintas opciones del bien
cultural con las opciones activas dependientes del tipo
del rol del usuario.
Tabla 5: Gestión de Bienes Culturales activos
Fuente: Propia
Req.05 Gestión de bienes culturales diagnostico preliminar
Descripción El sistema permitirá registrar la información del diagnóstico
preliminar de los bienes culturales.
Requisitos 1 El sistema debe permitir generar los campos propios de
cada tipo de bien cultural para ingresar los resultados
de los distintos análisis de diagnóstico realizados en
ese bien.
2 El sistema debe permitir registrar y modificar la
información de los campos de diagnóstico del bien.
3 El sistema debe mostrar campos adicionales para
ingresar información de los elementos relacionados del
bien, en caso de poseerlo.
4 El sistema debe permitir registrar y modificar la
información de los campos de diagnóstico de los
elementos relacionados del bien cultural.
Tabla 6: Gestión diagnóstico
Fuente: Propia
30
Req.06 Procesos de tratamiento
Descripción El sistema permitirá registrar la información de los distintos
procesos de tratamiento realizados en un bien cultural.
Requisitos 1 El sistema debe mostrar una lista de los procesos de
tratamiento de los bienes culturales relacionados con su
tipo.
2 El sistema debe permitir seleccionar los procesos que
el usuario crea necesarios para el proceso de
tratamiento.
3 El sistema debe presentar un formulario con los
procesos seleccionados en cuyos campos el usuario
plasmara el trabajo realizado en los bienes culturales.
4 El sistema debe permitir el ingreso o la modificación de
la información del formulario de procesos
seleccionados.
5 El sistema debe permitir el ingreso de la documentación
fotográfica del bien cultural.
Tabla 7: Gestión procesos
Fuente: Propia
Req.07 Gestión de administración de información preliminar del bien
Descripción El sistema permitirá la manipulación de la información
ingresada previo ingreso del bien cultural al departamento.
Requisitos 1 El sistema debe permitir mostrar un menú con las
distintas opciones de los formularios que se puedan
modificar
2 El sistema debe permitir de ser necesario la
modificación de la información básica de los bienes
culturales.
3 El sistema debe permitir de ser necesario la
modificación de la información de los clientes.
Tabla 8: Gestión administración de Bien Cultural
Fuente: Propia
31
Req.08 Gestión seguimiento de bienes culturales
Descripción El sistema permitirá realizar un seguimiento de los bienes
tratados en el departamento de Restauración y
Conservación.
Requisitos 1 El sistema debe permitir mostrar un menú para
seleccionar los bienes culturales tratados.
2 El sistema debe permitir seleccionar la fecha en que
una obra fue intervenida.
3 El sistema debe permitir mostrar el historial de las obras
intervenidas en un periodo de tiempo requerido.
4 El sistema debe permitir el ingreso de datos
complementarios como fecha de ingreso, datos de
personas que entregan y reciben el bien cultural.
Tabla 9: Gestión seguimiento de bienes culturales
Fuente: Propia
3.3.2. Diseño del sistema
Una vez finalizada la fase de análisis de requerimiento, en base a la información
recolectada y analizada en esta fase empezamos con la siguiente etapa del ciclo
de vida en cascada, el diseño del sistema, par esto utilizaremos técnicas de
diseño.
Una de las herramientas usadas con mayor frecuencia para este tipo de diseño,
son los diagramas de caso de uso.
3.3.2.1. Diagramas caso de uso
Un caso de uso describe una funcionalidad más una interacción entre un actor y
un sistema en forma de secuencia de acciones, la descripción se centra en lo
que debe hacerse, no en la manera de hacerlo, deben evitarse expresiones
imprecisas. Se busca sencillez y claridad y puede utilizarse un lenguaje
estructurado para representar secuencia, repeticiones y situaciones opcionales.
Es un proceso iterativo, se van descubriendo los escenarios desde el punto de
vista del usuario, es decir los actores que son los usuarios que intervienen en la
32
administración del sistema, es conveniente al momento de identificar los actores
distinguir entre los actores principales y actores secundarios. La estructura del
sistema debe decidirse teniendo en cuenta a los actores principales.
Para elaborar los casos de uso, es pertinente hacer las siguientes preguntas:
¿Cuáles son las principales tareas de cada actor?
¿El actor lee, escribe o modifica información del sistema?
¿Informa el actor al sistema de los cambios externos?
¿Desea el actor ser informado de cambios no esperados?
Los casos de uso no pueden ser demasiado pequeños, estos deben entregar
algún valor al actor.
Un caso de uso tiene como instancia los escenarios (situaciones concretas que
debe recorrer total o parcialmente el caso de uso), se debe considerar en lo posible
todos los escenarios de modo que se pueda validar el caso de uso.
Ventajas
Ayudan a asegurar que se desarrolla el sistema correcto cumpliendo con
las necesidades del cliente.
Documentan las respuestas funcionales de los requerimientos de los
usuarios.
Excelente forma de comunicación con los clientes y los usuarios, es una
forma sencilla de representación, de fácil entendimiento para estos.
Ayudan a gestionar la complejidad de los proyectos grandes.
Proporcionan el fundamento de los mensajes.
Ofrecen una buena base para la verificación y validación.
Modo objetivo para el seguimiento del proyecto.
Pueden servir como base para especificar respuestas a aplicaciones de
tiempo real.
33
Casos de uso del sistema
Caso de uso inicio de sesión
Figura 8: Caso de uso inicio de sesión
Fuente: Propis
<<extend>>
<<include>>
<<include>>
<<include>>
Administrador
Analista
Restaurador
Datos de usurio
Inicio sesión
Verificar ususario
sistema
Verificar contraseña
Cargar módulos
34
Caso de uso – Iniciar sesión
CASO DE USO: Inicio de sesión
ACTORES
(Administrador, Analista y Restaurador) – Usuarios del
departamento de Restauración y Conservación del Área de
Museo de la Casa de la Cultura Ecuatoriana encargado de
la administración del sistema.
DESCRIPCIÓN
Los actores ingresan sus credenciales (correo electrónico y
password de los actores), para ingresar al menú del
sistema.
PRECONDICIÓN Ser usuario activo del sistema
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El usuario ingresa a la página de login del
sistema.
2 El usuario ingresa su correo electrónico y
clave.
3 Seleccionamos el botón ingresar.
4
El sistema envía la información ingresada por
los actores a la base de datos para verificar
su autenticidad.
5 (credenciales ingresadas correctas) el
sistema redirige al menú principal del sistema
6
(Credenciales ingresadas incorrectas) el
sistema envía un mensaje de error de
credenciales.
7 Revisar credenciales ingresadas
8 Realizar procedimiento nuevamente
EXCEPCIÓN
En caso de no poder ingresar al sistema será declarado
como usuario no existente y el sistema no permitirá su
ingreso al menú principal del sistema
Tabla 10: Caso de uso inicio de sesión
Fuente: Propia
35
Caso de uso – Recuperar Contraseña
CASO DE USO: Recuperar contraseña
ACTORES
(Administrador, Analista y Restaurador) – Usuarios del
departamento de Restauración y Conservación del Área
de Museo de la Casa de la Cultura Ecuatoriana encargado
de la administración del sistema.
DESCRIPCIÓN El usuario
PRECONDICIÓN Ser usuario activo del sistema
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El usuario ingresa a la página de login del
sistema.
2 Dar click en link ¿olvido su contraseña
3 El sistema redirige a la página recuperar
contraseña.
4 Ingresar cuenta de correo electrónico del
usuario
5 Presionar el botón recuperar.
6 El usuario recibe mensaje de envío de nueva
contraseña a su cuenta de correo electrónico.
EXCEPCIÓN
En el caso de ingresar una cuenta de correo electrónica
no registrada en el sistema enviará un mensaje de error
(El correo electrónico no se encuentra en la base de
datos)
Tabla 11: Caso de uso recuperar contraseña
Fuente: Propia
36
Casos de uso Ingresar bien cultural
Figura 9: caso de uso Ingresar Bien
Fuente: Propia
Caso de uso Diagnostico
Figura 10: Caso de uso Diagnóstico
Fuente: Propia
<<include>>
<<include>><<include>>
<<extend>>
Administrador
Ingresar Bien Interno
Ingresar Bien EXterno
Iniciar sesión Datos de bien
Ingresar cliente
<<include>>
<<include>>
<<include>>
Analista
Diagnostico bien cultural
Iniciar sesión
Ingresar bien bien cultural
seleccionar bien cultural
37
Caso de uso – Ingresar bien interno
CASO DE USO: Ingresar bien interno
ACTORES
Administrador – Usuarios del departamento de
Restauración y Conservación del Área de Museo de la
Casa de la Cultura Ecuatoriana encargado de la
administración del sistema.
DESCRIPCIÓN
Permite ingresar la información del bien cultural que se
encuentra en custodia del Área de Museos de la Casa de
la Cultura Ecuatoriana que ingresa al departamento de
Restauración y Conservación.
PRECONDICIÓN Existencia del bien cultural en custodia del área de
Museos de la casa de la cultura ecuatoriana.
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El administrador ingresa el código CCE del bien
cultural.
2 El sistema entrega la confirmación de la
existencia del bien cultural.
3 El administrador ingresa datos adicionales
4 El administrador selecciona la fecha de ingreso
del bien cultural
5 El administrador presiona el botón guardar
6 El sistema genera expediente de ingreso
7 El sistema envía mensa de confirmación de
ingreso
EXCEPCIÓN
El sistema muestra un mensaje de error cuando el código
CCE del bien a ingresar no ha sido encontrado dentro de
los bienes culturales en custodia del Área de Museos de la
Casa de la Cultura Ecuatoriana.
El sistema muestra un mensaje de error mientras los
campos obligatorios no hayan sido llenados.
Tabla 12: Caso de uso ingresar bien interno
Fuente: Propia
38
Caso de uso –Ingresar bien externo
CASO DE USO: Ingresar bien Externo
ACTORES
Administrador – Usuarios del departamento de
Restauración y Conservación del Área de Museo de la
Casa de la Cultura Ecuatoriana encargado de la
administración del sistema.
DESCRIPCIÓN
El sistema permite ingresar información de bienes
culturales no pertenecientes a la Casa de la Cultura
Ecuatoriana que ingresan al departamento de
Restauración y Conservación.
PRECONDICIÓN Existencia del bien cultural.
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El administrador ingresa en la página de ingreso
de bienes externos.
2
El administrador ingresa los datos del bien
cultural en el formulario de ingreso, en este
formulario se ingresara la información del bien
cultural, del autor y cliente.
3 El administrador selecciona el botón Guardar.
4 El sistema genera el número de expediente del
ingreso del bien, este servirá para futuras.
5 El sistema envía un mensaje de confirmación de
ingreso.
EXCEPCIÓN El sistema muestra un mensaje de error mientras los
campos obligatorios no hayan sido llenados.
Tabla 13: Casos de uso ingresar bien externo
Fuente: Propia
39
Caso de uso –Diagnostico Bien Cultural
CASO DE USO: Diagnostico Bien Cultural
ACTORES
Analista – Usuarios del departamento de
Restauración y Conservación del Área de Museo
de la Casa de la Cultura Ecuatoriana encargado del
análisis de estado de bien previo al proceso de
tratamiento que se ejecutara en el bien cultural.
DESCRIPCIÓN
El sistema permite ingresar información de
resultados de análisis de estado del bien cultural
con el fin de tomar decisiones para el proceso de
restauración.
PRECONDICIÓN Existencia del bien cultural.
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El analista selecciona el bien cultural a ser
analizado.
2
El sistema presenta en menú del bien
cultural seleccionado con las distintas
opciones que el analista tiene permiso de
utilizar.
3 El analista selecciona del menú la opción
Diagnostico de bien cultural.
4 El sistema presenta el formulario de
ingreso de diagnóstico de bien cultural.
5 El analista ingresa los resultados de
análisis del bien cultural en el formulario.
6 El analista selecciona el botón guardar.
7 El sistema envía un mensaje de
confirmación de ingreso de información.
EXCEPCIÓN El sistema muestra un mensaje de error mientras los
campos obligatorios no hayan sido llenados.
Tabla 14: casos de uso diagnóstico
Fuente: Propia
40
Caso de uso – Proceso de restauración
Figura 11: Caso de uso proceso de restauración
Fuente: Propia
Caso de uso – Selección de procesos de tratamiento
CASO DE USO: Selección de procesos de tratamiento
ACTORES
Restaurador – Usuarios del departamento de
Restauración y Conservación del Área de Museo de la
Casa de la Cultura Ecuatoriana encargado del tratamiento
de los bienes culturales.
DESCRIPCIÓN
El sistema permite seleccionar uno a más procesos del
conjunto de procesos guardados en la base de datos, con
el fin de para el tratamiento del bien cultural seleccionado.
PRECONDICIÓN Existencia del bien cultural.
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El restaurador selecciona el bien cultural a ser
analizado.
2
El sistema presenta en menú del bien cultural
seleccionado con las distintas opciones que el
restaurador tiene permiso de utilizar.
<<include>>
<<extend>><<extend>>
Restaurador
Iniciar sesión
Proceso restauración
Seleccionar Procesos
Seleccionar bien cultural
41
3 El restaurador selecciona del menú la opción
Selección de procesos del bien cultural.
4 El sistema presenta el presenta el formulario de
selección de procesos de tratamiento.
5
El restaurador selecciona los procesos de
tratamiento que serán utilizados para la
restauración del bien cultural
6 El restaurador selecciona el botón guardar.
7 El sistema envía un mensaje de confirmación de
ingreso de información.
EXCEPCIÓN El sistema muestra un mensaje de error mientras los
campos obligatorios no hayan sido llenados.
Tabla 15: Casos de uso selección de procesos de tratamiento
Fuente: propia
Caso de uso – Registro de tratamiento
CASO DE USO: Registro de tratamiento
ACTORES
Restaurador – Usuarios del departamento de Restauración
y Conservación del Área de Museo de la Casa de la Cultura
Ecuatoriana encargado del tratamiento de los bienes
culturales.
DESCRIPCIÓN
El sistema permite ingresar información sobre lo realizado
por el restaurador en cada uno de los procesos de
tratamiento seleccionados con antelación.
PRECONDICIÓN Existencia del bien cultural.
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El restaurador selecciona el bien cultural a ser
analizado.
2
El sistema presenta en menú del bien cultural
seleccionado con las distintas opciones que el
restaurador tiene permiso de utilizar.
42
3 El restaurador selecciona del menú la opción
Procesos del bien cultural.
4 El sistema presenta el formulario de procesos
seleccionados
5
El restaurador selecciona los procesos de
tratamiento en el que desea ingresar o modificar
la información.
6 El restaurador selecciona el botón guardar.
7 El sistema envía un mensaje de confirmación de
ingreso de información.
EXCEPCIÓN El sistema muestra un mensaje de error mientras los
campos obligatorios no hayan sido llenados.
Tabla 16: Casos de uso registro de tratamiento
Fuente: Propia
Caso de uso – Modificar información
Figura 12: Caso de uso modificar información
Fuente: Propia
<<include>>
<<include>>
<<extend>>
<<extend>>
Administrador
Iniciar sesiónModificar Bien Cultural
Seleccionar Bien
Modificar Cliente
43
Caso de uso- Modificar cliente
CASO DE USO: Modificar cliente
ACTORES
Administrador – Usuarios del departamento de
Restauración y Conservación del Área de Museo de la
Casa de la Cultura Ecuatoriana encargado de la
administración del sistema.
DESCRIPCIÓN El sistema permite modificar la información del cliente
PRECONDICIÓN Existencia del bien cultural.
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El administrador selecciona el bien cultural del
cliente que se desea modificar la información.
2
El sistema presenta en menú del bien cultural
seleccionado con las distintas opciones que el
administrador tiene permiso de utilizar.
3 El administrador selecciona del menú la
opción Información del cliente.
4
El sistema presenta el formulario de Cliente
con la información ingresada en el proceso
de ingreso de bien externo con los campos
de ingreso de información desactivados.
5
El administrador selecciona el botón modificar
para activar los campos que desea modificar
del formulario de cliente.
6 El administrador ingresa los datos del cliente
que serán modificados.
7 El administrador selecciona el botón guardar.
8 El sistema envía un mensaje de confirmación
de ingreso de información.
EXCEPCIÓN El sistema muestra un mensaje de error mientras los
campos obligatorios no hayan sido llenados.
Tabla 17: Casos de uso modificar cliente
Fuente: Propia
44
Caso de uso – Modificar bien cultural
CASO DE USO: Modificar información de bien cultural
ACTORES
Administrador – Usuarios del departamento de
Restauración y Conservación del Área de Museo de la
Casa de la Cultura Ecuatoriana encargado de la
administración del sistema.
DESCRIPCIÓN
El sistema permite modificar la información del bien
cultural externo ingresado en el departamento de
Restauración y Conservación
PRECONDICIÓN Existencia del bien cultural.
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El administrador selecciona el bien cultural que
requiere modificación de información
2
El sistema presenta en menú del bien cultural
seleccionado con las distintas opciones que el
administrador tiene permiso de utilizar.
3 El administrador selecciona del menú la
opción Información del bien cultural.
4
El sistema presenta el formulario Información
bien con la información ingresada en el
proceso de ingreso de bien externo y los
campos de ingreso de información
desactivados.
5
El administrador selecciona el botón modificar
para activar los campos que desea modificar
del formulario Información del bien cultural.
6 El administrador ingresa los datos del bien
cultural que serán modificados.
7 El administrador selecciona el botón guardar.
8 El sistema envía un mensaje de confirmación
de ingreso de información.
EXCEPCIÓN El sistema muestra un mensaje de error mientras los
campos obligatorios no hayan sido llenados.
Tabla 18: Casos de uso modificar bien cultural
Fuente: Propia
45
Caso de uso – Historial bien cultural
CASO DE USO: Historial bien cultural
ACTORES
Administrador – Usuarios del departamento de
Restauración y Conservación del Área de Museo
de la Casa de la Cultura Ecuatoriana encargado de
la administración del sistema.
DESCRIPCIÓN El sistema permite realizar un historial de los bienes
tratados diariamente.
PRECONDICIÓN Existencia del bien cultural.
FLUJO
NORMAL
DE
EVENTOS
PASO ACCIÓN
1 El administrador selecciona del menú
lateral Bienes en proceso de tratamiento.
2 El sistema presenta la página bienes el
proceso de tratamiento.
3
El administrador tiene la opción buscar un
bien cultural especifico o una lista de todos
en proceso de tratamiento.
4 El sistema presenta el o los bienes
culturales solicitados por el administrador.
5 El administrador selecciona el o los bienes
que fueron intervenidos en ese día.
6 El administrador selecciona el botón
guardar
7
El sistema envía la información con la fecha
a la base de datos del departamento de
Restauración y Conservación del Área de
Museos de la Casa de la Cultura
Ecuatoriana.
8 El sistema envía un mensaje de
confirmación de ingreso de información.
EXCEPCIÓN El sistema muestra un mensaje de error mientras los
campos obligatorios no hayan sido llenados.
Tabla 19: Casos de uso historial bien cultural
Fuente: Propia
46
3.3.2.2. Diagramas de secuencia
Los diagramas de secuencia en UML muestra la forma en que los objetos se
comunican entre sí al transcurrir el tiempo, los diagramas de clases y los de
objetos representan información estática. No obstante, en un sistema funcional,
los objetos interactúan entre sí, y tales interacciones suceden en el tiempo. El
diagrama de secuencia muestra la mecánica de la interacción con base en los
tiempos.
47
DIAGRAMA DE SECUENCIA – INICIO DE SECIÓN
Diagrama 1: Diagrama de secuencia inicio de sesión
Fuente: Propia
Inicio de sesión
Petición de inicio de sesión
Usuario validoConfirmación
Verificacion de credenciales
Ingreso de credenciales
Interfaz de inicio de seción Controlador Base de datos
Usuario registrado
Petición de inicio de sesión
Usuario validoConfirmación
Verificacion de credenciales
Ingreso de credenciales
48
Recuperar contraseña
Diagrama 2: Diagrama de secuencia recuperar contraseña
Fuente: Propia
SequenceDiagram_1
Usuario registrado
Mensaje de confirmacion
Generar mail confirmación
Generar contraseña(Script)
Generar script(ID, e-mail)
devuelve credencial
Formulario
Recuperar contraseña
Usuario registrado
Interfaz de usuario Controlador Base de datos
Usuario registrado
Mensaje de confirmacion
Generar mail confirmación
Generar contraseña(Script)
Generar script(ID, e-mail)
devuelve credencial
Formulario
Recuperar contraseña
49
Diagrama de secuencia – Ingreso Bien Interno
Diagrama 3: Diagrama de secuencia ingresar Bien Cultural interno
Fuente: Propia
Ingresar bien cultural interno
Registro exitosoRegistro exitoso
Registro exitoso
Ingreso de información
Generar expediente ingreso
Confirmación
Verificar ExistenciaIngresar codigo CCE
Seleccionar Ingresar Bien Interno del menu
Usuario Valido
Confirmación
Verificación de credencialesIngreso de credenciales
Petición de inicio de sesión
Administrador
Interfaz de usuario Controlador Base de datos
Registro exitosoRegistro exitoso
Registro exitoso
Ingreso de información
Generar expediente ingreso
Confirmación
Verificar ExistenciaIngresar codigo CCE
Seleccionar Ingresar Bien Interno del menu
Usuario Valido
Confirmación
Verificación de credencialesIngreso de credenciales
Petición de inicio de sesión
50
Diagrama de secuencia – Ingresar Bien Cultural Externo
Diagrama 4: Diagrama de secuencia ingresar Bien Cultural externo
Fuente: Propia
SequenceDiagram_1
Petición de inicio de sesiónIngreso de credenciales
Verificación de credenciales
Confirmación
Usuario Valido
Seleccionar Ingresar Bien externo del menú
Llenar formulario
Almacenamiento de información
Generar expediente ingreso
Registro exitosoRegistro exitoso
Registro exitoso
Administrador
Interfaz de usuario Controlador Base de datos
Petición de inicio de sesiónIngreso de credenciales
Verificación de credenciales
Confirmación
Usuario Valido
Seleccionar Ingresar Bien externo del menú
Llenar formulario
Almacenamiento de información
Generar expediente ingreso
Registro exitosoRegistro exitoso
Registro exitoso
51
Diagrama de secuencia – Diagnostico bien
Diagrama 5: Diagrama de secuencia diagnostico Bien Cultural
Fuente: Propia
Diagnostico Bien
Registro exitosoRegistro exitoso
Almacenar información
Llenar formulario de analisis de diagnostico
Registro exitoso
Devuelve menu del bien
Confirmación de xistencia
Verificar existencia del bien
Seleccionar bien en tratamiento
Seleccionar bien en proceso del menú
Usuario Valido
Confirmación
Verificación de credencialesIngreso de credenciales
Petición de inicio de sesión
Analista
Interfaz de usuario Controlador Base de datos
Registro exitosoRegistro exitoso
Almacenar información
Llenar formulario de analisis de diagnostico
Registro exitoso
Devuelve menu del bien
Confirmación de xistencia
Verificar existencia del bien
Seleccionar bien en tratamiento
Seleccionar bien en proceso del menú
Usuario Valido
Confirmación
Verificación de credencialesIngreso de credenciales
Petición de inicio de sesión
52
Diagrama de secuencia – Selección procesos de tratamiento
Diagrama 6: Diagrama de secuencia selección procesos de tratamiento
Fuente: Propia
Selección proceso tratamiento
Petición de inicio de sesiónIngreso de credenciales
Verificación de credenciales
Confirmación
Usuario Valido
Seleccionar bien en proceso del menú
Seleccionar bien en tratamiento
Verificar existencia del bien
Confirmación de xistencia
Devuelve menú seleccionar procesos
Registro exitoso
Seleccionar procesos de tratamiento de lista
Almacenar información
Registro exitosoRegistro exitoso
Restaurador
Interfaz de usuario Controlador Base de datos
Petición de inicio de sesiónIngreso de credenciales
Verificación de credenciales
Confirmación
Usuario Valido
Seleccionar bien en proceso del menú
Seleccionar bien en tratamiento
Verificar existencia del bien
Confirmación de xistencia
Devuelve menú seleccionar procesos
Registro exitoso
Seleccionar procesos de tratamiento de lista
Almacenar información
Registro exitosoRegistro exitoso
53
Diagrama de secuencia – Registro de tratamiento
Diagrama 7: Diagrama de secuencia registro de tratamiento
Fuente: Propia
SequenceDiagram_1
Registro exitosoRegistro exitoso
Almacenar información
Ingresar información en proceso seleccionado
Registro exitoso
Devuelve menú opciones de bien seleccionado
Confirmación de xistencia
Verificar existencia del bien
Seleccionar bien en tratamiento
Seleccionar bien en proceso del menú
Usuario Valido
Confirmación
Verificación de credencialesIngreso de credenciales
Petición de inicio de sesión
Restaurador
Interfaz de usuario Controlador Base de datos
Registro exitosoRegistro exitoso
Almacenar información
Ingresar información en proceso seleccionado
Registro exitoso
Devuelve menú opciones de bien seleccionado
Confirmación de xistencia
Verificar existencia del bien
Seleccionar bien en tratamiento
Seleccionar bien en proceso del menú
Usuario Valido
Confirmación
Verificación de credencialesIngreso de credenciales
Petición de inicio de sesión
54
Diagrama de secuencia – Modificar Cliente
Diagrama 8: Diagrama de secuencia modificar cliente
Fuente: propia
SequenceDiagram_1
Petición de inicio de sesiónIngreso de credenciales
Verificación de credenciales
Confirmación
Usuario Valido
Seleccionar bien en proceso del menú
Seleccionar bien en tratamiento
Verificar existencia del bien
Confirmación de xistencia
Devuelve menú Cliente de bien seleccionado
Registro exitoso
Ingresar información del cliente
Almacenar información
Registro exitosoRegistro exitoso
Administrador
Interfaz de usuario Controlador Base de datos
Petición de inicio de sesiónIngreso de credenciales
Verificación de credenciales
Confirmación
Usuario Valido
Seleccionar bien en proceso del menú
Seleccionar bien en tratamiento
Verificar existencia del bien
Confirmación de xistencia
Devuelve menú Cliente de bien seleccionado
Registro exitoso
Ingresar información del cliente
Almacenar información
Registro exitosoRegistro exitoso
55
Diagrama de secuencia – Modificar información de bien Cultural
Diagrama 9: Diagrama de secuencia modificar información de bien cultural
Fuente: Propia
SequenceDiagram_1
Registro exitosoRegistro exitoso
Almacenar información
Modificar información del bien cultural
Registro exitoso
Devuelve menú Información de bien seleccionado
Confirmación de xistencia
Verificar existencia del bien
Seleccionar bien en tratamiento
Seleccionar bien en proceso del menú
Usuario Valido
Confirmación
Verificación de credencialesIngreso de credenciales
Petición de inicio de sesión
Administrador
Interfaz de usuario Controlador Base de datos
Registro exitosoRegistro exitoso
Almacenar información
Modificar información del bien cultural
Registro exitoso
Devuelve menú Información de bien seleccionado
Confirmación de xistencia
Verificar existencia del bien
Seleccionar bien en tratamiento
Seleccionar bien en proceso del menú
Usuario Valido
Confirmación
Verificación de credencialesIngreso de credenciales
Petición de inicio de sesión
56
Diagrama de secuencia – Bienes tratados al día
Diagrama 10: Diagrama de secuencia Bienes tratados al día
Fuente: Propia
SequenceDiagram_1
Petición de inicio de sesión
Ingreso de credencialesVerificación de credenciales
Confirmación
Usuario Valido
Seleccionar bien en proceso del menú
Seleccionar Buscar bienes en proceso de tratamiento
Verificar bienes activos
Bienes encontrados
Devuelve lista de bienes activos
Registro exitoso
Seleccionar bienes tratados durante el día
Almacenar información
Registro exitosoRegistro exitoso
Administrador
Interfaz de usuario Controlador Base de datos
Petición de inicio de sesión
Ingreso de credencialesVerificación de credenciales
Confirmación
Usuario Valido
Seleccionar bien en proceso del menú
Seleccionar Buscar bienes en proceso de tratamiento
Verificar bienes activos
Bienes encontrados
Devuelve lista de bienes activos
Registro exitoso
Seleccionar bienes tratados durante el día
Almacenar información
Registro exitosoRegistro exitoso
57
3.3.3. Diseño de Base de datos
La base de datos es una de las columnas vertebrales de un sistema, es aquí donde
se deposita la información. Una base de datos (cuya abreviatura es BD) es una
entidad en la cual se pueden almacenar datos de manera estructurada, con la
menor redundancia posible.
Modelo entidad – relación
El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN. En el
modelo ENTIDAD/RELACIÓN se parte de una situación real a partir de la cual se
definen entidades y relaciones entre dichas entidades:
Entidad.- Objeto del mundo real sobre el que queremos almacenar información
(Ej: un bien cultural). Las entidades están compuestas de atributos que son los
datos que definen el objeto (para la entidad bien cultural serían, código CCE,
código INPC, título, autor, técnica,...). De entre los atributos habrá uno o un
conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le
llama clave de la entidad, (para la entidad persona una clave seria código CCE).
En toda entidad siempre hay al menos una clave que en el peor de los casos
estará formada por todos los atributos de la tabla. Ya que puede haber varias
claves y necesitamos elegir una, lo haremos atendiendo a estas normas:
Que sea única.
Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se
asigna a cada cliente un número de cliente?
Que sea mínima, ya que será muy utilizada por el gestor de base de datos.
Relación.- Asociación entre entidades, sin existencia propia en el mundo real que
estamos modelando, pero necesaria para reflejar las interacciones existentes
entre entidades. Las relaciones pueden ser de tres tipos.
Relaciones 1-1.- Las entidades que intervienen en la relación se asocian una a
una.
Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas (n) de
otra.
58
Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la
relación, puede estar asociada con muchas (n) de la otra y viceversa.
59
3.3.3.1. Modelo Entidad – relación
Diagrama 11: Modelo entidad-relación
Fuente: Propia
Relationship_24
Relationship_25
Relationship_26
Relationship_27
Relationship_33
Relationship_34
Relationship_35
Relationship_37
Relationship_38
Relationship_40
Relationship_41
Relationship_42
Relationship_16
Relationship_17
Relationship_18
Relationship_19
Relationship_20
Relationship_21
EMPLEADO
id_empleado
emp_primer_nombre
emp_segundo_nombre
emp_primer_apellido
emp_segundo_apellido
emp_cedula
emp_email
emp_fono
emp_direccion
emp_contrasena
emp_usuario
<pi> Integer
Variable characters (60)
Variable characters (60)
Variable characters (60)
Variable characters (60)
Variable characters (13)
Variable characters (100)
Variable characters (10)
Variable characters (255)
Variable characters (50)
Variable characters (60)
<M>
Identifier_1 <pi>
CARGO
id_cargo
car_nombre
<pi> Integer
Variable characters (50)
<M>
Identifier_1 <pi>
DEPARTAMENTO
id_departamento
dep_nombre
<pi> Integer
Variable characters (50)
<M>
Identifier_1 <pi>
ROL
id_rol
rol_nombre
<pi> Integer
Variable characters (50)
<M>
Identifier_1 <pi>
ESTADO_EMPLEADO
id_estado_empleado
est_emp_nombre
<pi> Integer
Variable characters (60)
<M>
Identifier_1 <pi>
BIEN_CULTURAL_EXTERNO
id_bien_cultural_externo
codigo_inpc
otros_codigos
tipo_bien
nombre_obra
nombre_autor_obra
epoca_obra
tecnica_manufactura
formato
valuacion
alto
ancho
profundidad
diametro_mayor
diametro_menor
peso
elemento_relacionado
elem_relc_alto
elem_relc_anch
elem_relc_profu
fecha_inicio
fecha_finalizacion
<pi> Integer
Variable characters (100)
Variable characters (100)
Variable characters (256)
Variable characters (250)
Variable characters (256)
Variable characters (256)
Variable characters (100)
Variable characters (256)
Variable characters (256)
Variable characters (100)
Variable characters (100)
Variable characters (100)
Variable characters (100)
Variable characters (100)
Variable characters (100)
Variable characters (256)
Variable characters (256)
Variable characters (256)
Variable characters (256)
Date
Date
<M>
Identifier_1 <pi>
CLIENTE
id_cliente
nombre_cliente
cargo
nombre_empresa
tipo_emprea
<pi> Integer
Variable characters (256)
Variable characters (256)
Variable characters (256)
Variable characters (256)
<M>
Identifier_1 <pi>
BIEN_EXTERNO_CLIENTE
id_bien_externo_cliente <pi> Integer <M>
Identifier_1 <pi>
DOCUMENTACION_FOTOGRAFICA
id_doc_fot
imagen
<pi> Integer
Byte
<M>
Identifier_1 <pi>
TIPO_BIEN
id_tipo_bien
nombre_bien
<pi> Integer
Variable characters (100)
<M>
Identifier_1 <pi>
LISTA_PROCESOS
id_lista_procesos
nombre_proceso
<pi> Integer
Variable characters (256)
<M>
Identifier_1 <pi>
LISTA_PROCESOS_BIEN
id_lista_procesos_bien <pi> Integer <M>
Identifier_1 <pi>
TOMA_MUESTRA
id_toma_muestra
estratigraficos
iden_aglut_emp
iden_pig_comp
iden_nat_fib_tela
<pi> Integer
Text
Text
Text
Text
<M>
Identifier_1 <pi>
TRATAMIENTO_BIEN
id_tratamiento_bien
fecho_tratamiento
<pi> Integer
Date
<M>
Identifier_1 <pi>
PROCESOS
id_procesos
detalle
<pi> Integer
Text
<M>
Identifier_1 <pi>DIAGNOSTICO
id_dia_pin_cab
marco
bastidor
soporte
base_preparacion
capa_pictorica
capa_proteccion
base_peana
suprabases
policromia
tecnica_pictorica_impresion
capa_proteccion_fijacion
estructura_interna
decoracion
otros
<pi> Integer
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
<M>
Identifier_1 <pi>
ESTADO_BIEN
id_estado_bien
estado
<pi> Integer
Variable characters (15)
<M>
Identifier_1 <pi>
EXPEDIENTE
id_expediente
codigo_expediente
fecha
<pi> Integer
Variable characters (30)
Date
<M>
Identifier_1 <pi>
DOCUMENTACION_FOTOG_ETA
id_doc_fot_eta
descripcion
<pi> Integer
Variable characters (256)
<M>
Identifier_1 <pi>
MENUPRINCIPAL
id_menu
etiqueta_opcion_menu
nivel
orden_opcion
url_opcion
menu_id_menu
<pi> Integer
Variable characters (255)
Integer
Integer
Variable characters (255)
Integer
<M>
Identifier_1 <pi>
60
3.3.3.2. Distribución física de la base de datos
Diagrama 12: Distribución física de la base de datos
Fuente: Propia
Relationship_24
FK_EMPLEADO_RELATIONS_CARGO
Relationship_25FK_EMPLEADO_RELATIONS_ESTADO_E
Relationship_26FK_EMPLEADO_RELATIONS_DEPARTAM
Relationship_27FK_EMPLEADO_RELATIONS_ROL
Relationship_33FK_BIEN_EXT_RELATIONS_CLIENTE
Relationship_34FK_BIEN_EXT_RELATIONS_BIEN_CUL
Relationship_35FK_BIEN_CUL_RELATIONS_TIPO_BIE
Relationship_37FK_TRATAMIE_RELATIONS_BIEN_CUL
Relationship_38FK_LISTA_PR_RELATIONS_TOMA_MUE
Relationship_40
FK_LISTA_PR_RELATIONS_DOCUMENT
Relationship_41
FK_LISTA_PR_RELATIONS_PROCESOS
Relationship_42
FK_LISTA_PR_RELATIONS_LISTA_PR
Relationship_16
FK_BIEN_CUL_RELATIONS_ESTADO_B
Relationship_17
FK_EXPEDIEN_RELATIONS_BIEN_CUL
Relationship_18FK_DIAGNOST_RELATIONS_EXPEDIEN
Relationship_19FK_LISTA_PR_RELATIONS_EXPEDIEN
Relationship_20FK_DOCUMENT_RELATIONS_DOCUMENT
Relationship_21FK_LISTA_PR_RELATIONS_TIPO_BIE
EMPLEADO
id_empleado
id_cargo
id_estado_empleado
id_departamento
id_rol
emp_primer_nombre
emp_segundo_nombre
emp_primer_apellido
emp_segundo_apellido
emp_cedula
emp_email
emp_fono
emp_direccion
emp_contrasena
emp_usuario
CARGO
id_cargo
car_nombre
DEPARTAMENTO
id_departamento
dep_nombre
ROL
id_rol
rol_nombre
ESTADO_EMPLEADO
id_estado_empleado
est_emp_nombre
BIEN_CULTURAL_EXTERNO
id_bien_cultural_externo
id_tipo_bien
id_estado_bien
codigo_inpc
otros_codigos
tipo_bien
nombre_obranombre_autor_obra
epoca_obra
tecnica_manufactura
formato
valuacion
alto
ancho
profundidad
diametro_mayor
diametro_menor
peso
elemento_relacionado
elem_relc_alto
elem_relc_anch
elem_relc_profu
fecha_inicio
fecha_finalizacion
CLIENTE
id_cliente
nombre_cliente
cargo
nombre_empresa
tipo_emprea
BIEN_EXTERNO_CLIENTE
id_bien_externo_cliente
id_cliente
id_bien_cultural_externo
DOCUMENTACION_FOTOGRAFICA
id_doc_fot
id_doc_fot_eta
imagen
TIPO_BIEN
id_tipo_bien
nombre_bien
LISTA_PROCESOS
id_lista_procesos
id_tipo_bien
nombre_proceso
LISTA_PROCESOS_BIEN
id_lista_procesos_bien
id_toma_muestra
id_doc_fot
id_procesos
id_lista_procesos
id_expediente
TOMA_MUESTRA
id_toma_muestra
estratigraficos
iden_aglut_emp
iden_pig_comp
iden_nat_fib_tela
TRATAMIENTO_BIEN
id_tratamiento_bien
id_bien_cultural_externo
fecho_tratamiento
PROCESOS
id_procesos
detalleDIAGNOSTICO
id_dia_pin_cab
id_expediente
marco
bastidor
soporte
base_preparacion
capa_pictorica
capa_proteccion
base_peana
suprabases
policromia
tecnica_pictorica_impresion
capa_proteccion_fijacion
estructura_interna
decoracion
otros
ESTADO_BIEN
id_estado_bien
estado
EXPEDIENTE
id_expediente
id_bien_cultural_externo
codigo_expediente
fecha
DOCUMENTACION_FOTOG_ETA
id_doc_fot_eta
descripcion
MENUPRINCIPAL
id_menu
etiqueta_opcion_menu
nivel
orden_opcion
url_opcion
menu_id_menu
61
3.3.3.3. Distribución lógica de la base de datos
Diagrama 13: Distribución lógica de la base de datos
Fuente: Propia
Relationship_24
Relationship_25
Relationship_26
Relationship_27
Relationship_33
Relationship_34
Relationship_35
Relationship_37
Relationship_38
Relationship_40
Relationship_41
Relationship_42
Relationship_16
Relationship_17
Relationship_18
Relationship_19
Relationship_20
Relationship_21
EMPLEADO
#
o
o
o
o
o
o
o
o
o
o
o
o
o
o
id_empleado
id_cargo
id_estado_empleado
id_departamento
id_rol
emp_primer_nombre
emp_segundo_nombre
emp_primer_apellido
emp_segundo_apellido
emp_cedula
emp_email
emp_fono
emp_direccion
emp_contrasena
emp_usuario
Integer
Integer
Integer
Integer
Integer
Variable characters (60)
Variable characters (60)
Variable characters (60)
Variable characters (60)
Variable characters (13)
Variable characters (100)
Variable characters (10)
Variable characters (255)
Variable characters (50)
Variable characters (60)
CARGO
#
o
id_cargo
car_nombre
Integer
Variable characters (50)
DEPARTAMENTO
#
o
id_departamento
dep_nombre
Integer
Variable characters (50)
ROL
#
o
id_rol
rol_nombre
Integer
Variable characters (50)
ESTADO_EMPLEADO
#
o
id_estado_empleado
est_emp_nombre
Integer
Variable characters (60)
BIEN_CULTURAL_EXTERNO
#
o
o
o
o
o
oo
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
id_bien_cultural_externo
id_tipo_bien
id_estado_bien
codigo_inpc
otros_codigos
tipo_bien
nombre_obranombre_autor_obra
epoca_obra
tecnica_manufactura
formato
valuacion
alto
ancho
profundidad
diametro_mayor
diametro_menor
peso
elemento_relacionado
elem_relc_alto
elem_relc_anch
elem_relc_profu
fecha_inicio
fecha_finalizacion
Integer
Integer
Integer
Variable characters (100)
Variable characters (100)
Variable characters (256)
Variable characters (250)Variable characters (256)
Variable characters (256)
Variable characters (100)
Variable characters (256)
Variable characters (256)
Variable characters (100)
Variable characters (100)
Variable characters (100)
Variable characters (100)
Variable characters (100)
Variable characters (100)
Variable characters (256)
Variable characters (256)
Variable characters (256)
Variable characters (256)
Date
Date
CLIENTE
#
o
o
o
o
id_cliente
nombre_cliente
cargo
nombre_empresa
tipo_emprea
Integer
Variable characters (256)
Variable characters (256)
Variable characters (256)
Variable characters (256)
BIEN_EXTERNO_CLIENTE
#
o
o
id_bien_externo_cliente
id_cliente
id_bien_cultural_externo
Integer
Integer
Integer
DOCUMENTACION_FOTOGRAFICA
#
o
o
id_doc_fot
id_doc_fot_eta
imagen
Integer
Integer
Byte
TIPO_BIEN
#
o
id_tipo_bien
nombre_bien
Integer
Variable characters (100)
LISTA_PROCESOS
#
o
o
id_lista_procesos
id_tipo_bien
nombre_proceso
Integer
Integer
Variable characters (256)
LISTA_PROCESOS_BIEN
#
o
o
o
o
o
id_lista_procesos_bien
id_toma_muestra
id_doc_fot
id_procesos
id_lista_procesos
id_expediente
Integer
Integer
Integer
Integer
Integer
Integer
TOMA_MUESTRA
#
o
o
o
o
id_toma_muestra
estratigraficos
iden_aglut_emp
iden_pig_comp
iden_nat_fib_tela
Integer
Text
Text
Text
Text
TRATAMIENTO_BIEN
#
o
o
id_tratamiento_bien
id_bien_cultural_externo
fecho_tratamiento
Integer
Integer
Date
PROCESOS
#
o
id_procesos
detalle
Integer
TextDIAGNOSTICO
#
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
id_dia_pin_cab
id_expediente
marco
bastidor
soporte
base_preparacion
capa_pictorica
capa_proteccion
base_peana
suprabases
policromia
tecnica_pictorica_impresion
capa_proteccion_fijacion
estructura_interna
decoracion
otros
Integer
Integer
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
ESTADO_BIEN
#
o
id_estado_bien
estado
Integer
Variable characters (15)
EXPEDIENTE
#
o
o
o
id_expediente
id_bien_cultural_externo
codigo_expediente
fecha
Integer
Integer
Variable characters (30)
Date
DOCUMENTACION_FOTOG_ETA
#
o
id_doc_fot_eta
descripcion
Integer
Variable characters (256)
MENUPRINCIPAL
#
o
o
o
o
o
id_menu
etiqueta_opcion_menu
nivel
orden_opcion
url_opcion
menu_id_menu
Integer
Variable characters (255)
Integer
Integer
Variable characters (255)
Integer
62
3.3.4. Codificación
La siguiente fase de la metodología modelo en cascada es la codificación, en
esta fase seguiremos el modelo de arquitectura JEE y adoptando el patrón de
arquitectura MVC (Modelo – Vista - Controlador).
La codificación se realiza con el apoyo del IDE de desarrollo Eclipse.
Figura 13: IDE eclipse
Fuente: Propia
3.3.4.1. Estructura principal de codificación del sistema
Figura 14: Estructura de proyecto JEE
Fuente: Propia
63
3.3.4.2. Deployment Descriptor
Es un componente de aplicaciones J2EE que describe cómo se debe desplegar
(o implantar) una aplicación web
Figura 15: Deployment Descriptor
Fuente: Propia
3.3.4.3. Web Resources
Son recursos adicionales que se pueda necesitar para incluir en el proyecto Web
cuando se utilizan tecnologías web más avanzadas en la aplicación.
Figura 16: Web Resources
Fuente: Propia
3.3.4.4. JAX-WS Web Services
Es una API de Java para la creación de servicios web. Es parte de la plataforma
Java EE de Sun Microsystems para simplificar el desarrollo y despliegue de los
clientes y puntos finales de servicios web.
64
Figura 17: JAX-WS Web Services
Fuente: Propia
3.3.4.5. Java Resources
Es un conjunto de paquetes que contiene en su interior las clases e interfaces que
componen las capas de modelo y controlador del sistema.
Figura 18: Java Resources
Fuente Propia
DaoGenerico contiene las consultas básicas que se realizan a la base de datos
65
Entidades, clases en código java que representan las tablas de la base de datos.
Figura 19: Entidades
Fuente Propia
Clase que ofrecen servicios específicos para cada una de las entidades del
sistema.
Figura 20: Servicios para entidades
Fuente Propia
66
Clases que manejan excepciones
Figura 21: Excepciones
Fuente: Propia
Interfaces para declarar métodos abstractos.
Figura 22: Interfaces
Fuente: Propia
Clases para implementar los métodos abstractos declarados en las interfaces.
Figura 23: Implementar métodos abstractos
Fuente Propia
67
Backing Beans, estas clases sirven de soporte para un objeto manejado dentro de
la aplicación a través de un Bean común.
Figura 24: Backing Beans
Fuente: Propia
Managed beans
Figura 25: Managed Beans
Fuente: Propia
68
Pages, contiene las páginas de la aplicación.
Figura 26: Paginas
Fuente: Propia
69
DISCUSIÓN
El desarrollo del sistema ha permitido dar solución a uno de los inconvenientes
de mayor relevancia del departamento de restauración y conservación los
cuales comprenden el manejo de la información y procesos.
Los tiempos de respuesta para la solución de problemas han mejorado
significativamente gracias a la utilización de las tecnologías adecuadas que
van de la mano de las necesidades del cliente.
El sistema fue diseñado específicamente para el departamento de
Restauración y Conservación del área de Museo de la casa de la cultura
Ecuatoriana, esto permite aprovechar su funcionalidad a su máxima
capacidad, ya que fue diseñado bajo los requerimientos propios de la
organización, esto no sucede si se adquiere un sistema de uso general para
la gestión de Conservación y Restauración de bienes culturales, en este
existirán campos que podrían ser innecesarios o en su defecto inexistencia
de campos que para la organización son de gran relevancia.
Limitaciones
La falta de personal capacitado para la administración del sistema.
El miedo de las personas a manipular nuevas tecnologías.
70
CONCLUSIONES
Se han identificado 10 procesos y 2 subprocesos para el manejo eficiente
de la información del departamento de Restauración y Conservación.
Para identificar los procesos un requisito indispensable es entrar en
contacto con las personas que realizan dichos procesos, ya que ellos
describen como llevan a cabo cada actividad y tarea.
Para la descripción de los procesos resulta indispensable la utilización de
herramientas que permita realizar gráficos y especialmente diagramas, se
utilizó el Lenguaje de Modelamiento Unificado esto facilita comprender
que estamos construyendo, determinar la mejor manera de solucionar los
procesos propuestos y beneficiar al usuario en la comprensión del flujo del
sistema.
El sistema para la gestión del departamento de Restauración y
Conservación ha permitido acortar significativamente los tiempos de
respuesta a los distintos procesos propios del área permitiendo al personal
del departamento incrementar su productividad.
La implementación del sistema permite al personal del departamento el
manejo eficiente de la información de los bienes culturales ingresados y
tratados en el departamento gracias a que la información se encuentra en
una base de datos central, dando seguridad y garantías a los usuarios
sobre la información obtenida de esta.
Al ser una aplicación web los usuarios tienen total disponibilidad en cuanto
a hora y lugar, solo necesita una laptop o computador de escritorio con un
navegador compatible y conexión a internet.
71
Tener el respaldo de un sistema informático permite que una organización,
en este caso la Casa de la Cultura Ecuatoriana específicamente el
departamento de Restauración y Conservación aumente su productividad
y su eficiencia en el manejo de la información. Los sistemas informáticos
hoy en día no son una opción, son una necesidad.
La capacitación del personal permite que los usuarios utilicen el sistema
informático correcta y eficientemente.
RECOMENDACIONES
Si se desea agregar más procesos en el sistema, automatizar un proceso
que haga seguimiento de usuarios, para identificar que usuario ha
ingresado al sistema y que cambios ha realizado en la información que
este dispone.
Para la descripción de procesos utilizar UML, es un lenguaje estándar para
establecer la serie de requerimientos y estructura necesaria de un proceso,
además de gráficos que permiten entender al cliente lo que se quiere
hacer.
Realizar el mantenimiento periódico del software y hardware de la
institución como método de seguridad preventiva con la finalidad proteger
el correcto funcionamiento del sistema.
En caso de ingreso de nuevo personal al departamento de Restauración y
Conservación hacer uso del manual de usuario ubicado en el ANEXO A
del documento para el uso correcto del sistema.
72
BIBLIOGRAFÍA
1. POSTGRESQL, https://pgsqltutorial.readthedocs.org/es/latest/
2. JAVA, Deitel, P., & Deitel, H. (2012). Como Programar en Java Novena
Edición. Mexico: Pearson Educación.
3. KENDALL, Kenneth; KENDALL, Julie Análisis y Diseño de Sistemas.
Recuperado desde
http://www.academia.edu/7102592/Analisis_y.Diseno_de_Sistemas_8ed_Ke
ndall_PDF. Recuperado el 11/01/2016.
4. JBOSS, Guía de JBoos. http://www.osmosislatina.com/jboss/basico.html.
Recuperado el 17/01/2016
5. Somerville, I. (2005). Ingeniería de Software. Madrid: Pearson Educación.
6. MODELO DE CASCADA, Modelo de desarrollo
http://www.osmosislatina.com/jboss/basico.html. Recuperado el 02/02/2016.
73
ANEXOS
74
Anexo A
Manual de usuario
Introducción
El sistema diseñado para el departamento de Restauración y Conservación de la
Casa de la Cultura Ecuatoriana tiene una interfaz de usuario intuitiva y fácil de
utilizar, la aplicación se lanza utilizando un navegador web
Usuarios
El sistema fue diseñado para los usuarios que administraran el sistema.
Inicio de sesión
Para ingresar a la página de inicio de sesión el usuario debe ingresar a la url que
el personal del departamento de tecnología asigne al sistema.
Se mostrara la siguiente pantalla
75
En este menú el usuario ingresara su correo electrónico y contraseña para validar
los datos e ingresar al menú principal, previamente el usuario debe ser registrado
en el sistema por el administrador del sistema.
Página de Bienvenida
Validada la información del usuario es sistema presenta la página de bienvenida
con un menú lateral que permitirá navegar en las opciones indispensables del
usuario.
Menú Lateral
Permite navegar por las páginas principales del sistema
76
BIENES
Esta opción se subdivide en dos:
BIENES EN TRATAMIENTO
Permite seleccionar los bienes culturales que se encuentran en proceso de
tratamiento para realizar su gestión.
En la página Bienes en tratamiento el usuario seleccionara el bien cultural del que
desea manipular la información.
Seleccionar opciones de búsqueda (código CCE, código INPC, autor, nombre de
obra, cliente, todos).
77
En la tabla ubicada en la parte inferior de la página se mostrara el bien cultural o
los bienes culturales encontrados dependiendo de la opción de búsqueda
seleccionada.
Seleccionar en bien cultural deseado.
Al seleccionar el bien deseado se mostrará la siguiente página.
Bien seleccionado
Muestra el menú del bien seleccionado con las siguientes opciones
Información del bien
Información del cliente
Diagnóstico de estado de conservación.
Propuesta de conservación y/o conservación
Procesos de restauración y conservación
78
Información del Bien
Permite que el administrador modifique la información básica de bien cultural que
fue guardada en la base de datos el momento del ingreso del bien cultural al
departamento de Restauración y conservación.
79
Información del cliente
Permite que el administrador modifique la información básica del cliente que fue
guardada en la base de datos el momento del ingreso del bien cultural al
departamento de Restauración y conservación.
80
Diagnóstico de estado de conservación
El usuario (analista) en esta página registra los resultados del análisis de
conservación preliminar de los bienes culturales, esta información permitirá
realizar la toma de decisiones sobre los procesos de restauración que serán
aplicados a los bienes.
81
82
Procesos de conservación y/o restauración
Es opción nos presenta la página donde el usuario seleccionara los procesos
adecuados para el tratamiento del bien cultural una vez terminado el diagnostico
de conservación.
Se presentaran los distintos procesos para ser seleccionado dependiendo del tipo
de bien cultural.
Los procesos seleccionados serán almacenados en la tabla situada en la parte
inferior de la página.
En la tabla el usuario confirmara los procesos seleccionados y será guardada en
la base de datos para su posterior utilización.
Propuesta de Restauración y Conservación
Esta opción permite a los usuarios (restauradores) ingresar la información sobre
los tratamientos realizado por el personal del departamento de Restauración. Se
mostraran solo los campos que fueron seleccionados previamente.
Si se requiere ingresar otro campo se debe ingresar nuevamente en la opción
seleccionar procesos.
83
84
Bienes tratados permite seleccionar los bienes culturales que ingresaron al
departamento y fueron terminados y entregado a los clientes, permite obtener
información del bien cultural mientras estuvo en custodia del departamento.
Tiene las mismas opciones que la opción Bienes en tratamiento
INGRESAR BIEN
Tiene dos opciones:
BIEN INTERNO
El usuario ingresara al departamento los bienes que se encuentran en custodia
del Área Museo de la Casa de la Cultura Ecuatoriana.
85
Seleccionar en opciones de búsqueda código CCE como primera prioridad, en
caso de no encontrar utilizar las otras opciones de búsqueda.
El resultado de la búsqueda se mostrará en la tabla de resultados.
En la tabla de resultados seleccionar el bien cultural que se desea ingresar.
Completar la información adicional que requiere el formulario
Nombre de la persona que entrega el bien cultural y cargo.
Nombre de la persona que recibe el bien cultural y cargo.
Fecha de ingreso
Presionar el botón guardar para concluir con el proceso de ingreso de bien
cultural.
86
BIEN EXTERNO
Permite ingresar la información de los bienes culturales de clientes externos no
dependientes del Área de Museo de la Casa de la Cultura Ecuatoriana.
La opción de búsqueda sirve siempre y cuando el bien cultural que se desea
ingresar, haya ingresado anteriormente para ser intervenida en el departamento
de Restauración y Conservación de la Casa de la Cultura Ecuatoriana.
El ingreso de un bien cultural al departamento por primera vez se realiza llenando
todos los campos que se encuentran en el formulario.
Seleccionar el botón añadir para guardar y enviar la información a la base de
datos.
Si se desea ingresar otro bien realizar el proceso anterior.
Los bienes culturales ingresados se mostraran en la tabla que se encuentra en la
parte inferior de la página.
Seleccionar guarda para concluir con el proceso de ingreso de bienes culturales.
87
88
INGRESAR AL SISTEMA
El sistema como medida de seguridad para una aplicación web cierra sesión si
detecta que no existe actividad en el uso del sistema.
La opción ingresar al sistema redirige a la página iniciar sesión para que el usuario
ingrese nuevamente la información requerida para ingresar al sistema.
Cerrar sesión
Permite que el usuario salga del sistema una vez concluida sus actividades.