universidad central del ecuador facultad de … · 2021. 3. 16. · iii aprobaciÓn del tutor yo,...
TRANSCRIPT
UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA Y CIENCIAS APLICADAS
CARRERA DE INGENIERÍA INFORMÁTICA
Diseño de la plataforma de libros digitales de la UCE
Trabajo de Titulación modalidad Proyecto Integrador, previo a la obtención del Título
de Ingeniero Informático
AUTOR: Coello Allán Gustavo Marcelo
TUTORA: Ing. Alicia Lorena Andrade Bazurto. PhD
Quito, 2021
II
DERECHOS DE AUTOR
Yo, Coello Allán Gustavo Marcelo, en calidad de autor de los derechos morales y patrimoniales
el trabajo de titulación: DISEÑO DE LA PLATAFORMA DE LIBROS DIGITALES DE LA
UCE, modalidad integrador, de conformidad con el Art. 114 del CÓDIGO ORGÁNICO DE LA
ECONOMÍA SOCIAL DE LOS CONOCIMIENTOS, CREATIVIDAD E INNOVACIÓN,
concedo a favor de la Universidad Central del Ecuador una licencia gratuita, intransferible y no
exclusiva para el uso no comercial de la obra, con fines estrictamente académicos. Conservo a mi
favor todos los derechos de autor sobre la obra, establecidos en la normativa citada.
Al mismo, autorizo a la Universidad Central del Ecuador para que realice la digitalización y
publicación de este trabajo de titulación en el repositorio virtual, de conformidad de lo dispuesto
en el Art. 144 de la Ley Orgánica de Educación Superior.
El autor declara que la obra objeto de la presente autorización es original en su forma de
expresión y no infringe el derecho de autor de terceros, asumiendo la responsabilidad por cualquier
reclamación que pudiera presentarse por esta causa y liberando a la Universidad de toda
responsabilidad.
––––––––––––––––––––––––––
Coello Allán Gustavo Marcelo
CI: 020194602-7
III
APROBACIÓN DEL TUTOR
Yo, Ing. Alicia Lorena Andrade Bazurto PhD, en calidad de tutor del trabajo de titulación:
DISEÑO DE LA PLATAFORMA DE LIBROS DIGITALES DE LA UCE, elaborado por el
estudiante GUSTAVO MARCELO COELLO ALLÁN de la carrera de Ingeniería Informática,
Facultad de Ingeniería y Ciencias Aplicadas 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 APRUEBO, a fin de que el proyecto de trabajo integrador sea habilitado para continuar
con el proceso de titulación determinado por la Universidad Central del Ecuador.
Dado en la ciudad de Quito, a los 12 días del mes de Octubre de 2018
______________________
Ing. Alicia Lorena Andrade Bazurto PhD.
DOCENTE – TUTORA
CC: 1306194810
IV
DEDICATORIA
Dedico esta tesis a mi familia, en especial a mi madre que supo luchar y salir adelante frente a
las adversidades y obstáculos que le ha puesto la vida, a mi abuelita, tíos, tías, mi hermano, mis
primos pequeños quienes me enseñaron que, a pesar de la distancia, el apoyo mutuo, constancia,
responsabilidad y el cariño puedes alcanzar y cumplir tus propósitos en la vida.
V
AGRADECIMIENTO
Agradecerle a Dios, por brindarme la fuerza necesaria para no darme por vencido en estos años
de estudio, a mi familia por todo el apoyo que me brindaron para poder culminar mi carrera, a
todos los maestros quienes supieron formarme tanto personal como profesionalmente, a todos mis
amigos que, con su apoyo y ayuda formaron parte de este logro.
VI
CONTENIDO
DERECHOS DE AUTOR .......................................................................................................... ii
APROBACIÓN DEL TUTOR .................................................................................................. iii
DEDICATORIA ....................................................................................................................... iv
AGRADECIMIENTO ................................................................................................................ v
CONTENIDO ........................................................................................................................... vi
LISTA DE TABLAS ................................................................................................................. ix
LISTA DE ILUSTRACIONES .................................................................................................. x
RESUMEN ............................................................................................................................... xii
ABSTRACT ............................................................................................................................ xiii
INTRODUCCIÓN ..................................................................................................................... 1
CAPÍTULO I .............................................................................................................................. 2
1. Planteamiento del problema ......................................................................................... 2
1.1. Antecedentes ......................................................................................................... 2
1.2. Planteamiento del Problema .................................................................................. 3
1.3. Objetivos ............................................................................................................... 3
1.3.1. Objetivos Generales .............................................................................................. 3
1.3.2. Objetivos Específicos ............................................................................................ 4
1.4. Justificación ........................................................................................................... 4
1.5. Alcance .................................................................................................................. 5
1.6. Limitaciones .......................................................................................................... 5
1.7. Marco Legal .......................................................................................................... 6
CAPÍTULO II ............................................................................................................................ 8
2. Marco Teórico .............................................................................................................. 8
2.1. Conceptos previos ................................................................................................. 8
VII
2.2. Sistema de información ......................................................................................... 8
2.3. Ingeniería de software ........................................................................................... 9
2.4. Aplicativo web .................................................................................................... 10
2.5. Arquitectura de software ..................................................................................... 10
2.5.1. Patrones de arquitectura ...................................................................................... 10
CAPÍTULO III ......................................................................................................................... 16
3. METODOLOGÍA ....................................................................................................... 16
3.1. Tipos de metodologías ........................................................................................ 16
3.1.1. Metodologías agiles............................................................................................. 17
3.1.2. Metodologías tradicionales ................................................................................. 19
3.2. Justificación metodología seleccionada .............................................................. 19
3.3. Metodología Ágil XP .......................................................................................... 20
3.3.1. Ciclo de vida XP (eXtreme Programming) ......................................................... 21
3.4. Justificación de tecnologías de desarrollo ........................................................... 25
3.4.1. Plataforma de Desarrollo ..................................................................................... 25
3.4.2. Framework .......................................................................................................... 26
3.4.3. Componente Gráfico ........................................................................................... 27
3.5. Herramientas para el desarrollo........................................................................... 29
3.5.1. Spring Tools Suite ............................................................................................... 29
3.5.2. Visual Studio Code.............................................................................................. 29
3.5.3. MySQL ................................................................................................................ 29
3.5.4. Postman ............................................................................................................... 30
CAPÍTULO IV ......................................................................................................................... 32
4. Desarrollo del proyecto .............................................................................................. 32
4.1. Planificación ........................................................................................................ 32
4.2. Diseño.................................................................................................................. 33
4.3. Codificación ........................................................................................................ 40
4.4. Pruebas. ............................................................................................................... 49
4.5. Resultados ........................................................................................................... 56
4.6. Respaldos del Sistema: ........................................................................................ 57
CONCLUSIONES ................................................................................................................... 58
VIII
RECOMENDACIONES .......................................................................................................... 59
BIBLIOGRAFÍA ...................................................................................................................... 60
ANEXOS .................................................................................................................................. 64
Anexo A – Manual de Usuario ............................................................................................. 64
Anexo B – Documento de Satisfacción del Cliente ............................................................. 70
IX
LISTA DE TABLAS
Tabla 1. Tabla de Roles Principales. ........................................................................................ 32
Tabla 2. Actores del desarrollo de software. ............................................................................ 33
Tabla 3. Actores del Proyecto.. ................................................................................................ 34
X
LISTA DE ILUSTRACIONES
Ilustración 1. Arquitectura Cliente Servidor. ........................................................................... 11
Ilustración 2. Elementos de una Metodología. ......................................................................... 16
Ilustración 3. Fases, eXtreme Programming – XP. .................................................................. 21
Ilustración 4. Módulos de Spring Framework. ......................................................................... 27
Ilustración 5. Angular Framework. .......................................................................................... 28
Ilustración 6. Diagrama General Proyecto. .............................................................................. 34
Ilustración 7. Flujo del proceso Repositorio Virtual. ............................................................... 35
Ilustración 8. Diagrama de Caso de Uso Plataforma Libros Digitales. ................................... 36
Ilustración 9. Diagrama de Caso de Uso: Administración del Sistema. .................................. 37
Ilustración 10. Diagrama de Caso de Uso: Estudiante en el Sistema. ...................................... 37
Ilustración 11. Modelo de Base de datos. ................................................................................ 39
Ilustración 12. Arquitectura del sistema. .................................................................................. 40
Ilustración 13. Clase Entity. ..................................................................................................... 41
Ilustración 14. Interfaz Repository. .......................................................................................... 42
Ilustración 15. Servicio genérico. ............................................................................................. 42
Ilustración 16. Servicio. ........................................................................................................... 43
Ilustración 17. Lógica de negocio. ........................................................................................... 43
Ilustración 18. Servicio Rest. ................................................................................................... 45
Ilustración 19. Clase POJO Angular. ....................................................................................... 46
XI
Ilustración 20. Servicio Angular. ............................................................................................. 47
Ilustración 21. Estilos CSS. ...................................................................................................... 48
Ilustración 22. Archivo HTML. ............................................................................................... 49
Ilustración 23. Prueba de validación de campos Método POST. ............................................. 50
Ilustración 24. Error de validación Postman – Método POST. ................................................ 50
Ilustración 25. Mensaje de validación Spring Tools Suite. ...................................................... 51
Ilustración 26. Prueba de inserción en el sistema – Método POST. ........................................ 51
Ilustración 27. Mensaje 201 OK Método POST – Postman. ................................................... 51
Ilustración 28. Prueba Método GET – Postman. ...................................................................... 52
Ilustración 29. Prueba método PUT – Postman. ...................................................................... 53
Ilustración 30. Verificación de método PUT – Postman. ......................................................... 54
Ilustración 31. Prueba Método DELETE – Postman. .............................................................. 54
Ilustración 32. Verificación Método DELETE – Postman. ..................................................... 55
Ilustración 33. Ventana Login del Sistema. ............................................................................. 56
Ilustración 34. Ventana Login del Sistema. ............................................................................. 64
Ilustración 35. Menú del Sistema. ............................................................................................ 65
Ilustración 36. Administrador del Repositorio Digital. ............................................................ 66
Ilustración 37. Formulario de Registro de Libros. ................................................................... 67
Ilustración 38. Pantalla upload de archivos PDF. .................................................................... 67
Ilustración 39. Pantalla de verificación de archivos al Sistema. .............................................. 68
Ilustración 43. Pantalla de inicio del Sistema – Lista de libros en la aplicación. .................... 69
Ilustración 44. Visualización del libro en la pantalla. .............................................................. 69
XII
TÍTULO: diseño de la plataforma de libros digitales de la UCE
Autor: Coello Allán Gustavo Marcelo
Tutora: Ing. Alicia Lorena Andrade Bazurto. PhD
RESUMEN
Cuando un estudiante se dirige a una biblioteca, un libro físico de su interés es posible que no
se encuentre disponible, se encuentra prestado, el número de libros con los que cuenta la biblioteca
es limitado, los libros no se encuentran en condiciones debido a los años de uso que tiene entre
otras circunstancias. El presente proyecto tiene como objetivo solventar estos problemas, de ahí
nace la idea de la implementación de un repositorio virtual para el almacenamiento y visualización
de estos libros, apoyándose en tecnologías de desarrollo web, permitiendo a los estudiantes tener
acceso al o los libros de manera segura y confiable, con garantías de calidad, agilizando la
búsqueda, el acceso y la obtención de la información que necesita el estudiante.
PALABRAS CLAVE: APLICACIÓN WEB / LIBRO DIGITAL / PDF / BACKEND /
FRONTEND / SERVICIOS REST / MYSQL.
XIII
Title: Design of a digital books platform for the UCE
Author: Coello Allán Gustavo Marcelo
Tutor: Eng. Alicia Lorena Andrade Bazurto
ABSTRACT
When a student goes to the library, looking for a physical book, it may be not available, or it
has been granted to someone else; the amount of books in the library is limited anyway. Books are
not in good conditions due to the years of use, among other reasons. This project is intended to
solve such trouble; hence, the idea of implementing a virtual books repository to be stored and
maintained available for viewing and reading was proposed. The project should be supported by
web development technologies, and allows students to have access to books on a safe and reliable
fashion, with assurance of good quality, efficient search, access and obtaining of information
needed by students.
KEYWORDS: WEB APPLICATION / DIGITAL BOOK / PDF / BACKEND / FRONTEND
/ REST SERVICES.
1
INTRODUCCIÓN
Los libros digitales han ganado un espacio grande en el mundo actual, la tecnología con la que
se cuenta facilita el acceso a los mismos.
La rapidez, facilidad y agilidad con la que se puede obtener un libro digital a través de un
computador hoy en día es lo más común que se tiene, un libro físico es de gran utilidad, pero si se
necesitaría alrededor de 6 o 7 libros costaría mucho llevarlos de un lado a otro, a diferencia de
tenerlo digital, se podría acceder a muchos a la vez.
Según el informe del Centro Regional para el Fomento del Libro en América Latina y el Caribe
(Cerlalc), en Latinoamérica, “23 de cada cien títulos registrados en el ISBN (International Standard
Book Number) son libros electrónicos”, en esta época el libro electrónico viene siendo una gran
ventaja a los usuarios ya sea a la hora de la movilización o a la hora de conseguirlo, no ocupa
espacio ni se deteriora con el transcurso del tiempo inclusive de manera ecológica reduciendo la
tala de árboles (Cerlalc, 2017).
En la internet existe gran cantidad de libros digitales, pero surgen inconvenientes a la hora de
la atención del libro, existen muchas páginas de las cuales se puede realizar la descarga del libro,
pero muchas de estas páginas no son fiables, contienen redirecciones o incluso pueden tener virus
ocultos en el momento de descargarlos ocasionando posibles daños en los dispositivos del usuario.
El presente proyecto tiene la finalidad de que la Biblioteca de la Universidad Central del
Ecuador, tenga un Sistema en el cual los estudiantes tengan un sitio web seguro y confiable al cual
acceder a buscar su libro de interés para su autoeducación y el refuerzo de su aprendizaje.
2
CAPÍTULO I
1. PLANTEAMIENTO DEL PROBLEMA
1.1. Antecedentes
Los libros, revistas y material impreso están con nosotros desde hace ya varios siglos, sin
embargo, desde hace algunas décadas los libros digitales surgieron, el mundo de los libros
impresos se ha mostrado conservador a los cambios, pero desde que la tecnología empezó a dar
agigantados pasos la digitalización de algunos medios como la música o la fotografía por nombrar
algunos ejemplos se puso en auge.
El tiempo para los libros digitales había llegado, varias editoriales empezaron a pasar sus libros
físicos en libros digitales, además de editoriales, usuarios empezaron a publicar sus libros en este
formato.
Con la ayuda de software informático la creación de los libros digitales es ágil y rápido, para el
usuario el acceso a estos libros digitales le facilita tanto en cantidad como en movilidad, ya que en
una unidad de almacenamiento puede tener una enorme cantidad de libros a la mano, respecto de
los libros físicos, la movilidad de varios libros sería una ardua tarea.
Los sistemas informáticos con los que se cuenta agilizan estos procesos, haciendo de la vida de
los estudiantes más cómoda, más ágil y más fácil.
Un sistema con las características adecuadas para soportar las peticiones de los estudiantes de
los distintos libros que necesita, lograría evitarse la ardua labor de llevar uno por uno a lugar de
estudio, además de la búsqueda que entre tantos anaqueles puede resultarle fastidiosa, por lo cual
implementar un sistema facilitará al usuario realizar todas estas tareas.
3
1.2. Planteamiento del Problema
Tanto en el ámbito personal o académico, la obtención de nueva información es fundamental
para la resolución de problemas, investigación y autoeducación, con la tecnología actual el acceso
a internet facilita el acceso a la información, pero en muchos de los casos esta información no
suele ser completa o suele ser confusa, con la ayuda de un buen libro la información requerida será
más completa y detallada, además obtendrá información adicional útil para la resolución del
problema mencionado, en muchos casos las editoriales ya no han seguido con la publicación de
nuevos libros, o la biblioteca no contiene los suficientes libros para cubrir a todos los estudiantes
que requieren el libro, además de la ayuda con el medio ambiente.
Cuando se dirige a una biblioteca un libro físico de su interés es posible que no se encuentre
disponible, se encuentra prestado, el número de edición con los que cuenta la biblioteca es limitado
entre otras circunstancias.
¿Un lugar en línea, seguro y confiable, con garantías de calidad en el cual obtener un libro
digital ayudaría al usuario a agilizar la búsqueda y la obtención de la información del libro en
cuestión?
Sería el sistema más adecuado para la obtención de libros que tengan los inconvenientes
previamente mencionados.
1.3. Objetivos
1.3.1. Objetivos Generales
Diseñar y desarrollar la plataforma de libros digitales del Sistema Integrado de Bibliotecas de
la Universidad Central del Ecuador.
4
1.3.2. Objetivos Específicos
Recolección de información necesaria, para un correcto diseño de la plataforma.
Ofrecer el fácil acceso a estudiantes de la Universidad Central, que se encuentren dentro
de las instalaciones de la Biblioteca General, respetando los derechos de propiedad
intelectual.
Fomentar la digitalización de libros con alto patrimonio cultural y científico.
Establecer una metodología de desarrollo para el diseño del sistema, respetando los
requerimientos de la Biblioteca General.
1.4. Justificación
En el mundo de la internet existe un numero importantes de servicios web en el cual se
encuentran almacenados libros digitales, revistas, publicaciones, en su gran mayoría son servicios
no fiables o desconocidos, inclusive no cumpliendo con los derechos de autor (copyright), además
en estas páginas el antivirus se activa bloqueando el acceso, de ahí la necesidad de una plataforma
segura, centralizada, que brinde confianza al usuario para la obtención de libro digital que necesite
para su aprendizaje.
Las publicaciones digitales en una institución educativa pueden ser de gran utilidad ya que
permiten disponer de libros que las editoriales no disponen de sus publicaciones o en la biblioteca
cuenta con número reducido de libros físicos, además de almacenar grandes cantidades de
información ideal en caso de médicos, ingenieros, abogados, químicos, entre otros.
En la Biblioteca General de la Universidad Central del Ecuador, cuenta con un estimado de
20000 libros de gran calidad, pero con los años se han visto deteriorados, por lo cual prestarlas al
estudiante se ve en riego que sigan deteriorándose, varios de estos libros ya no cuentan con más
5
publicaciones, por lo cual digitalizarlos y almacenarlos en un repositorio virtual para el acceso de
los estudiantes es lo más necesario.
1.5. Alcance
En reunión con la Ingeniera María del Carmen Gaibor, directora del Sistema Integrado de
Bibliotecas de la Universidad Central del Ecuador y el Ingeniero José Chulde a cargo del
departamento de Sistemas de la Biblioteca General, el día viernes 26 de octubre del 2018 en las
instalaciones de la Biblioteca General, se pactó el desarrollo del sistema que contempla los
siguientes requerimientos:
El sistema contempla el diseño de la plataforma de libros digitales, que se refiere al ingreso
de los libros digitales con sus respectivos datos informativos como el nombre del libro,
autor, año de publicación, número de páginas, idioma, esto se hace con el fin de que la
biblioteca pueda disponer de unidades digitales para cubrir a los estudiantes que requieren
el libro.
Determinar la forma para evitar que el libro se pueda descargar de la plataforma, por
cuestiones de derechos de autor.
1.6. Limitaciones
El sistema se manejará de manera local dentro de la UCE, se trabajará con la información
proporcionada por la biblioteca general que servirá de guía para el desarrollo de la
plataforma, en caso contrario se la realizará a criterio del desarrollador guiado por el tutor
a cargo.
6
Con respecto a la infraestructura, la publicación y alojamiento de la aplicación en un
servidor en ambiente de producción, para uso general del sistema, queda a cargo de la
entidad solicitante según los lineamientos internos que ellos crean conveniente, para ello
se dejarán disponibles los ejecutables del sistema, código fuente, herramientas utilizadas
durante el desarrollo de la aplicación, manuales de instalación y funcionamiento del
sistema, quedando constancia del desarrollo y funcionamiento de la aplicación.
Para el almacenamiento de información en la base de datos en el ámbito de pruebas, se la
realizará con información brindada por la biblioteca general en caso contrario se realizará
con datos ficticios.
De no obtener acceso a la base de datos manejada por DTIC para el login del estudiante
con sus credenciales universitarias, se pondrá a consideración como contingencia el acceso
directo a la plataforma, con el único login del administrador del sistema.
El proyecto seguirá los estándares de desarrollo manejados por en DTIC, en caso de no
obtener dichos estándares se usará estándares elegidos por el desarrollador guiado por el
tutor a cargo.
1.7. Marco Legal
La Biblioteca General de la Universidad Central del Ecuador, de conformidad con el artículo
212 del código ORGANICO DE LA ECONOMIA SOCIAL DE LOS CONOCIMIENTOS,
CREATIVIDAD E INNOVACION, la digitalización de un ejemplar que se encuentre en la
colección de la biblioteca con Derechos de Autor no requiere autorización para su uso si se realiza
con los siguientes fines:
a. Preservar el ejemplar y sustituirlo en caso de extravío, destrucción o inutilización;
7
b. Entregar a otra biblioteca o archivo el ejemplar reproducido para fines de préstamo a los
usuarios de esta biblioteca o archivo. La biblioteca o archivo que reciba el ejemplar podrá
a su vez realizar una copia de él si ello es necesario para la conservación del ejemplar y la
copia se destina a la utilización por parte de sus usuarios; o,
c. Sustituir, en la colección permanente de otra biblioteca o archivo, un ejemplar que se haya
extraviado, destruido o inutilizado.
Una biblioteca o archivo podrá, además, realizar los siguientes actos:
La reproducción electrónica y comunicación pública de obras de su colección para ser
consultadas gratuita y simultáneamente hasta por un número razonable de usuarios, sólo en
terminales de redes de la respectiva institución o para usuarios de esa institución bajo su control,
en condiciones que garanticen que no se puedan hacer copias electrónicas de esas reproducciones.
8
CAPÍTULO II
2. MARCO TEÓRICO
2.1. Conceptos previos
En esta sección veremos las piezas clave para el entendimiento de la tesis de grado y el
desarrollo de la aplicación en su diseño y construcción.
2.2. Sistema de información
Las personas necesitan información por muchas razones y en diversas maneras. Por ejemplo,
es probable que usted busque información de entretenimiento para observar el televisor, ir al cine,
navegar por Internet, escuchar la radio y leer periódicos, revistas y libros. Sin embargo, en los
negocios, las personas y las organizaciones buscan utilizar la información de manera específica
para tomar decisiones sólidas y para resolver problemas.
Tanto la solución de problemas como la toma de decisiones requieren información. Reunir la
información adecuada de manera eficiente, guardarla para poder utilizarla y manipularla según se
requiera y emplearla para ayudar a una organización a lograr sus metas empresariales.
Un proceso es cualquier manipulación de los datos, con el propósito de producir información.
Por lo tanto, mientras los datos son materia prima, la información es una salida o resultado.
Igual que las materias primas se procesan en la fabricación o manufactura para crear productos
finales útiles, los datos básicos se procesan en los sistemas de información para crear información
útil (Effy, 2008).
Hay cuatro actividades en un sistema de información que producen los datos necesarios para
que las organizaciones tomen decisiones, controlen las operaciones, analicen problemas y creen
nuevos productos o servicios. Estas actividades son:
9
Entrada de la información: Es el proceso en el cual se captura o recolecta los datos en
crudo desde el interior de la organización o a través de su entorno externo.
Procesamiento de la información: Es el proceso en el cual se convierte esta entrada en
bruto en un formato significativo.
Salida de la información: Es la capacidad de transferir la información procesada a las
personas que harán uso de ella, o a las actividades para las que se utilizará (Laudon &
Laudon, 2012).
2.3. Ingeniería de software
La ingeniería del software es una disciplina de la ingeniería que comprende todos los aspectos
de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el
mantenimiento de éste después de que se utiliza. En esta definición, existen dos frases clave:
1. Disciplina de la ingeniería. Los ingenieros hacen que las cosas funcionen. Aplican teorías,
métodos y herramientas donde sean convenientes, pero las utilizan de forma selectiva y
siempre tratando de descubrir soluciones a los problemas, aun cuando no existan teorías y
métodos aplicables para resolverlos. Los ingenieros también saben que deben trabajar con
restricciones financieras y organizacionales, por lo que buscan soluciones tomando en
cuenta estas restricciones.
2. Todos los aspectos de producción de software. La ingeniería del software no sólo
comprende los procesos técnicos del desarrollo de software, sino también con actividades
tales como la gestión de proyectos de software y el desarrollo de herramientas, métodos y
teorías de apoyo a la producción de software.
10
En general, los ingenieros de software adoptan un enfoque sistemático y organizado en su
trabajo, ya que es la forma más efectiva de producir software de alta calidad. Sin embargo,
aunque la ingeniería consiste en seleccionar el método más apropiado para un conjunto de
circunstancias, un enfoque más informal y creativo de desarrollo podría ser efectivo en algunas
circunstancias. El desarrollo informal es apropiado para el desarrollo de sistemas basados en
Web, los cuales requieren una mezcla de técnicas de software y de diseño gráfico
(Sommerville, 2005).
2.4. Aplicativo web
En la ingeniería de software se denomina aplicación web a aquellas herramientas que los
usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet
mediante un navegador. En otras palabras, es una aplicación software que se codifica en un
lenguaje soportado por los navegadores web en la que se confía la ejecución al navegador (Solado
Zuña, 2018).
2.5. Arquitectura de software
La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus
componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y
evolución. (Sommerville, 2005).
2.5.1. Patrones de arquitectura
El patrón es una descripción del problema y la esencia de su solución, de forma que la solución
se pueda reutilizar en diferentes situaciones (Sommerville, 2005).
11
2.5.1.1. Arquitectura Cliente Servidor
En una arquitectura cliente-servidor, una aplicación se modela como un conjunto de servicios
proporcionados por los servidores y un conjunto de clientes que usan estos servicios. Los clientes
necesitan conocer qué servidores están disponibles, pero normalmente no conocen la existencia de
otros clientes. Clientes y servidores son procesos diferentes como se muestra en la Ilustración 1,
que representa un modelo lógico de una arquitectura distribuida cliente-servidor (Sommerville,
2005).
Ilustración 1. Arquitectura Cliente Servidor.
Fuente: (Schiaffarino, 2019).
Cuando hacemos referencia a clientes y servidores, nos referimos a los procesos lógicos en vez
de a las computadoras físicas sobre las que se ejecutan. El diseño de sistemas cliente-servidor
debería reflejar la estructura lógica de la aplicación que se está desarrollando. Una forma de ver
una aplicación como se muestra en la Ilustración 2, que muestra una aplicación estructurada en
tres capas. La capa de presentación está relacionada con la presentación de la información al
usuario y con toda la interacción con él. La capa de procesamiento de la aplicación está relacionada
12
con la implementación de la lógica de la aplicación, y la capa de gestión de datos está relacionada
con todas las operaciones sobre la base de datos (Sommerville, 2005).
Ilustración 2
Fuente: (Sommerville, 2005).
Adaptada por el Autor.
2.5.1.2. REST
Para algunas personas REST es una arquitectura, para otras es un patrón de diseño, para otras
un API. ¿Qué es REST exactamente? REST o Representational State Transfer es un ESTILO de
Arquitectura a la hora de realizar una comunicación entre cliente y servidor (Álvarez Caules,
2016).
Los 4 principios de REST
REST utiliza los métodos HTTP de manera explícita.
REST hace que los desarrolladores usen los métodos HTTP explícitamente de manera que
resulte consistente con la definición del protocolo. Este principio de diseño básico establece una
13
asociación uno-a-uno entre las operaciones de crear, leer, actualizar y borrar y los métodos HTTP
(Seta, 2008):
POST para crear un recurso en el servidor (Seta, 2008).
GET para obtener un recurso (Seta, 2008).
PUT para cambiar el estado de un recurso o actualizarlo (Seta, 2008).
DELETE para eliminar un recurso (Seta, 2008).
REST no mantiene estado.
Los servicios web REST necesitan escalar para poder satisfacer una demanda en constante
crecimiento. Se usan clusters de servidores con balanceadores de carga y alta disponibilidad,
proxies, y gateways de manera de conformar una topología serviciable, que permita transferir
peticiones de un equipo a otro para disminuir el tiempo total de respuesta de una invocación al
servicio web. El uso de servidores intermedios para mejorar la escalabilidad hace necesario que
los clientes de servicios web REST envíen peticiones completas e independientes; es decir, se
deben enviar peticiones que incluyan todos los datos necesarios para cumplir el pedido, de manera
que los componentes en los servidores intermedios puedan redireccionar y gestionar la carga sin
mantener el estado localmente entre las peticiones (Seta, 2008).
REST expone URIs con forma de directorios.
Desde el punto de vista del cliente de la aplicación que accede a un recurso, la URI determina
qué tan intuitivo va a ser el web service REST, y si el servicio va a ser utilizado tal como fue
pensado al momento de diseñarlo. La tercera característica de los servicios web REST es
justamente sobre las URIs (Seta, 2008).
Las URI de los servicios web REST deben ser intuitivas, hasta el punto de que sea fácil
adivinarlas. Pensemos en las URI como una interfaz auto-documentada que necesita de muy poca
14
o ninguna explicación o referencia para que un desarrollador pueda comprender a lo que apunta, y
a los recursos derivados relacionados (Seta, 2008).
REST transfiere XML, JSON, o ambos.
La representación de un recurso en general refleja el estado actual del mismo y sus atributos al
momento en que el cliente de la aplicación realiza la petición. Debido a la interacción entre
servicios, los recursos se comparten con diferentes formatos como XML o JSON (Seta, 2008).
15
16
CAPÍTULO III
3. METODOLOGÍA
En esta sección se describe las distintas metodologías para el desarrollo de software, de entre
de las que se escogerá la que más se ajuste a las necesidades del proyecto.
Ilustración 2. Elementos de una Metodología.
Fuente: (unADM, 2015).
3.1. Tipos de metodologías
Cabe destacar que estos métodos no son impuestos, solo son recomendaciones que se
aconseja seguir para mejorar el trabajo. El marco de trabajo referencial, que se usa para
estructurar, planificar y controlar las fases del proceso de desarrollo de sistemas de
información a crearse. Estas son básicamente usadas con los siguientes objetivos
(StudentPlace, 2018):
17
Definir actividades a llevarse a cabo en un Proyecto.
Unificar criterios en la organización para el desarrollo del proyecto.
Proporcionar puntos de control y revisión.
Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en sí.
Ajustarse a los plazos y costos previstos en la planificación.
Generar de forma adecuada la documentación asociada a los sistemas.
Facilitar el mantenimiento posterior de los sistemas.
Existen dos clases de metodología Ágiles y Clásicas.
3.1.1. Metodologías agiles
Las Metodologías Ágiles son aquellas que permiten adaptar la forma de trabajo a las
condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar el
proyecto y su desarrollo a las circunstancias específicas del entorno (Rosselló Villán, 2019).
SCRUM: Scrum es una metodología Ágil y flexible que trata de ser de utilizar en proyectos
donde el nivel de incertidumbre es alto. Su objetivo será controlar y planificar proyectos
con un gran volumen de cambios de última hora, en donde la incertidumbre sea elevada.
(Rosselló Villán, 2019).
XP: Es un enfoque de la ingeniería de software formulado por Kent Beck. Es una de las
llamadas Metodologías ágiles de desarrollo de software más exitosas de los tiempos
recientes, nace como nueva disciplina de desarrollo de software. (Martín Campos, 2019).
Kanban: Actualmente, el término Kanban ha pasado a formar parte de las llamadas
metodologías ágiles, cuyo objetivo es gestionar de manera general cómo se van
18
completando las tareas. Kanban es una palabra japonesa que significa “tarjetas visuales”,
donde Kan es “visual”, y Ban corresponde a “tarjeta”. (Martín Campos, 2019).
ScrumBan: Conocemos Kanban y Scrum como metodologías de gestión Agile. Scrumban
combina las mejores características de ambos métodos. Reúne la naturaleza preceptiva de
Scrum y la capacidad de mejora del proceso de Kanban, permitiendo a los equipos moverse
hacia el desarrollo Agile y a mejorar constantemente sus procesos. Scrumban se está
haciendo especialmente popular en industrias en las que el desarrollo del proyecto y el
mantenimiento van juntos. (kanban tool, s.f.).
Lean: El término “Lean” o “Lean Manufacturing” (cuya traducción sería algo así como
fabricación esbelta) es otro término que, al igual que el Kanban, tiene su origen en Toyota.
De hecho, “Lean” es sinónimo de Toyota Production System, una estrategia de fabricación
aplicada con mucho éxito en Japón y ahora muy famosa en el mundo del software, muchas
veces bajo el término de Lean Software Development. (Garzas, 2012).
FDD (Feature Driven Development): La metodología ágil FDD está orientada a equipos
más grandes, con más personas que aquellos a los que normalmente se aplican otras
metodologías ágiles como Scrum. La metodología ágil FDD contempla la figura del jefe
de proyecto y una fase de arquitectura. (Garzas, 2012).
TDD (Test Driven Development): TDD es una técnica de programación en la que se evita
posibles problemas futuros que pudieran surgir durante el ciclo de vida del software en
desarrollo. Básicamente, las pruebas se escriben antes de programar la funcionalidad,
garantizando la calidad y la estabilidad máxima (Sorsa, 2017).
19
3.1.2. Metodologías tradicionales
Para el desarrollo de software cada metodología tiene más o menos su propio enfoque. Estos
enfoques son más generales, de aquellos que se desarrollan con metodologías específicas.
Los sistemas tradicionales de ciclo de vida desarrollados empezaron a elaborarse a partir de la
década del 60 del siglo pasado; para desarrollar a gran escala funcional de sistemas de negocio en
una época de grandes conglomerados empresariales. La principal idea era continuar con el
desarrollo de sistemas de información en una estructura metódica muy deliberada, considerando
cada una de las etapas del ciclo de vida. Los sistemas de información en torno a las actividades
resueltas pesadas para el procesamiento de datos y rutinas de cálculo.
Algunas metodologías tradicionales son las siguientes:
Cascada.
Evolutivo.
Prototipo.
Desarrollo basado en Componentes.
Espiral.
Incremental.
3.2. Justificación metodología seleccionada
Una vez analizada cada una de las diferentes metodologías existentes en el mundo de la
ingeniería de software, teniendo en cuenta características, ventajas y desventajas, para la
construcción del presente proyecto se optó por elegir el entorno de metodologías agiles, más en
específico la metodología XP (Extreme Programming), ya que es la metodología más utilizada y
20
la más exitosa de los últimos tiempos, además que es la que más se ajusta a las necesidades del
proyecto a realizar.
Esta metodología a seguir, se podrá definir cada una de las tareas en las distintas fases, para un
mejor manejo del proyecto.
3.3. Metodología Ágil XP
La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de
software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de
software. Al igual que éstos, la programación extrema se diferencia de las metodologías
tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.
Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse
a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor
y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos
después en controlar los cambios en los requisitos (Bautista).
La metodología XP o Programación Extrema es una metodología ágil y flexible utilizada para
la gestión de proyectos.
Extreme Programming se centra en potenciar las relaciones interpersonales del equipo de
desarrollo como clave del éxito mediante el trabajo en equipo, el aprendizaje continuo y el buen
clima de trabajo.
Esta metodología pone el énfasis en la retroalimentación continua entre cliente y el equipo de
desarrollo y es idónea para proyectos con requisitos imprecisos y muy cambiantes (Calvo, 2018).
21
3.3.1. Ciclo de vida XP (eXtreme Programming)
El ciclo de vida XP tiene las siguientes fases:
Ilustración 3. Fases, eXtreme Programming – XP.
Autor: (Vila Grau, Management Plaza, s.f.).
3.3.1.1. Análisis
Esta Fase define los requerimientos, funcionalidades, alcance y riesgos del proyecto, junto con
el cliente, además se obtendrá una vista previa de los tiempos de la aplicación.
En esta fase se debe tomar en cuenta los siguientes puntos:
Historias del usuario:
Las historias de usuario tienen el mismo propósito que los casos de uso. Las escriben
los propios clientes, son similares al empleo de escenarios, con la excepción de que no se
limitan a la descripción de la interfaz de usuario. También conducirán el proceso de
creación de los test de aceptación (empleados para verificar que las historias de usuario han
sido implementadas correctamente).
22
Existen diferencias entre estas y la tradicional especificación de requisitos. La
principal diferencia es el nivel de detalle. Las historias de usuario solamente
proporcionaran los detalles sobre la estimación del riesgo y cuánto tiempo conllevará la
implementación de dicha historia de usuario.
Release Planning:
Es una planificación donde los desarrolladores y clientes establecen los tiempos de
implementación ideales de las historias de usuario, la prioridad con la que serán
implementadas y las historias que serán implementadas en cada una de las versiones del
programa.
Iteraciones:
Todo proyecto desarrollado con esta metodología siempre debe dividirse en iteraciones,
al comienzo de cada iteración se deberá elegir con que historia de usuario va a empezará
la iteración y así las actividades que hará al inicio una nueva iteración.
Rotaciones:
Las rotaciones evitarán que las personas se conviertan en sí mismas en un cuello de
botella. Las rotaciones permitirán que el equipo de trabajo conozca cómo funciona el
sistema.
Correcciones:
Cuando el proceso falla se debe corregir el proceso, el equipo de trabajo debe estar al
corriente de los cambios. Para que esto funcione correctamente hay que crear unidades de
prueba de cada módulo que se desarrolle.
23
3.3.1.2. Diseño
La sugerencia es que se debería conseguir simples y sencillos diseños. Esto conlleva a procurar
a hacer lo menos complicado posible para el usuario o cliente, pueda conseguir un diseño en forma
entendible e implementable que a la larga el resultado es menor costo, en menos tiempo y esfuerzo
en el proceso de desarrollarlo. Toda esta fase permite lograr, crear la parte física del proyecto, la
interfaz que tendrá el usuario o cliente con el proyecto (Obando, 2015).
En esta fase se debe tomar en cuenta los siguientes puntos:
Simplicidad:
Se sugiere conseguir diseños simples y sencillos.
Terminología adecuada:
Usar glosarios de términos y una correcta especificación de los nombres de métodos y
clases ayudará a comprender el diseño y facilitará sus posteriores ampliaciones y la
reutilización del código (Franco, n.d.).
Riesgos:
Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una pareja de
desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese
problema (Franco, n.d.).
Funcionalidad extra
Nunca se debe añadir funcionalidad extra al programa, aunque se piense que en un
futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica que el desarrollo
de funcionalidad extra es un desperdicio de tiempo y recursos (Franco, n.d.).
24
Refactorizar:
Refactorizar es mejorar y modificar la estructura y codificación de códigos ya creados
sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos para
procurar optimizar su funcionamiento (Franco, n.d.).
3.3.1.3. Codificación
La codificación debe hacerse ateniendo a estándares de codificación ya creados. Programar bajo
estándares mantiene el código consistente y facilita su comprensión y escalabilidad (Franco, n.d.).
Crear test que prueben el funcionamiento de los distintos códigos implementados nos ayudará
a desarrollar dicho código. Crear estos test antes nos ayuda a saber qué es exactamente lo que tiene
que hacer el código a implementar y sabremos que una vez implementado pasará dichos test sin
problemas ya que dicho código ha sido diseñado para ese fin.
La optimización del código siempre se debe dejar para el final. Hay que hacer que funcione y
que sea correcto, más tarde se puede optimizar.
X.P afirma que la mayoría de los proyectos que necesiten más tiempo extra que el planificado
para ser finalizados no podrán ser terminados a tiempo se haga lo que se haga, aunque se añadan
más desarrolladores y se incrementen los recursos. La solución que plantea X.P es realizar un
nuevo "Release plan" para concretar los nuevos tiempos de publicación y de velocidad del
proyecto.
A la hora de codificar no seguimos la regla de X.P que aconseja crear test de funcionamiento
con entornos de desarrollo antes de programar. Nuestros test los obtendremos de la especificación
de requisitos ya que en ella se especifican las pruebas que deben pasar las distintas funcionalidades
25
del programa, procurando codificar pensando en las pruebas que debe pasar cada funcionalidad.
(Castillo , Figueroa , & Sevilla , s.f.).
3.3.1.4. Pruebas
Las pruebas de aceptación XP son especificadas por el cliente y se centran es las características
y funcionalidad generales del sistema que son visibles y revisables por parte del cliente, basadas
en las historias proporcionadas por este. (Pater, 2013).
3.4. Justificación de tecnologías de desarrollo
Para el desarrollo de la plataforma de libros digitales de la UCE, teniendo en cuenta las
tecnologías existentes para el desarrollo web, se tomó en cuenta los siguientes puntos.
3.4.1. Plataforma de Desarrollo
Se ha seleccionado como plataforma de desarrollo JEE, plataforma que se ha venido conociendo
desde el inicio de la carrera, por lo que se tiene un cierto grado de madurez con esta plataforma.
Java Enterprise Edition, Java EE en adelante, es un conjunto de estándares de tecnologías
dedicadas al desarrollo de Java del lado del servidor. La plataforma Java EE consta de un conjunto
de servicios, API y protocolos que proporcionan la funcionalidad necesaria para desarrollar
aplicaciones basadas en web de varios niveles. Es decir, desarrollaremos aplicaciones
empresariales distribuidas, con arquitecturas multicapa, escritas en Java y que se ejecutan en un
servidor de aplicaciones. (Fontanet, 2016).
26
3.4.2. Framework
3.4.2.1. Spring Framework
Tal vez una de las partes más difíciles de explicar Spring es clasificar exactamente lo que es.
Por lo general, Spring se describe como un Framework liviano para la construcción de aplicaciones
Java, pero esa declaración muestra dos puntos interesantes.
En primer lugar, puede usar Spring para compilar cualquier aplicación en Java (por ejemplo,
aplicaciones independientes, web o JEE), a diferencia de muchos otros frameworks (como Apache
Struts, que está limitado a aplicaciones web).
En segundo lugar, la parte liviana de la descripción no se refiere realmente a la cantidad de
clases o al tamaño de la distribución, sino que define el principio de la filosofía Spring como un
todo, es decir, un impacto mínimo. Spring es liviano en el sentido de que tienes que hacer pocos
cambios, si es que hay alguno, en tu código de aplicación para obtener los beneficios de Spring
Core, y si eliges dejar de usar Spring en cualquier momento, lo encontrarás bastante simple.
El núcleo del Spring Framework se basa en el principio de inversión de control. IoC es una
técnica que externaliza la creación y gestión de dependencias de componentes (Cosmina , Harrop
, Schaefer, & Ho, 2017).
27
Ilustración 4. Módulos de Spring Framework.
Autor: (Tutorials Point, s.f.).
3.4.2.2. Spring Boot
El objetivo de Spring Boot es proporcionar un conjunto de herramientas para construir
rápidamente aplicaciones de Spring que sean fáciles de configurar (Perry, 2017).
Citando la página oficial del Spring dice, “Spring Boot facilita la creación de aplicaciones
basadas en Spring, autónomas y del nivel de producción que "simplemente se ejecutan". Tomamos
una visión dogmática de la plataforma de Spring y de las bibliotecas de terceros para que pueda
empezarse con el mínimo revuelo” (Perry, 2017).
3.4.3. Componente Gráfico
Para la parte de componentes grafico (parte web) se tomó la decisión de utilizar Angular.
28
3.4.3.1. Angular
Angular es un framework de desarrollo para JavaScript creado por Google. La finalidad de
Angular es facilitarnos el desarrollo de aplicaciones web SPA y además darnos herramientas para
trabajar con los elementos de una web de una manera más sencilla y optima.
Otro propósito que tiene Angular es la separación completa entre el front-end y el back-end en
una aplicación web.
¿Qué es una aplicación web SPA desarrollada con Angular?
Una aplicación web SPA creada con Angular es una aplicación de una sola página, en la cual
la navegación entre secciones y páginas de la aplicación, así como la carga de datos, se realiza de
manera dinámica, casi instantánea, asíncronamente haciendo llamadas al servidor (backend con
un API REST) y sobre todo sin refrescar la página en ningún momento.
Es decir, las aplicaciones web que podemos hacer con Angular son reactivas y no recargan el
navegador, todo es muy dinámico y asíncrono. (Robles, 2019).
Ilustración 5. Angular Framework.
Autor: (Abacus Consulting, 2018)..
29
3.5.Herramientas para el desarrollo
Parte vital de la construcción de la aplicación son las herramientas que facilitaran la creación
del sistema, tanto del lado BackEnd, FrontEnd, y almacenamiento de toda la información como el
motor de Base de Datos.
3.5.1. Spring Tools Suite
Spring Tool Suite es un entorno de desarrollo basado en Eclipse que está personalizado para
desarrollar aplicaciones Spring. Proporciona un entorno listo para usar para implementar, depurar,
ejecutar e implementar sus aplicaciones Spring, incluidas integraciones para Pivotal tc Server,
Pivotal Cloud Foundry, Git, Maven, AspectJ, y se suma a las últimas versiones de Eclipse (Solado
Zuña, 2018).
3.5.2. Visual Studio Code
Este es un programa que permite editar código fuente desarrollado por Microsoft para
Windows, Linux y macOS. Incluye soporte para depuración, control de Git integrado, resaltado de
sintaxis, finalización de código inteligente, fragmentos de código y refactorización de código.
3.5.3. MySQL
Una compañía sueca llamada MySQL AB originalmente desarrolló MySQL en 1994. La
compañía de tecnología de los Estados Unidos Sun Microsystems luego tomó el control por
completo cuando compró MySQL AB en el 2008.
MySQL es un sistema de gestión de base de datos relacional (RDBMS) de código abierto,
basado en lenguaje de consulta estructurado SQL (Rouse, 2015).
30
3.5.4. Postman
Postman es una herramienta que se utiliza, sobre todo, para el testing de API REST, aunque
también admite otras funcionalidades que se salen de lo que engloba el testing de este tipo de
sistemas.
Gracias a esta herramienta, además de testear, consumir y depurar API REST, podremos
monitorizarlas, escribir pruebas automatizadas para ellas, documentarlas, mockearlas, simularlas,
entre otras. (López, 2019).
31
32
CAPÍTULO IV
4. DESARROLLO DEL PROYECTO
En esta capitulo se detallará cada una de las fases, actividades y tareas realizadas durante el
desarrollo del proyecto, en base a la metodología y tecnologías establecidas previamente.
4.1. Planificación
En esta fase de planificación, se realizaron las respectivas reuniones con los responsables de la
biblioteca general de la Universidad Central del Ecuador para determinar los requerimientos,
alcances, historias, ideas etc. acerca del desarrollo del proyecto.
Definiendo los roles para el desarrollo de la aplicación siguiendo la metodología XP.
Tabla 1. Tabla de Roles Principales.
Actores Roles
Ing. Alicia Andrade. PhD. Propietaria del Proyecto.
Gustavo Coello Desarrollador.
Biblioteca General UCE Cliente.
4.1.1. Historias del usuario
La prioridad del proyecto es establecer el diseño de la plataforma para libros digitales, dirigido
hacia los estudiantes de la UCE, se puede nombrar las distintas actividades durante el proceso:
Subir los archivos PDF al directorio de almacenamiento.
Registro de libros con sus respectivos detalles para el reconocimiento de cada archivo PDF.
Lista de cada uno de los archivos PDF.
Administrador del sistema.
Estudiante.
33
4.2. Diseño
Una vez determinadas los requerimientos funcionales del sistema ya se puede tener una idea
principal del camino a seguir para el desarrollo la aplicación.
4.2.1. Actores del desarrollo del proyecto
El cimiento del desarrollo del proyecto es establecer los actores participantes, para llevar un
orden y establecer los roles que desempeñarán durante la construcción de la aplicación.
La siguiente tabla muestra los actores y que rol desempeñan en el proyecto:
Tabla 2. Actores del desarrollo de software.
Actor Rol Descripción
Ing. Alicia Andrade Project Manager Encargado de coordinar y
gestionar al equipo para
cumplir los objetivos de
gestión del proyecto.
Gustavo Coello Developer Encargado del modelado,
desarrollo y tester del
desarrollo del proyecto.
4.2.2. Actores del Proyecto
Estos actores están ligados con el proceso de la plataforma virtual, ya que son ellos los que
interactúan con el sistema que se pondrá en producción.
La siguiente tabla muestra estos actores y que rol desempeñan en el proyecto:
34
Tabla 3. Actores del Proyecto..
Actor Descripción
Administrador Está a cargo de todo el sistema, ya que tiene acceso total a cada uno de los
módulos que presenta el sistema.
Estudiante Solo podrá visualizar los documentos que el administrador subió al sistema.
Definidos los actores del sistema se puede definir el diagrama general como interactúan cada
uno de ellos en sistema, como se muestra a continuación:
Ilustración 6. Diagrama General Proyecto.
Autor: Gustavo Coello.
4.2.3. Flujo del proceso
La ilustración 7 indica el diagrama de procesos, podemos ver el flujo que sigue el proyecto de
inicio a fin, determinando cada una de las actividades del sistema.
35
Ilustración 7. Flujo del proceso Repositorio Virtual.
Autor: Gustavo Coello.
4.2.4. Casos de uso
Con los diagramas de casos de uso podemos definir y ver a detalle el comportamiento de los
usuarios dentro del sistema.
36
4.2.4.1. Plataforma de libros digitales
En la ilustración 8, se muestra el acceso y la interacción que tienen cada uno de los actores
dentro del sistema de Plataforma de Libros Digitales
Ilustración 8. Diagrama de Caso de Uso Plataforma Libros Digitales.
Autor: Gustavo Coello.
4.2.4.2. Administrador
En la Ilustración 9, presenta el acceso que tiene el usuario administrador, este perfil de usuario
tiene el acceso total al sistema, sin ninguna restricción.
37
Ilustración 9. Diagrama de Caso de Uso: Administración del Sistema.
Autor: Gustavo Coello.
4.2.4.3. Estudiante
En la Ilustración 10, se presenta el acceso que tiene el usuario estudiante, este rol de usuario
tiene el acceso restringido al sistema, solo tiene acceso a la visualización de los libros digitales
disponibles en el sistema, este perfil solo tendrá acceso a una solo opción de menú en el sistema.
Ilustración 10. Diagrama de Caso de Uso: Estudiante en el Sistema.
Autor: Gustavo Coello.
38
4.2.5. Diseño de Base de Datos
Una vez definido todo el sistema, se debe definir el almacenamiento de cada uno de los datos
que se van ingresar en el sistema.
La Ilustración 11 muestra el modelo de base de datos que se va a utilizar para el almacenamiento
de la información, así como las relaciones que tienen entre sí:
39
Ilustración 11. Modelo de Base de datos.
Autor: Gustavo Coello.
40
4.2.6. Arquitectura del Sistema
En esta etapa del proyecto se establece como va hacer la arquitectura que va a llevar el sistema,
la siguiente ilustración muestra cada uno de los componentes que va a tener la aplicación.
La arquitectura que se presenta a continuación, será la referencia que siga los desarrolladores
para la construcción del sistema.
Ilustración 12. Arquitectura del sistema.
Autor: Gustavo Coello.
4.3. Codificación
En esta fase se explica cómo fue la codificación del sistema tanto en BackEnd y FrontEnd.
4.3.1. BackEnd
La codificación en la parte BackEnd se la realizo con Spring Boot, a continuación, se muestra
a detalle cómo se codifico las clases Java.
41
4.3.1.1. Modelo
En esta clase es la de mapeo a la base de datos, Spring nos da la facilidad de crear la clase Entity
y en la base de datos solo crear la base, Spring se encargará de crear las tablas en la base de datos.
La anotación @Entity le dice a Spring que esta clase es una entidad de mapeo a la base de datos,
como muestra la ilustración 13.
Ilustración 13. Clase Entity.
Autor: Gustavo Coello.
4.3.1.2. Repository
JPA Repository brinda la facilidad de persistencia a la base de datos, bridando todos los
métodos de persistencia extendiendo de la clase JpaRepository, como muestra la ilustración 14.
42
Ilustración 14. Interfaz Repository.
Autor: Gustavo Coello.
4.3.1.3. Servicios
Las clases que se muestran a continuación indican la lógica de negocio de la aplicación, esta
capa está dividida en dos subcapas:
4.3.1.3.1. Servicio
La interfaz service define los métodos que va a utilizar la aplicación, como indica la ilustración
15, se utilizó una clase genérica, y de esa clase partir para el resto de interfaces, para reutilización
de código:
Ilustración 15. Servicio genérico.
Autor: Gustavo Coello.
Una vez definidos los métodos se tiene que implementar dichos métodos para saber cuál va
hacer el funcionamiento de cada uno, como muestra la ilustración 16.
43
Ilustración 16. Servicio.
Autor: Gustavo Coello.
4.3.1.3.2. Implementación del servicio
En esta clase se define la lógica de negocio de la aplicación, a esta clase se le debe agregar la
anotación @Service para decirle a Spring que es una clase Servicio. La anotación @Autowired
indica inyección de dependencia, como indica la ilustración 17.
Ilustración 17. Lógica de negocio.
Autor: Gustavo Coello.
44
4.3.1.4. Controlador – Servicio REST
Una vez codificados las demás capaz y que puedan comunicarse entre ellas, se debe exponer el
servicio para que pueda ser consumido desde el exterior.
Se debe configurar los endpoints para cada uno de los métodos que necesitemos exponerlos,
Spring brinda las anotaciones para exponer estos métodos a través de servicios REST utilizando
métodos HTTP.
Como se muestra en la ilustración 18 la anotación @RestController le dice a Spring que esta
clase expone un endpoint.
45
Ilustración 18. Servicio Rest.
Autor: Gustavo Coello.
46
4.3.2. FrontEnd
La codificación para el FrontEnd que es la vista que va a tener el usuario final se la realizo con
el Framework Angular.
4.3.2.1. Modelo
Angular necesita un modelo idéntico al que se encuentra en Spring ya que se comunican a través
de archivos Json, por lo cual debe tener la misma estructura para su comunicación, la ilustración
19 muestra una clase POJO con la sintaxis de Angular.
Ilustración 19. Clase POJO Angular.
Autor: Gustavo Coello.
4.3.2.2. Servicio
Al igual que Spring cuando expone un Servicio REST, del lado Angular para consumir esos
servicios se tiene una clase con la anotación @Injectable, la ilustración 20 indica los métodos para
consumir los servicios expuestos por el BackEnd.
47
Ilustración 20. Servicio Angular.
Autor Gustavo Coello.
4.3.2.3. Componente
El componente en Angular interactúa tanto con el modelo y el servicio, aquí se encuentra la
vista que va a mostrar en el navegador web, los estilos CSS y las validaciones JavaScript.
48
4.3.2.3.1. CSS
En el archivo .css van los estilos que va a tener la página HTML, la ilustración 21 muestra los
estilos que tendrá una página del sistema.
Ilustración 21. Estilos CSS.
Autor: Gustavo Coello.
49
4.3.2.3.2. HTML
La ilustración 22 muestra el archivo .html es lo que se muestra en la página web, no es más que
código HTML, pero con estilo del Framework Angular.
Ilustración 22. Archivo HTML.
Autor: Gustavo Coello.
4.4. Pruebas.
Una vez llegada a esta fase, se realizará las pruebas correspondientes al BackEnd y en la interfaz
FrontEnd, así verificar que se cumplan los requerimientos y el sistema funcione correctamente, de
esta manera si encontramos alguna falla la corregiremos.
4.4.1. Servicios REST.
Para realizar las pruebas del BackEnd utilizaremos la herramienta Postman para verificar que
los métodos HTTP funcionen correctamente.
50
La siguiente ilustración muestra el método POST de inserción en la base de datos.
Cuando enviamos el JSON incompleto ya que los campos a llenar son obligatorios tanto en
Postman como en el Spring Tools Suite nos indicará que el campo no puede venir vacío.
Ilustración 23. Prueba de validación de campos Método POST.
Autor: Gustavo Coello.
Postman nos muestra el siguiente error:
Ilustración 24. Error de validación Postman – Método POST.
Autor: Gustavo Coello.
51
En el Spring Tool Suite indica que el campo no puede venir vacío:
Ilustración 25. Mensaje de validación Spring Tools Suite.
Autor: Gustavo Coello.
Con esto se verifica que las validaciones funcionan correctamente, ahora la ilustración 26
muestra como inserta correctamente con en JSON enviado completo:
Ilustración 26. Prueba de inserción en el sistema – Método POST.
Autor: Gustavo Coello.
Postman devuelve 201 que significa creado correctamente, como muestra la ilustración 27:
Ilustración 27. Mensaje 201 OK Método POST – Postman.
Autor: Gustavo Coello.
52
Para verificar si los datos ingresados anteriormente si se encuentra creado, utilizaremos el
método GET para obtener la información de la Base de datos, la ilustración 28 indica que los datos
han sido ingresados correctamente.
Ilustración 28. Prueba Método GET – Postman.
Autor: Gustavo Coello.
53
Para actualizar utilizaremos el método PUT, actualizaremos el nombre del libro, en la
ilustración 29 se muestra que devuelve un 200, que actualizo de manera correcta:
Ilustración 29. Prueba método PUT – Postman.
Autor: Gustavo Coello.
54
Verifiquemos con una petición GET, la ilustración 30 verifica la actualización del campo:
Ilustración 30. Verificación de método PUT – Postman.
Autor: Gustavo Coello.
Para eliminar, utilizaremos el método DELETE, eliminaremos la información que tenga
idBook=2, la ilustración 31 indica un 200, que significa que se eliminó correctamente.
Ilustración 31. Prueba Método DELETE – Postman.
Autor: Gustavo Coello.
55
Verifiquemos con una petición GET, la ilustración 32 verifica la eliminación del campo:
Ilustración 32. Verificación Método DELETE – Postman.
Autor: Gustavo Coello.
56
4.5. Resultados
Una vez realizadas las pruebas y verificado que funciona correctamente los servicios, se puede
verificar el correcto funcionamiento de la aplicación, como podrá observar detalladamente en las
ilustraciones del Anexo A.
Ilustración 33. Ventana Login del Sistema.
Autor: Gustavo Coello.
57
4.6. Respaldos del Sistema:
En conversación con el Ingeniero José Chulde, encargado del departamento de Sistemas de la
Biblioteca General de la Universidad Central del Ecuador, los lineamientos para respaldos a seguir
serán los internos de la Biblioteca General, el cual lo realizan semanalmente, tanto aplicación como
Base de Datos, lo realizan mediante la programación de CRON diseñado, codificado, probado e
implementado por los encargados del departamento de Sistemas de la Biblioteca General, este
CRON estará desarrollado sobre el Bash de Linux, en este caso la distribución de Linux será centos
7.
58
CONCLUSIONES
Con la información proporcionada por los directivos de la Biblioteca General de la
Universidad Central del Ecuador se logró obtener un diseño amigable y de fácil uso para
los estudiantes puedan revisar los libros almacenados en el Sistema, sin infringir los
derechos de Autor.
Al tener un sistema en el cual se puede almacenar libros con alto valor cultural en forma
digital, estos libros físicos podrán almacenarse en algún lugar seguro, con lo cual ya se
puede digitalizar todos los libros que la biblioteca crea pertinente y almacenarlos en el
Sistema.
La implementación de este sistema permite que el uso de los libros físicos se reduzca en lo
mínimo, con ello conservar por mayor tiempo estos libros físicos con alto valor
patrimonial.
Gracias al sistema los estudiantes con solo presionar un clic podrán buscar el libro de su
elección sin tener que buscar en los lockers de la biblioteca, con lo que se ahorran mucho
tiempo en la búsqueda, sin saber si el libro ya ha sido utilizado o ya no hay más libros a
disposición.
59
RECOMENDACIONES
Una vez realizadas las pruebas del sistema se recomienda una buena conexión a internet,
mínimo 5Mbps, para un funcionamiento óptimo de la aplicación.
Se recomienda evaluar que libros necesitan ser digitalizados con mayor urgencia y subirlos
al sistema.
Utilizar la información que se encuentra en la plataforma de manera adecuada y sin
infringir las reglas de derechos de autor.
En un futuro para mejoras en el sistema o incluir más módulos, tener en cuenta las
tecnologías que se utilizó y verificar las tecnologías salientes para confirmar la
compatibilidad de los mismos.
Para nuevos temas de investigación se recomienda aplicar analítica de datos para generar
nuevo conocimiento con la información existente (Morales Cardoso, 2019).
60
BIBLIOGRAFÍA
Abacus Consulting. (2018). http://abacus-consulting. Obtenido de http://abacus-
consulting.net/noticias/desarrollo-de-aplicaciones-para-web-tabletas-y-moviles-con-
angulars-js/
Álvarez Caules, C. (18 de Noviembre de 2016). arquitecturajava. Obtenido de
https://www.arquitecturajava.com/que-es-rest/
Bautista, J. (s.f.). PROGRAMACIÓN EXTREMA (XP). Obtenido de
http://ingenieriadesoftware.mex.tl/images/18149/PROGRAMACI%C3%93N%20EXTRE
MA.pdf
Blanco, C. (s.f.). Ingeniería del Software. Obtenido de
https://ocw.unican.es/pluginfile.php/1403/course/section/1792/is1_t06_Patrones.pdf
Calvo, D. (7 de aBRIL de 2018). DIEGO CALVO. Obtenido de
http://www.diegocalvo.es/metodologia-xp-programacion-extrema-metodologia-agil/
Castillo , O., Figueroa , D., & Sevilla , H. (s.f.). Obtenido de
http://programacionextrema.tripod.com/index.htm
Cerlalc. (Agosto de 2017). http://www.cerlalc.org/. Obtenido de http://www.cerlalc.org/wp-
content/uploads/publicaciones/olb/PUBLICACIONES_OLB_El_libro_en_cifras_11_310
817.pdf
Cosmina , I., Harrop , R., Schaefer, C., & Ho, C. (2017). Pro Spring 5 . USA.
dmsysperu. (2014). Principios REST. hispavista, 3.
Effy, O. (2008). ADMINISTRACIÓN DE LOS SISTEMAS DE INFORMACIÓN. Pennsylvania,
Pennsylvania: 5ta. edición.
61
Fontanet, B. (12 de Julio de 2016). Fundesem Business Topics. Obtenido de
https://www.fundesem.es/bt/publicacion-java-ee-y-el-desarrollo-web-un-enfoque-de-
aprendizaje
Franco, A. (s.f.). Metodología de SCRUM. Obtenido de
http://wiki.monagas.udo.edu.ve/index.php/Metodología%20s_SCRUM_y_XP
Garzas, J. (11 de Enero de 2012). blog Javier Garzas. Obtenido de
https://www.javiergarzas.com/2012/01/lean-software-development.html
kanban tool. (s.f.). Scrumban. Obtenido de https://kanbantool.com/es/scrumban-scrum-y-kanban
Laudon, K., & Laudon, J. (2012). Sistemas de información gerencial. Estado de México:
Decimosegunda.
López, A. (3 de Junio de 2019). OpenWebinars. Obtenido de https://openwebinars.net/blog/que-
es-postman/
Martín Campos, J. (6 de Julio de 2019). EcuRed. Obtenido de
https://www.ecured.cu/index.php?title=Programaci%C3%B3n_Extrema_(XP)&action=hi
story
Morales Cardoso, S. L. (Marzo de 2019). Metodología para procesos de Inteligencia de Negocios
con mejoras en la extracción de fuentes de datos, orientado a la toma de desiciones .
Alicante.
Obando Mosquera, D. A. (2015). Desarrollo de un sitio web bajo el patron de diseño, modelo,
vista, controlador, que permita la gestión del registro de voluntarios y donaciones para
dar soporte e información a la fundación construyamos un sueño. Latacunga, Cotopaxi,
Ecuador. Obtenido de http://boards5.melodysoft.com/UBV_INGS/metodologias-agiles-
de-desarrollo-43.html
62
Pater, L. (6 de Marzo de 2013). SlideShare. Obtenido de
https://es.slideshare.net/LisPater1/metodologias-agiles-xp
Perry, S. (11 de Mayo de 2017). Aspectos básicos de Spring Boot. Obtenido de
https://spring.io/projects/spring-boot
Robles, V. (5 de Agosto de 2019). victorroblesweb. Obtenido de
https://victorroblesweb.es/2017/08/05/que-es-angular-y-para-que-sirve/
Rosselló Villán, V. (15 de Marzo de 2019). https://www.iebschool.com/. Obtenido de
https://www.iebschool.com/blog/que-son-metodologias-agiles-agile-scrum/
Rosselló Villán, V. (15 de Marzo de 2019). IeBS. Obtenido de
https://www.iebschool.com/blog/que-son-metodologias-agiles-agile-scrum/
Rouse, M. (Enero de 2015). Search Datacenter. Obtenido de
https://searchdatacenter.techtarget.com/es/definicion/MySQL
Schiaffarino, A. (12 de Marzo de 2019). Infranetworking. Obtenido de
https://blog.infranetworking.com/modelo-cliente-servidor/
Seta, L. D. (13 de Noviembre de 2008). https://dosideas.com/. Obtenido de
https://dosideas.com/noticias/java/314-introduccion-a-los-servicios-web-restful
Solado Zuña, A. F. (Agosto de 2018). Análisis, diseño e implementación de un sistema con
notificaciones push para plataforma Android. Quito, Pichincha, Ecuador. Obtenido de
http://mialtoweb.es/definicion-de-aplicacion-web/
Sommerville, I. (2005). Ingeniería del software. Madrid: PEARSON EDUCACIÓN, S.A.
Sorsa, D. (20 de Julio de 2017). https://solvingadhoc.com/. Obtenido de
https://solvingadhoc.com/tdd-desarrollo-software-guiado-pruebas/
63
StudentPlace. (9 de Septiembre de 2018). https://studentplace98.blogspot.com/. Obtenido de
https://studentplace98.blogspot.com/2018/09/metodologia-de-desarrollo-de-
software.html
Tutorials Point. (s.f.). tutorialspoint SIMPLY EASY LEARNING. Obtenido de
https://www.tutorialspoint.com/spring/spring_discussion.htm
unADM. (24 de Agosto de 2015). Metodologías de desarrollo. Obtenido de
https://woodyweb.wordpress.com/2015/08/24/metodologias-de-desarrollo/
Vila Grau, J. L. (s.f.). Management Plaza. Obtenido de https://managementplaza.es/blog/sabes-
como-funciona-xp/
Vila Grau, J. L. (s.f.). MANAGEMENT PLAZA. Obtenido de
https://managementplaza.es/blog/sabes-como-funciona-xp/
64
ANEXOS
ANEXO A – MANUAL DE USUARIO
La pantalla de Login será el inicio de la interacción del usuario con el sistema, por lo que los
usuarios que ingresen al sistema deben estar registrados.
Ilustración 34. Ventana Login del Sistema.
Autor: Gustavo Coello.
65
En la Ilustración 35, podrá observar las opciones de menú que podrá visualizar el usuario,
dependiendo los roles que tenga asignado. el rol Administrador tiene acceso a todos los menús del
sistema, mientras que el rol estudiante solo podrá acceder a la opción “Biblioteca”.
Ilustración 35. Menú del Sistema.
Autor: Gustavo Coello.
66
Para el usuario Administrador, el menú “Administrador” abrirá la pantalla como muestra la
ilustración 36, en la cual podrá registrar, editar, eliminar y listar los libros que se encuentren en
el sistema.
Ilustración 36. Administrador del Repositorio Digital.
Autor: Gustavo Coello.
Al dar clic en el botón , el sistema abrirá el formulario de registro, como muestra la
ilustración 37, llenados todos los campos se habilitará el botón Aceptar.
67
Ilustración 37. Formulario de Registro de Libros.
Autor: Gustavo Coello.
En el menú “Subir Libro”, el sistema mostrará la pantalla como muestra la ilustración 38 en la
cual podrá listar, eliminar y subir los libros en formato PDF al sistema.
Ilustración 38. Pantalla upload de archivos PDF.
Autor: Gustavo Coello.
68
Al dar clic en el botón , el sistema desplegará la siguiente sección en la pantalla, como
muestra la ilustración 39.
Ilustración 39. Pantalla de verificación de archivos al Sistema.
Autor: Gustavo Coello.
El botón “Examinar” abrirá un cuadro de dialogo en el cual deberá buscar el archivo PDF a
subir al sistema, se debe tomar muy en cuenta el cuadro azul de indicaciones.
69
La ilustración 43 muestra la ventana luego de realizar el Login del sistema en el menú es la
opción “Biblioteca”, esta es la única pantalla que podrá visualizar el usuario estudiante.
Ilustración 40. Pantalla de inicio del Sistema – Lista de libros en la aplicación.
Autor: Gustavo Coello.
Al dar clic en el botón “Ver”, el sistema mostrará el libro asociado a esos datos, como muestra
la ilustración 44:
Ilustración 41. Visualización del libro en la pantalla.
Autor: Gustavo Coello.
70
ANEXO B – DOCUMENTO DE SATISFACCIÓN DEL CLIENTE