Metafora-Acatlan--caso-practico-del-patron-modelo-vista-controlador-para-aplicaciones-web

Vista previa del material en texto

Universidad Nacional Autónoma de México
Facultad de Estudios Superiores Acatlán
Metáfora Acatlán: Caso Práctico del
Patrón Modelo Vista Controlador para
Aplicaciones Web
T E S I N A
QUE PARA OBTENER EL TÍTULO DE:
Licenciado en Matemáticas Aplicadas y Computación
PRESENTA:
David Bryan Padilla Alemán
ASESOR:
M. en C. Sara Camacho Cancino
Naucalpan, Estado de México, Agosto 2018
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
Para poder seguir habrá un motivo
que no tenga que ver nada con el olvido
sin un pasado no diŕıa que he vivido.
“Un alto en el camino” - Jairo Varela
Agradecimientos
A Dios, por su gúıa, paciencia, consejos, por nunca abandonarme, brindarme la
fuerza y salud para poder concluir este trabajo.
A mis padres, por confiar y creer en mı́.
A mi hermano, Jordy, por su ayuda para concluir este trabajo, y a mi hermana,
Dania, por su motivación en cada etapa de la investigación.
A mi asesora, Sara Camacho, por su tiempo para llevar a cabo este trabajo, por
la enseñanza que desde el primer d́ıa me brindó.
A Maribel, por su apoyo incondicional d́ıa a d́ıa, a lo largo de este tiempo, gracias
de todo corazón.
A mi gran amigo, Julio Cruz, por su amistad incondicional.
A Minerva, Mike, Ángel, Elisa, Jorge, Daniel, Eualalio, amigos y compañeros de
trabajo, gracias por su apoyo y amistad.
A la Facultad de Estudios Superiores Acatlán, por todo por permitirme devolverle
un poco de lo mucho que me ha dado en mi trayectoria académica y profesional.
I
Resumen
Las aplicaciones Web son parte de una evolución de hardware y software, siendo
piezas centrales en el desarrollo de aplicaciones modernas. La implementación de una
arquitectura de software, apoya en la creación de aplicaciones grandes de forma efi-
ciente, estructurada y con capacidad de reutilización. La arquitectura forma parte del
proceso de diseño de software, que es parte del desarrollo de software que comprende:
requerimientos, diseño, implementación, pruebas y mantenimiento.
La investigación en esta área es relativamente reciente, sin embargo, existen un
gran número de aplicaciones que no cuentan con algún modelo arquitectónico bien
implementado; en ocasiones el poco tiempo para la creación de una aplicación juega
en contra y no se considera utilizar una arquitectura de software. Debido a esto, es-
te proyecto tiene como objetivo describir la importancia del uso de una arquitectura
de software; particularmente el patrón arquitectónico Modelo Vista Controlador pa-
ra la creación de aplicaciones Web, mostrado en la construcción de la aplicación Web
“Metáfora Acatlán”.
III
Índice general
Índice de figuras VII
Índice de tablas IX
1. Introducción 1
1.1. Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Aplicaciones Web 7
2.1. ¿Qué es la Web? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. ¿Qué es una aplicación Web? . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Tipos de aplicaciones web . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. ¿Por qué utilizar aplicaciones Web? . . . . . . . . . . . . . . . . 10
2.3. Arquitectura de una aplicación Web . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Arquitectura cliente - servidor . . . . . . . . . . . . . . . . . . . 11
2.4. Ingenieŕıa de software y la Web . . . . . . . . . . . . . . . . . . . . . . . 12
3. Ingenieŕıa de Software 15
3.1. ¿Qué es el software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1. Definición de software . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Tipos de software . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. ¿Qué es la ingenieŕıa de software? . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1. Definición de ingenieŕıa de software . . . . . . . . . . . . . . . . . 18
3.2.2. Retos de la ingenieŕıa de software . . . . . . . . . . . . . . . . . . 18
3.3. El proceso de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1. Modelos del proceso de software . . . . . . . . . . . . . . . . . . 20
3.3.2. Obtención y análisis de requerimientos . . . . . . . . . . . . . . . 21
3.3.3. Diseño del software . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.4. Desarrollo del software . . . . . . . . . . . . . . . . . . . . . . . . 24
V
ÍNDICE GENERAL
3.3.5. Pruebas del software . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.6. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.7. ¿Cómo enfrentarse al cambio? . . . . . . . . . . . . . . . . . . . . 27
4. Arquitectura de Software para Aplicaciones Web 29
4.1. ¿Qué es una arquitectura de software? . . . . . . . . . . . . . . . . . . . 29
4.1.1. Definición de arquitectura de software . . . . . . . . . . . . . . . 30
4.1.2. Caracteŕısticas de la arquitectura de software . . . . . . . . . . . 30
4.1.3. Importancia de la arquitectura de software . . . . . . . . . . . . 30
4.2. Del Estilo Arquitectónico al Patrón de Diseño . . . . . . . . . . . . . . . 32
4.2.1. Diseño Arquitectónico . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3. ¿Qué es un patrón? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1. Patrones de Arquitectura . . . . . . . . . . . . . . . . . . . . . . 33
4.3.2. Patrón Arquitectónico Modelo Vista Controlador . . . . . . . . . 34
4.3.3. ¿Cómo funciona? . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.4. El Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.5. La Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.6. El Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5. Implementación del Patrón Modelo Vista Controlador 39
5.1. Caso práctico: Metáfora Acatlán . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1. Identificación del problema . . . . . . . . . . . . . . . . . . . . . 39
5.2. Implementación del patrón MVC en Metáfora Acatlán . . . . . . . . . . 41
5.2.1. Propuesta de solución . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.2. Análisis de requerimientos . . . . . . . . . . . . . . . . . . . . . . 41
5.2.3. Diseño del software . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.4. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . . . 49
5.2.5. Construcción de la aplicación . . . . . . . . . . . . . . . . . . . . 54
5.2.6. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.7. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3. Análisis de resultados de la implementación . . . . . . . . . . . . . . . . 60
5.3.1. Resultados a nivel aplicativo . . . . . . . . . . . . . . . . . . . . 60
5.3.2. Resultados a nivel usuarios . . . . . . . . . . . . . . . . . . . . . 61
Bibliograf́ıa 65
Conclusiones 64VI
Índice de figuras
1.1. Planteamiento del problema. . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Caracteŕısticas de las aplicaciones Web. . . . . . . . . . . . . . . . . . . 10
2.2. Arquitectura cliente - servidor. . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. El software y las aplicaciones web. . . . . . . . . . . . . . . . . . . . . . 12
3.1. ¿Qué es el software?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Perspectiva general del proceso de software. . . . . . . . . . . . . . . . . 20
3.3. Ingenieŕıa de requerimientos. . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Componentes del diseño de software. . . . . . . . . . . . . . . . . . . . . 23
4.1. Ventajas del uso de la arquitectura de software. . . . . . . . . . . . . . . 31
4.2. Descripción general del funcionamiento del patrón MVC. . . . . . . . . . 35
4.3. Función general del modelo. . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4. Función general de la vista. (Tahuiton, 2011) . . . . . . . . . . . . . . . 37
4.5. Función general del controlador. . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Propuesta inicial de los requerimientos. . . . . . . . . . . . . . . . . . . 40
5.2. Diagrama de casos de uso del profesor. . . . . . . . . . . . . . . . . . . . 43
5.3. Diagrama de casos de uso del alumno. . . . . . . . . . . . . . . . . . . . 43
5.4. Diagrama de casos de uso del investigador. . . . . . . . . . . . . . . . . 44
5.5. Diagrama general del sistema Metáfora Acatlán. . . . . . . . . . . . . . 45
5.6. Diagrama de la arquitectura general de Metáfora Acatlán. . . . . . . . . 45
5.7. Diagrama entidad relación de la aplicación. . . . . . . . . . . . . . . . . 46
5.8. Cuestionario alumno. (https://www.metaforacatlan.net/student) . . . . 47
5.9. Cuestionario profesor. (https://www.metaforacatlan.net/proffesor) . . . 48
5.10. Acceso al sistema. (https://www.metaforacatlan.net/acceso) . . . . . . . 48
5.11. Módulo: Acceso al sistema. . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.12. Archivos del módulo, bajo el patrón MVC. . . . . . . . . . . . . . . . . . 50
5.13. Directorio del aplicativo Metáfora Acatlán. . . . . . . . . . . . . . . . . 51
5.14. Directorio MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.15. Directorio del controlador. . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.16. Directorio del modelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
VII
ÍNDICE DE FIGURAS
5.17. Directorio de las vistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.18. Primera fase del desarrollo del aplicativo. . . . . . . . . . . . . . . . . . 55
5.19. Diagrama de etapas de desarrollo del aplicativo. . . . . . . . . . . . . . . 55
5.20. Invitación enviada v́ıa correo electrónico. . . . . . . . . . . . . . . . . . . 57
5.21. Página de inicio. (https://www.metaforacatlan.net/) . . . . . . . . . . . 58
5.22. Acceso. (https://www.metaforacatlan.net/acceso) . . . . . . . . . . . . . 59
5.23. Vista de los datos recolectados. . . . . . . . . . . . . . . . . . . . . . . . 60
VIII
Índice de tablas
2.1. La web 1.0 y 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Definiciones de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Categoŕıas de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Clasificación de requerimientos. . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Niveles de diseño arquitectónico. . . . . . . . . . . . . . . . . . . . . . . 33
5.1. Contabilización de las pruebas. . . . . . . . . . . . . . . . . . . . . . . . 56
5.2. Comentarios obtenidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3. Total usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.4. Clasificación por Licenciaturas. . . . . . . . . . . . . . . . . . . . . . . . 61
IX
Caṕıtulo 1
Introducción
“En la solución a cualquier problema hay un grano de descubrimiento.”
Louis Monier.
1.1. Presentación
En la última década la ingenieŕıa de software ha tenido un crecimiento importante,
esto en consecuencia del gran número de aplicaciones que han sido desarrolladas para
ser utilizadas a través de Internet, denominadas “Aplicaciones Web”; estas con dife-
rentes objetivos en los que destacan: el procesamiento de datos, gráficos, multimedia,
entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y per-
sonales además de las redes sociales o acceso a bases de datos externas.
Estas aplicaciones han sido una herramienta clave para el desarrollo de software ya
que son una pieza fundamental en la administración de grandes cantidades de datos,
y debido a que Internet es un mercado muy demandante, d́ıa a d́ıa se encuentra con
la necesidad de construir aplicaciones más complejas en un tiempo reducido y que
cuenten con la funcionalidad correcta. Este punto es fundamental ya que es el lugar en
donde el desarrollo de software se enfrenta con diferentes factores que generan que el
proceso obtenga una complejidad mayor, principalmente en la etapa de diseño, siendo
esta etapa el lugar donde la arquitectura de software juega un papel importante para
saber la forma en la que estará conformada la aplicación además de obtener mayor
control durante la creación y mantenimiento de la misma.
1
1. INTRODUCCIÓN
Esta investigación al realizarse, ofrecerá un panorama general de los elementos ne-
cesarios para la creación de una aplicación Web, apoyándose en el proceso de desarrollo
de software e implementando el patrón arquitectónico Modelo Vista Controlador. A
su vez esta investigación contará con el caso práctico “Metáfora Acatlán”, siendo esta
una aplicación, que será una herramienta de apoyo que busque agilizar la obtención
de información para una investigación del doctorado de pedagoǵıa perteneciente a la
Facultad de Estudios Superiores Acatlán.
En el primer caṕıtulo se define el planteamiento del problema, mismo que llevó a
desarrollar esta investigación, también se definen los objetivos particulares y el objetivo
general, para poder determinar una solución al problema planteado.
En el caṕıtulo dos se abordarán de manera general las definiciones relacionadas con
las aplicaciones web, los diferentes tipos de aplicaciones y una breve explicación de su
arquitectura.
En el tercer caṕıtulo se mostrarán los conceptos que corresponden a la ingenieŕıa
de software mostrando cada una de las etapas, colocando énfasis en los procesos de
análisis de requerimientos y diseño.
En el caṕıtulo cuatro se explica de manera breve la definición de arquitectura de
software, aśı como también se explica el patrón arquitectónico Modelo Vista Controla-
dor, explicando cada uno de sus componentes.
El caso práctico es en donde se identifican los elementos para implementar el patrón
arquitectónico Modelo Vista Controlador, explicándolo en la creación de la aplicación
“Metáfora Acatlán”, visto a detalle en el caṕıtulo número cinco.
2
1.2 Objetivo
1.2. Objetivo
Este trabajo tiene como principal objetivo describir la importancia de la utilización
de una arquitectura de software; particularmente el patrón arquitectónico Modelo Vista
Controlador, identificando el rol que tiene dentro del proceso de desarrollo de software
mostrado en la creación de la aplicación Web ”Metáfora Acatlán”, apoyándose de los
siguientes objetivos particulares:
Conocer las aplicaciones Web, aśı como, la importancia que estas tienen en la
actualidad.
Analizar el impacto de la implementación de un patrón arquitectónico dentro
de la ingenieŕıa de software.
Describir la arquitectura modelo Vista Controlador para aplicaciones Web.
Implementar la arquitectura de software en la creación de la aplicación “Metáfo-
ra Acatlán” basada en tecnoloǵıa Web tomando como base el patrón Modelo Vista
Controlador.
3
1. INTRODUCCIÓN
1.3. MotivaciónEl desarrollo de aplicaciones Web ha crecido de forma notable abarcando áreas
como: comercio electrónico, redes sociales, banca en ĺınea, entretenimiento, etc. La ma-
yoŕıa de los grandes sistemas de información que antes se utilizaban de manera local
han tenido que ser trasladados a tecnoloǵıa Web como parte de su evolución.
La arquitectura forma parte del proceso de diseño de software que a su vez forma
parte del proceso de desarrollo de software. Cada una de las etapas es importante, sin
embargo la etapa de obtención de requerimientos y diseño son fundamentales para que
el software pueda contar con una funcionalidad óptima. La alternativa de utilizar una
arquitectura de software brinda grandes ventajas en las que inicialmente destacan:
1. Mejor manejo de la complejidad de los requerimientos.
2. Reducción en el tiempo de desarrollo.
3. Mantenibilidad y escalabilidad a través del tiempo.
De lo anterior nace la motivación principal para la elaboración de esta investiga-
ción, el exponer con detalle el patrón arquitectónico Modelo Vista Controlador para la
creación de aplicaciones Web, con la finalidad de que el lector conozca sus ventajas y
desventajas de utilizar o no el patrón arquitectónico en el ciclo de vida del desarrollo
de software.
4
1.4 Planteamiento del problema
1.4. Planteamiento del problema
El proceso de diseño de software es una parte fundamental ya que muestra el pa-
norama general del software siendo la base para la etapa de desarrollo. Sin embargo, a
pesar de los recientes avances en la tecnoloǵıa, y de los lenguajes orientados a objetos,
los sistemas de software grandes, son muy complejos de diseñar, debido a que en algu-
nos casos no se cuenta con modelos arquitecturales que ayuden en su construcción.
Este último punto es clave ya que si el diseño de cada uno de los componentes
del software no se analizó de manera correcta, la evolución del software será cada
vez más costosa en tiempo y esfuerzo. En consecuencia la arquitectura de software
con el patrón Modelo Vista Controlador propone una separación de cada unos de los
componentes que conforman la aplicación, con esto se busca facilitar el rendimiento,
seguridad, escalabilidad y mantenibilidad.
Figura 1.1: Planteamiento del problema.
5
1. INTRODUCCIÓN
1.5. Contribución
La principal contribución de este trabajo es la identificación de los componentes de
una aplicación Web, fundamentalmente el autor invita a poner énfasis en la etapa de
diseño del proceso de desarrollo de software, para evaluar el uso de una arquitectura
de software para realizar un diseño escalable en el menor tiempo posible y con buena
calidad.
En consecuencia el patrón Modelo Vista Controlador es una de las arquitecturas más
utilizados para la creación de aplicaciones Web. El caso práctico “Metáfora Acatlán”,
explicará la implementación del patrón, basándose en los conceptos teóricos y la expe-
riencia del autor en esta área.
6
Caṕıtulo 2
Aplicaciones Web
“Cuando veamos cualquier tipo de estabilización, la web se habrá convertido en algo
completamente diferente.”
Louis Monier.
En los últimos años Internet ha tenido un crecimiento importante tanto en infra-
estructura como en la creación de aplicaciones globales. Más de la mitad del total de
las aplicaciones de la industria de software son utilizadas por medio de Internet, estl
indica, que estas aplicaciones siguen ganando popularidad en un mercado muy com-
petitivo (Tahuiton, 2011). En este caṕıtulo se describe qué es una aplicación Web, su
arquitectura general y campo en cual son mayormente utilizadas.
2.1. ¿Qué es la Web?
Web se refiere a la red de información que existe en Internet. Se identifica como
una red o telaraña ya que internet es una compleja red de servidores que almacenan
distintas aplicaciones Web (Tahuiton, 2011).
Definición: La Web es un subconjunto de Internet que consiste en páginas a las que
se puede acceder usando un navegador. Está tecnoloǵıa se basa en buscadores y el pro-
tocolo de transporte de hipertexto (hypertext transport protocol (http)). La mayoŕıa
de los documentos de la Web se crean utilizando lenguaje HTML (hypertext markup
language). Hoy en d́ıa existen millones de servidores y todos se conectan entre śı, ge-
nerando como resultado un rápido crecimiento (Firtman, 2012).
7
2. APLICACIONES WEB
2.1.1. Historia
La World Wide Web, como se le conoce en el presente, nació a principios de la
década de los noventas, y en sus inicios sólo ofreció un contenido textual agrupado
en los famosos hiperv́ınculos o links. En esa época se habló mucho del nacimiento del
hipertexto como concepto de la navegación por la Web.
El principal creador de la World Wide Web fue Tim Berners-Lee, con la propuesta
de crear un sistema para compartir información, Berners-Lee puso en marcha el primer
servidor Web y la primera página Web del mundo en agosto de 1991 (Pressman, 2010).
No obstante, en la actualidad, estamos lejos de aquella época; basta con visitar
cualquiera de nuestros sitios web favoritos para darnos cuenta que los sitios Web ya no
son sólo texto e hiperv́ınculos, ahora son imágenes, animaciones, ventanas desplegables,
redes sociales, documentos en ĺınea, videojuegos etc.
La Web 1.0 hasta hace unos años era la única que conoćıamos y que, si bien hab́ıa
evolucionado desde 1995 durante 10 años, segúıa utilizando la misma base, incluso en
términos económicos. La Web 2.0 surge como consecuencia del avance tecnológico tan-
to de software como hardware que permiten que las aplicaciones puedan ser más que
simplemente texto como lo presentaba la Web 1.0 (Firtman, 2012).
En la tabla 2.1 se realiza una comparación entre la Web 1.0 y la 2.0, para una mejor
comprensión de las diferencias entre las mismas (Firtman, 2012) .
Tabla 2.1: La web 1.0 y 2.0
Concepto ¿Cómo es la Web 1.0? cómo es en la Web 2.0?
Distribución de la in-
formación
Centralizada en un sitio web a
través de interrelaciones
Dispersa en miles de sitios
Tecnoloǵıa base HTML 4.0 HTML5 Y CSS3
Servicios Web Lleva años de trabajo finali-
zarlos y lanzarlos
Se realizan entregas periódi-
cas lo más pronto posible
Interacción con otros
sitios
No es posible Los sitios ofrecen APIs abier-
tas para que otros se conecten
Ahora estamos claramente inmersos en la etapa de la Web 3.0, donde se busca ayu-
dar a los usuarios a encontrar la información que necesita. Se trata de un cambio de
8
2.2 ¿Qué es una aplicación Web?
concepción que implica también una evolución tecnológica, aplicando nuevos lenguajes,
nuevas técnicas de búsqueda y de almacenamiento (Iruela, 2015).
El ejemplo claro de la evolución de la Web es el motor de búsqueda de Google, que
cuenta con un gran número de servicios que principalmente brindan ayuda para que el
usuario tenga rapidez al obtener información por medio de Internet (Google, 2018).
2.2. ¿Qué es una aplicación Web?
Las aplicaciones Web son aquellas que se ejecutan por medio de Internet, es decir
que los datos y los archivos en los que se trabaja son procesados y almacenados dentro
de un servidor espećıfico que es accedido a través de la Web. (Tahuiton, 2011).
El concepto de aplicaciones Web está relacionado con el almacenamiento en la nube.
Toda la información se guarda de manera permanente en cientos de servidores ubicados
en diferentes partes del mundo. Esto permite tener el acceso a un mundo de aplicaciones
por medio de una sola interfaz que es el navegador (Tahuiton, 2011).
2.2.1. Tipos de aplicaciones web
Las aplicaciones Web cuentan con excelentes ventajas, como se ha mencionado en
el punto 2.2. Para el desarrollo de este trabajo se han clasificado a estas aplicaciones
en cuatro grandes bloques, que se describen a continuación: (Pressman, 2010)
1. Estática. Es el tipo de aplicación que muestra poca información y está pensada
para no generar ó incluir nuevos contenidos. La mayoŕıa de estas se encuentran
desarrolladas enHTML y CSS; pueden incluir v́ıdeos, banners y GIFS. Algunos
ejemplos podŕıan ser un curriculum digital o bien la de una empresa.
2. Dinámicas. Presentan una mayor complejidad a nivel técnico que la aplicación
Web estática. Utilizan una base de datos para cargar la información y los conteni-
dos se van actualizando cada vez que el usuario utiliza la aplicación. Regularmente
cuentan con un panel de administración donde se crean y actualizan los conteni-
dos. Existen muchos lenguajes de programación para aplicaciones web dinámicas
como PHP, JAVA siendo estos los más populares.
3. E-commerce. Es el tipo de aplicación Web pensada para tiendas en ĺınea. El
desarrollo de estas aplicaciones es más complejo al tener que crear pasarelas de
pago para tarjetas de crédito, además de sincronizarse con la gestión de stocks y
loǵıstica. Básicamente este tipo de aplicaciones realizan las operaciones de altas
9
2. APLICACIONES WEB
bajas y cambios sobre los productos que se ofrecen. Un ejemplo que abarca las
caracteŕısticas antes mencionadas es la tienda en ĺınea Amazon.
4. Gestores de Contenidos. Este tipo de aplicaciones son ideales para aquellas
personas o empresas que desean actualizar su contenido constantemente. Tienen
un gestor de contenidos (CMS), a través del cual el administrador y los edito-
res pueden ir añadiendo los contenidos realizando los cambios y actualizaciones.
Muchas empresas han optado por este tipo de aplicación Web por la facilidad de
publicar contenidos. Es muy popular su uso en diarios digitales, blogs (personales
o corporativos), medios de comunicación entre otros.
Algunos ejemplos de CMS son:
a) WordPress
b) Joomla
c) Drupal
2.2.2. ¿Por qué utilizar aplicaciones Web?
Las aplicaciones Web utilizan como medio de almacenamiento servidores Web, con
esto se obtienen grandes ventajas que han impulsado y mantenido que estas aplicacio-
nes sigan siendo utilizadas. En la figura 2.1 se muestran las caracteŕısticas destacadas.
Figura 2.1: Caracteŕısticas de las aplicaciones Web.
10
2.3 Arquitectura de una aplicación Web
2.3. Arquitectura de una aplicación Web
Las aplicaciones Web están conformadas por un servidor Web, y es el cliente que
interactuan con el servidor por medio de Internet. La arquitectura de un sitio web tiene
tres componentes principales:
Servidor Web
Conexión de Red
Uno o más clientes
2.3.1. Arquitectura cliente - servidor
Las aplicaciones Web están basadas en la arquitectura Cliente - Servidor, que cuen-
tan con dos elementos principales, los servidores, quienes almacenan y gestionan la
aplicación y los clientes que tiene como interfaz a las páginas Web, por medio de un na-
vegador. En la figura 2.2, se muestran los componentes principales de esta arquitectura.
Figura 2.2: Arquitectura cliente - servidor.
11
2. APLICACIONES WEB
La colección de páginas Web son en su mayoŕıa dinámicas creadas con un lenguaje
de programación que el servidor Web puede interpretar como: PHP, JAVA, entre otros.
Estas páginas en la mayoŕıa de las casos se encuentran agrupadas lógicamente para dar
un servicio al usuario. Esta división lógica será vista con mayor detalle en el caṕıtulo
4, donde, se podrá revisar el impacto de una división lógica para las aplicaciones.
2.4. Ingenieŕıa de software y la Web
Antes del gran impacto de la World Wide Web, la ingenieŕıa de software se encon-
traba enfocada a realizar sistemas de software que eran ejecutados en computadoras
locales, solo accesibles desde el interior de una organización, es decir, en un lugar es-
pećıfico.
En la figura 2.3, se muestra un comparativo de los sistemas locales y los basados en
tecnoloǵıa Web.
Figura 2.3: El software y las aplicaciones web.
12
2.4 Ingenieŕıa de software y la Web
Este avance hizo menos costosas las actualizaciones del software, pues no habŕıa
necesidad de instalarlo en cada una de las computadoras de los usuarios. En conse-
cuencia, muchos negocios se mudaron a la interacción basada en la web, el software no
funcionaŕıa usualmente en computadoras locales, si no en servidores Web a los que se
accede a través de Internet.
Ahora el software se encuentra distribuido, en ocasiones a lo largo del mundo. Es-
tos cambios conducieron a modificaciones en las formas en que los sistemas basados
en Web se adaptan a la ingenieŕıa de software, (Sommerville, 2011) destaca tres ideas
fundamentales de la ingenieŕıa de software para las aplicaciones Web:
1. La reutilización del software se ha convertido en el enfoque dominante para
construir sistemas basados en la Web. Cuando se construyen tales sistemas uno
piensa en cómo ensamblarlos a partir de componentes y sistemas de software
preexistentes.
2. Entrega progresiva. Ahora se sabe que no es práctico especificar por adelantado
todos los requerimientos para tales sistemas. Los sistemas basados en la Web
deben desarrollarse y entregarse de manera progresiva.
3. Las interfaces. de usuario están restringidas por las capacidades de los navega-
dores Web. Estas aplicaciones con frecuencia sufren un mayor número de cambios
o actualizaciones que las interfaces espećıficamente diseñadas para sistemas para
equipos de cómputo locales.
13
Caṕıtulo 3
Ingenieŕıa de Software
“Más que una disciplina o cuerpo de conocimientos, ingenieŕıa es un verbo, una
palabra de acción, una forma de abordar un problema.”
Scott Whitmir.
En este caṕıtulo se presentan algunos de los conceptos relacionados a la ingenieŕıa
de software, donde principalmente se busca enfatizar la necesidad de comprender los
requerimientos y realizar un diseño del software, además de responder a las siguientes
preguntas:
1. ¿Qué es el software?
2. ¿Qué es la ingenieŕıa de software?
3. ¿Qué es un proceso del software?
Las respuestas a las preguntas anteriores son fundamentales para conocer las carac-
teŕısticas y funciones del área de desarrollo de software.
3.1. ¿Qué es el software?
Es común escuchar la palabra software dentro de la vida cotidiana ya se distribuye
el producto más importante de nuestro tiempo la información, transforma los datos de
modo que puedan ser más fáciles y útiles.
En la figura 3.1 se interpreta el surgimientos de un sistema software, partiendo de
procesos realizados de manera manual.
15
3. INGENIERÍA DE SOFTWARE
Figura 3.1: ¿Qué es el software?.
3.1.1. Definición de software
A través del tiempo y de la definición de software se ha ido enriqueciendo por dife-
rentes autores en la tabla 3.1 se citan las referencias más destacadas.
16
3.1 ¿Qué es el software?
Tabla 3.1: Definiciones de software
Definición Autor
El software de computadora es el producto que construyen
los ingenieros de software para poder apoyar en la automa-
tización de un proceso.
(Pressman, 2010)
Programas de computadora y la documentación asociada.
Los productos de software se pueden desarrollar para un
cliente en particular o para un mercado general.
(Sommerville, 2011)
Los autores de la tabla 3.1, mencionan que el software ayuda a la automatización
de procesos, en consecuencia, se puede decir, que el software es un programa que se
ejecuta en un equipo de cómputo, mismo que apoya en la realización de una o varias
actividades especificas.
3.1.2. Tipos de software
Los sistemas de computadora han sido catalogados por la tecnoloǵıa que utilizan
y dependiendo el área u objetivo para el que son creados (Pressman, 2010). Para esta
investigación se ha realizado una acotación en la clasificación, enfocada en aquellos
sistemas que de alguna manera manera se relacionan con las aplicaciones Web. En la
tabla 3.2 se describen las categoŕıas.
Tabla 3.2: Categoŕıas de software
Categoŕıa Descripción Ejemplos
Software de Sistemas Escritos para dar servicio a
otros programas.
Sistemas Operativos: Win-
dows, Linux, Android etc.
Aplicaciones Web Software centrado en redes
agrupa una amplia gama de
aplicaciones.
Redes sociales, procesamiento
de datos, aplicacionesde ne-
gocio.
Aplicaciones Móviles Software creado para ser utili-
zado en dispositivos móviles.
Financieras, entretenimiento
redes sociales.
17
3. INGENIERÍA DE SOFTWARE
3.2. ¿Qué es la ingenieŕıa de software?
Con el gran crecimiento del software surge la ingenieŕıa de software, con el objetivo
de apoyar con el análisis, creación y mantenimiento, no importando la categoŕıa, la
ingenieŕıa puede aplicarse sin ningún problema.
Un software no es algo que se fabrica a partir de una materia prima, ni se ensambla
a partir de piezas pequeñas. (Pressman, 2010) menciona que el software presenta esta
caracteŕıstica especial en comparación con otros tipos de productos, es decir, no se crea
en un proceso t́ıpico, si no que se desarrolla por medio de un proceso de ingenieŕıa
espećıfica.
3.2.1. Definición de ingenieŕıa de software
La ingenieŕıa de software es la disciplina que se ocupa de todos los aspectos del desa-
rrollo de software, incluyendo las actividades de ingenieŕıa de requerimientos modelos de
procesos y técnicas de procesos, modelos y técnicas de estimación (Sommerville, 2011).
Esta cuenta con un conjunto de actividades y resultados asociados para obtener un
producto de software, cada una cuenta con procesos espećıficos para poder obtener el
aplicativo final.
3.2.2. Retos de la ingenieŕıa de software
La ingenieŕıa de software presenta tres principales retos que a consecuencia de la
evolución y demanda que se tiene para la creación y mantenimiento del software.
1. Escalabilidad: Cada vez más, se requiere que el software funcione de manera
modular o distribuida, para que pueda ser integrado con otros aplicativos de
manera sencilla y práctica. El reto de la escalabilidad es crear softwares capaces
de integrarse con otros con la menor complejidad posible.
2. Entrega: Las etapas de la ingenieŕıa de software necesitan tiempo para producir
un software con calidad, sin embargo hoy d́ıa se debe de tener una gran capacidad
de respuesta y evolucionar con rapidez. El reto de la entrega es reducir los tiempos
de desarrollo sin comprometer la calidad del software.
3. Calidad: En la mayoŕıa de los casos el software absorbe procesos cŕıticos. El reto
de la calidad es estar presente en cada uno de los procesos del software con la
finalidad de transmitir confianza al usuario.
18
3.3 El proceso de software
3.3. El proceso de software
La creación de software se construye por medio de un proceso de desarrollo. A
través del tiempo, se ha ido adaptando a las caracteŕısticas actuales de la industria del
software. El proceso de software es complejo y depende de la toma de las decisiones
de los involucrados, cada software cuenta con caracteŕısticas únicas, por esta razón no
existe un proceso ideal que se pueda aplicar para todos los casos.
En la figura 3.2 se muestran las fases fundamentales que se proponen para el desa-
rrollo de software.
19
3. INGENIERÍA DE SOFTWARE
Figura 3.2: Perspectiva general del proceso de software.
La estructura de este proceso establece el fundamento para la creación del software,
por medio de la identificación de tareas que apoyan en el desarrollo, sin importar el
nivel de la complejidad.
3.3.1. Modelos del proceso de software
Como se ha mencionado en los puntos anteriores, la ingenieŕıa de software cuenta
con una serie de pasos, para llevar a cabo el proceso. Los modelos son descripciones
definitivas, más bien, son abstracciones de los procesos que se pueden utilizar para ex-
plicar diferentes enfoques para el desarrollo de software. Puede pensarse en ellos como
marcos de trabajo, que pueden ser extendidos y adaptados para crear procesos más
espećıficos de la ingenieŕıa de software.
(Sommerville, 2011), menciona tres principales modelos que son los más recurrentes
en la práctica de la ingenieŕıa de software.
1. El modelo de cascada. Considera las actividades fundamentales del proceso de
especificación de desarrollo, validación y evolución, y los representa como fase
separadas del proceso, tales como, la especificación de requerimientos, el diseño
de software, la implementación, las pruebas, etc.
2. Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificación,
desarrollo y validación. Un sistema inicial se desarrolló rápidamente a partir de
especificaciones abstractas. Este se refina basándose en peticiones del cliente para
producir un sistema que cumpla sus necesidades.
20
3.3 El proceso de software
3. Ingenieŕıa de software basada en componentes. Permite reutilizar piezas de código
preelaborado que permiten realizar diversas tareas, conllevando a diversos benefi-
cios como: las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor
retorno sobre la inversión.(Casal, 2017).
3.3.2. Obtención y análisis de requerimientos
El crecimiento de la demanda de software viene acompañado de la complejidad, que
en la mayoŕıa de los casos es dif́ıcil de identificar, para esto, el proceso de obtención y
el análisis de requerimientos apoya para la comprensión y definición de servicios que se
necesitan. En esta etapa también se identifican y definen las restricciones del funciona-
miento y desarrollo, a este proceso se le conoce como la ingenieŕıa de requerimientos.
Es la etapa con mayor interacción con el usuario, se lleva a cabo entre el analista
de requerimientos y el usuario que solicita la creación del software, es importante que
el analista cuestione y clasifique cada uno de los requerimientos. Además de tener el
mayor contexto posible sobre el negocio, esto traerá como consecuencia que sea más
rápida la interacción con el usuario y que los requerimientos sean comprendidos de me-
jor manera. En la figura 3.3, se representa la interacción entre el usuario y el analista
de requerimientos.
Algunos de los problemas que surgen durante el proceso de obtención y análisis de
requerimientos son resultado de no hacer una clara separación de estos.
En la tabla 3.3, se propone una clasificación de requerimientos para una mejor iden-
tificación de los mismos (Sommerville, 2011).
Tabla 3.3: Clasificación de requerimientos.
Requerimientos
funcionales
Definen las funciones que el sistema será capaz de realizar.
Describen las transformaciones que el sistema realizará en-
trada y salida de datos.
Requerimientos
no funcionales
Son caracteŕısticas que imponen restricciones al sistema, co-
mo por ejemplo, diseño de interfaces o estándares de calidad.
Son cualidades que el software debe de tener
Posterior a la obtención de los requerimientos se realiza el análisis de requerimientos
que implica refinar, y examinar la información obtenida, para asegurar que es claro lo
21
3. INGENIERÍA DE SOFTWARE
Figura 3.3: Ingenieŕıa de requerimientos.
que se solicitó. Con este análisis principalmente se obtiene:
Visión y alcance del software
Flujos de trabajo
Identificación de usuarios
Es importante mencionar que en la mayoŕıa de los casos algunos requerimientos no
son detectados a tiempo, para esto en la sección 3.3.7, se proponen una serie de pasos
para enfrentarse al cambio o actualizaciones.
22
3.3 El proceso de software
3.3.3. Diseño del software
Terminada la etapa de obtención y análisis de requerimientos, inicia la etapa de
diseño, aqúı se describe la estructura, los componentes, los conectores, las interfaces y
los algoritmos utilizados en el software que se desea implementar.
La etapa de diseño cuenta con varias fases, tomando como referencia inicial el lis-
tado de los requerimientos. En la figura 3.4 se muestran los principales elementos para
el diseño del software.
Figura 3.4: Componentes del diseño de software.
Diseño de software: es una actividad que permite estructurar de forma general al
sistema, el objetivo es tener una visión clara del sistema a construir. El resultado
de esta fase es el diseño es la arquitectura del sistema.
23
3. INGENIERÍA DE SOFTWARE
Diseño Arquitectónico: es una tareaque necesita estudiar el flujo de la informa-
ción para analizar la comunicación entre los distintos componentes del sistema.
Como resultado de esta actividad se tiene el documento de especificación de las
interfaces.
La especificación de componentes, permite abstraer una funcionalidad para poder
ser reutilizado. El resultado de esta actividad es el documento de especificaciones
de componentes.
El diseño de las estructuras de datos, es la etapa que detalla cada una de las clases
y objetos que son necesarios para construir el sistema.
El diseño de algoritmos permite identificar si se necesitará implementar algún
algoritmo especifico o bien crear uno para alguna funcionalidad especifica del
software.
(Taylor, 2007) ha considerado el diseño como una actividad importante que debeŕıa
ser el centro de todo el desarrollo de software. A este enfoque se le conoce como desarro-
llo centrado en la arquitectura. Esto se debe a que la arquitectura es la representación
formal de todo el sistema y puede usarse para localizar errores existentes en el software
y tener una mejora continua.
En esta fase del proceso de desarrollo de software, se involucra la persona con el
perfil de arquitecto de software. Aqúı el arquitecto debe hacer uso de todas sus habi-
lidades técnicas con el fin de establecer una solución técnica pertinente que satisfaga,
en la medida de lo posible, los requerimientos que influyen en el diseño arquitectónico.
Es importante mencionar que el numero de personas con diferentes perfiles invo-
lucradas en el proyecto dependerán plenamente del tiempo y del presupuesto para el
mismo.
3.3.4. Desarrollo del software
En esta etapa cada uno de los elementos planteados en el diseño de la arquitectura
se conectará para dar paso a la creación del software. Los encargados de esta etapa
son los programadores, estos seleccionaran el lenguaje de programación tomando como
referencia dos criterios: la experiencia de los programadores en un lenguaje especifico y
las caracteŕısticas del proyecto para poder utilizar debidamente las herramientas para
desarrollar el sistema de software.
El avance o retroceso de la etapa de desarrollo será reflejado en la funcionalidad
que está siendo agregada al software, la misma dependerá de la experiencia del equi-
po de desarrollo y principalmente en la manera en que se planea la creación del software.
24
3.3 El proceso de software
En el desarrollo de software, una metodoloǵıa hace cierto énfasis al entorno en el
cuál se plantea y estructura el desarrollo de un sistema. Existen una gran cantidad de
metodoloǵıas que se han utilizado desde tiempos atrás y que con el paso del tiempo
han ido evolucionando. Esto se debe principalmente a que no todos los sistemas, son
compatibles con todas las metodoloǵıas, pues el ciclo de vida del software puede ser
variable. Por esta razón, es importante que dependiendo del tipo de software que se
vaya a desarrollar, se identifique la metodoloǵıa idónea.
Cada metodoloǵıa de desarrollo, tiene un enfoque para la planeación y desarrollo
de software. Actualmente se dividen en dos grandes bloques:
1. Metodoloǵıas tradicionales. Son aquellas en las que no podrás avanzar a la si-
guiente fase, si la anterior no se encuentra totalmente terminada, pues no tiene
porque haber regreso a una fase anterior. Algunas metdologias son: Modelo Es-
piral, Modelo Incremental o Iterativo y Creciente, Metodoloǵıa en cascada, etc.
2. Metodoloǵıas Ágiles. Consisten principalmente en trabajar con la menor docu-
mentación posibles, se basan en la entrega rápida e incremental del software.
Algunos ejemplos son: SCRUM, Programación extrema o XP, Agile Unified Pro-
ces, etc.
Básicamente la principal diferencia entre estás dos metodoloǵıas es el tiempo en la
que el software es entregado, las metodoloǵıas tradicionales entregan el software una
vez terminado y las metodoloǵıas ágiles entregan el software poco a poco, esto no nece-
sariamente implica que las metodoloǵıas ágiles no utilicen todas las fases del software,
si no que tratan de hacerlo lo más rápido posible.
Ninguna de las metodoloǵıas es correcta o incorrecta, la decisión por inclinarse por
alguna de ellas dependerá de las caracteŕısticas del proyecto y las del equipo que está
involucrado en el ciclo de vida del software.
3.3.5. Pruebas del software
Las pruebas o validación del software son la base que permite analizar el compor-
tamiento, teniendo como punto de referencia la obtención y análisis de requerimientos.
Comprenden el conjunto de actividades que se realizan para identificar posibles fallos
de funcionamiento, configuración o usabilidad de un programa o aplicación, por medio
de pruebas sobre el comportamiento del mismo (Rodŕıguez, 2015).
Actualmente el proceso de pruebas del software, es considerado toda una área den-
tro de las empresas o instituciones dedicadas a desarrollar software, sin embargo, se
mencionan de manera acotada los tipos de pruebas de software en función de sus obje-
tivos:
25
3. INGENIERÍA DE SOFTWARE
1. Pruebas de software funcionales. Estas pruebas se definen a partir de funcio-
nes o caracteŕısticas del sistema, subsistema o componente de software descrito
en los requisitos.
2. Pruebas software no funcionales. Incluyen las pruebas de: rendimiento, carga,
estrés, usabilidad, mantenibilidad, fiabilidad o portabilidad, entre otras. Por tanto
se centran en caracteŕısticas del software que establecen trabaja el sistema.
El periodo de pruebas es la fase en la que existe una estrecha relación entre el equipo
de desarrollo y el equipo de pruebas, estos últimos al detectar algún error, deberán de
reportar a estos las caracteŕısticas del error y el camino para lograr replicarlo. La etapa
de pruebas concluye una vez que los encargados de las mismas, validaron el correcto
funcionamiento del software.
3.3.6. Implementación
Una vez que se ha terminado la etapa de desarrollo y que se han realizado las prue-
bas necesarias para verificar que el software cumple con las especificaciones , se inicia
la etapa de implementación. Esta consiste en crear las condiciones necesarias para que
el software sea instalado y que pueda funcionar sin ningún problema.
La determinación de poner o no en marcha es una decisión que se toma en conjunto
con el cliente. Una propuesta para poder ejecutar la implementación es que se le mues-
tre el software al cliente, destacando los requerimientos principales, es importante que
se acoten las observaciones, es decir, si surgen nuevos requerimientos se puede hablar
de una siguiente versión del software y aśı una vez más se inicia con el proceso de
desarrollo de software.
Para la implementación es necesario cumplir requisitos tanto f́ısicos (equipos de
cómputo) como de software (servidores de aplicaciones y manejadores de base de da-
tos) que permitan un buen funcionamiento. Esta etapa es igual de importante ya que
para la puesta en marcha del software es necesario que todos los requerimientos se
cumplan totalmente. Una vez que el software ha sido instalado se realizan pruebas para
verificar que su comportamiento es correcto.
Generalmente en la etapa de implementación cuenta con la participación princi-
palmente de dos personas. La primera es la que provee los requerimientos f́ısicos de
la aplicación, y otra que pondrá en marcha el software (despliegue), ambos tendrán el
conocimiento para poner en marcha el software en caso de alguna contingencia.
26
3.3 El proceso de software
3.3.7. ¿Cómo enfrentarse al cambio?
El software cambia en cada fin del proceso de desarrollo, o bien, durante la creación
del mismo, para esto es importante controlar los cambios, es decir, hay que aceptar
que estas modificaciones estarán presentes. La gestión de cambios se presenta como
una herramienta esencial para que el proceso de desarrollo no sea altamente afectado,
principalmente en los tiempos de entrega.
Supongamos que el software se encuentra en la fase de desarrolloy se solicita un
cambio o un nuevo requerimiento, nos enfrentamos a la siguiente pregunta ¿Qué hare-
mos? Para poder responder se proponen cuatro pasos para llevar a cabo la gestión de
cambios:
1. Evaluar el impacto. La primera actividad a realizar tras recibir la solicitud de
un cambio o nuevo requerimiento es valorar qué tanto impacto generará en el
proceso que se está llevando o bien que ya se llevó a cabo. Para esto se revisarán
una vez más los requerimientos y los diseños del software para verificar en qué
parte será implementado y qué consecuencias tendrá.
2. Aceptación del cambio. Una vez analizando el impacto del cambio, se debe
tomar una decisión. Si se acepta el cambio basado en la evaluación, se conti-
nuará con la actividad de implementar el cambio. En caso contrario, se deberá de
negociar e informar el resultado de la evaluación y de la decisión.
3. Implementación del cambio. Si se ha aceptaoa la modificación, hay que refle-
jarlo en todos los lugares en donde se verá afectado el software.
4. Trazabilidad. Los requisitos deben ser trazables, es decir, bien identificados . Se
podŕıa decir que un requerimiento es trazable si se pueden identificar todas las
partes del producto existente relacionados con este requisito.
Es importante que los puntos anteriores sean considerados cada vez que un reque-
rimiento es agregado al proceso de desarrollo de software.
27
Caṕıtulo 4
Arquitectura de Software para
Aplicaciones Web
“Construimos nuestros sistemas informáticos de la misma manera que construimos
nuestras ciudades: con el tiempo, sin un plan, sobre las ruinas.”
Ellen Ullman.
En los caṕıtulos anteriores se mencionó el gran impacto y crecimiento que han te-
nido las aplicaciones en el mundo de Internet con esto, la ingenieŕıa de software ha
sufrido actualizaciones para poder adaptarse al desarrollo y mantenimiento de las apli-
caciones Web, colocando principal enfoque en la escalabilidad, entrega y calidad. La
arquitectura de software apoya en el desarrollo de aplicaciones de forma eficiente y con
capacidad de reutilización. En este caṕıtulo se busca definir qué es una arquitectura de
software, aśı como también, las ventajas que genera al ser implementada.
4.1. ¿Qué es una arquitectura de software?
El desarrollo de software tiene un grado de complejidad importante, particularmente
cuando se decide cómo y con qué se realizará. La arquitectura se centra en la forma
en la que se construirán los sistemas de software; además define la estructura
del sistema e integra todos los componentes que lo involucran y sus interrelaciones. En
el presente, el diseño de una arquitectura es fundamental en la ingenieŕıa de software
(Braude, 2014).
“Si se quiere reducir el deterioro del software, tendrá que mejorar su diseño”.
(Pressman, 2010).
29
4. ARQUITECTURA DE SOFTWARE PARA APLICACIONES WEB
4.1.1. Definición de arquitectura de software
La arquitectura de software es la forma en que se organizan los componentes de
un sistema, interactúan y se relacionan entre śı y con el contexto, al utilizar normas y
principios de diseño y calidad, que fortalezcan y fomenten la usabilidad, que a la vez
preparan al sistema, para su propia evolución. (Sommerville, 2011)
El objetivo de la arquitectura consiste en desarrollar sistemas de software grandes
de forma eficiente, estructurada y con capacidad de reutilización.
4.1.2. Caracteŕısticas de la arquitectura de software
En la fase de diseño se construye la arquitectura del software y la de los datos,
para esto se toma en cuenta el entorno sobre el cual estará ejecutándose. Es importante
mencionar que la arquitectura no es el software operativo, más bien es aquella repre-
sentación que permite:
1. Analizar la efectividad del diseño para cumplir los requerimientos establecidos.
2. Considerar alternativas arquitectónicas en la etapa en la que realizar cambios es
relativamente fácil.
3. Reducir los riesgos asociados con la construcción del software.
Como se menciona en el punto 4.1.1 la arquitectura de software está basada en
componentes. Un componente puede ser algo tan simple como un módulo de programa
o una clase orientada a objetos, pero también puede ampliarse para que incluya bases
de datos que permitan la configuración de una red de clientes y servidores.
En el nivel arquitectónico, no se especifican las propiedades internas, por ejemplo
los detalles de un algoritmo. Las relaciones de los componentes pueden ser tan simples
como una llamada a un procedimiento de un módulo a otro o tan complejos como un
protocolo de acceso a una base de datos.
4.1.3. Importancia de la arquitectura de software
A través de la arquitectura de software es posible analizar el impacto de los cambios
en el software.Cuando se necesita desarrollar una nueva funcionalidad o un nuevo módu-
lo, es más fácil identificar los componentes que se necesitan crear, modificar o reutilizar.
Se identifica dos puntos clave para el uso de una arquitectura: (Pressman, 2010).
30
4.1 ¿Qué es una arquitectura de software?
Las representaciones de la arquitectura de software permiten la comunicación
entre todas las partes (participaciones) interesadas en el desarrollo basado en la
computadora.
La arquitectura constituye un modelo relativamente pequeño y accesible para
saber cómo está estructurado el sistema y la forma en la que sus componentes
trabajan juntos.
En la figura 4.1 se muestran las tres principales ventajas al utilizar una arquitectura
de software. La arquitectura afecta el rendimiento, solidez, grado de distribución y
mantenimiento; para que estos puntos sean lo más eficientes posible es importante el
análisis de requerimientos y también depende del tipo del sistema a desarrollar.
Figura 4.1: Ventajas del uso de la arquitectura de software.
31
4. ARQUITECTURA DE SOFTWARE PARA APLICACIONES WEB
1. Comunicación con los participantes. La arquitectura es una presentación de
alto nivel del sistema, que puede usarse como un enfoque para la discusión de un
amplio número de participantes.
2. Análisis del sistema. En una etapa temprana en el desarrollo del sistema,
aclarar la arquitectura del sistema requiere cierto análisis. Las decisiones de diseño
arquitectónico tiene un efecto profundo sobre si el sistema puede o no cubrir
requerimientos cŕıticos como rendimiento, fiabilidad y mantenibilidad.
3. Reutilización a gran escala. Un módulo de una arquitectura de sistema es
descripción corta y manejable de cómo se organiza un sistema y cómo se relacionan
sus componentes. Por lo general, la arquitectura del sistema es la misma para
sistemas con requerimientos similares, y por lo tanto, puede soportar reutilización
de software a gran escala.
4.2. Del Estilo Arquitectónico al Patrón de Diseño
En el caṕıtulo anterior, se mencionó que el diseño permite estimar costos, tiem-
pos, detectar errores, dividir tareas y ayuda a hacer las modificaciones necesarias, para
mantener un desarrollo en buen estado y mejorar su funcionalidad.
(Braude, 2014) y (Sommerville, 2011) han comparado el desarrollo de software con
la construcción de edificios. Se han adoptado ciertas metodoloǵıas que nos permiten
construir grandes aplicaciones de igual forma que la ingeniera civil lo hace con los
grandes edificios. Esto hasta cierto grado es posible debido a que los ambientes son
totalmente diferentes, en la Ingenieŕıa Civil se tiene que lidiar con problemas f́ısicos
como la tensión y la compresión. Además, en el desarrollo de software las leyes de la
f́ısica no son aplicables, sin embargo, el equipo de desarrollo tiene que lidiar con nuevas
restricciones como son la escalabilidad, entrega y calidad.
4.2.1. Diseño Arquitectónico
Existen varios niveles de diseño arquitéctonico, todos con el objetivo de aportar
calidad al software resultante. En la tabla 4.1 se mencionan las diferencias entre estos
tres conceptos y la relación que tienen entre śı, mismos que en conjunto forman la
arquitecturade software. (Bahit, 2013) ,
32
4.3 ¿Qué es un patrón?
Tabla 4.1: Niveles de diseño arquitectónico.
Nivel Función Ejemplos
Primer Nivel: Estilo
Arquitectónico
Describir la estructura ge-
neral de un software y defi-
nir los componentes del sis-
tema, su relación e interac-
tividad.
Flujo de datos del softwa-
re, llamadas y respuestas a
procedimientos.
Segundo Nivel: El
Patrón Arquitectónico
Define la estructura bási-
ca del software y represen-
ta una forma de construc-
ción que contiene un con-
junto de normas para su or-
ganización.
Modelo en capas, patrón
Modelo Vista Controlador
Tercer Nivel: El Patrón
de Diseño
Describir con detalle los
subsistemas y componen-
tes del software.
Proxys y conexiones
4.3. ¿Qué es un patrón?
Un patrón es un modelo que podemos seguir para realizar algo. Los patrones surgen
de la experiencia de los seres humanos para tratar de lograr ciertos objetivos. Los
patrones capturan la experiencia existente y probada para promover buenas prácticas.
(Rayfield, 2001)
4.3.1. Patrones de Arquitectura
(Sommerville, 2011), sugiere que el desarrollo de aplicaciones Web se basa en la ex-
periencia de los participantes involucrados. Es por eso que se ha hecho el esfuerzo por
documentar los casos de éxito en el desarrollo de este tipo de aplicaciones y se han
propuestos patrones arquitectónicos, que intentan abstraer el comportamiento de un
conjunto de componentes.
33
4. ARQUITECTURA DE SOFTWARE PARA APLICACIONES WEB
Los patrones arquitectónicos determinan:
La organización estructural del sistema. ¿Cómo será el diseño de la solución?
La selección de los elementos estructurales. ¿Cuáles serán los componentes?
El comportamiento de los componentes. ¿Cuál sera la función de cada uno?
Las interfaces entre ellos. ¿Cómo se van a comunicar esos componentes?
4.3.2. Patrón Arquitectónico Modelo Vista Controlador
En los últimos años el patrón Modelo Vista Controlador (MVC) ha sido utilizado
para el desarrollo de aplicaciones Web. La primera aparición de este patrón fue en
el lenguaje Smalltalk-80 para construir interfaces de usuario, siendo la separación de
componentes la aportación más importante.(Tahuiton, 2011).
El patrón MVC divide las aplicaciones en tres niveles de abstracción:
1. Modelo
2. Vista
3. Controlador
Con lo anterior, se logra separar la lógica del negocio de la interfaz del usuario, esto
facilita que la funcionalidad, mantenibilidad y escalabilidad del sistema se realice de
forma sencilla. Además resuelve caracteŕısticas comunes para las aplicaciones Web, en
las que destacan:
Mantener separadas las operaciones con los datos. (interacciones con la Base de
datos)
Creación de las interfaces que se le presentaron al usuario.
Mantener separado la manipulación de los datos y también el manejo de las
interfaces, manejo de errores y excepciones.
34
4.3 ¿Qué es un patrón?
4.3.3. ¿Cómo funciona?
El funcionamiento del patrón Modelo Vista Controlador es el siguiente:
1. El usuario realiza una petición al servidor por medio de su navegador web, misma
que es recibida por el controlador.
2. El controlador llama al modelo correspondiente.
3. El modelo solicita la información a la base de datos.
4. El modelo recoge la información de la base de datos y la regresa al controlador.
5. El controlador recibe la información.
6. El controlador procesa y env́ıa la información a la vista.
7. La vista entrega al usuario la información de forma de una vista web.
Figura 4.2: Descripción general del funcionamiento del patrón MVC.
35
4. ARQUITECTURA DE SOFTWARE PARA APLICACIONES WEB
Al separar la presentación, los datos y la lógica del negocio, ayuda a tener control
sobre cada uno de los componentes que forman parte del software.
4.3.4. El Modelo
La figura 4.3 muestra como el modelo implementa la interacción con la base de datos,
por medio de métodos que ejecutan sentencias para la obtención y actualización de la
información. Por ejemplo, en una aplicación bancaria, el modelo lo forman aquellas
métodos que modifican o bien registran datos sobre los distintos servicios (cuentas,
transacciones, y otras operaciones). El modelo no tiene información sobre la vista y el
controlador (no los referencia directamente).
Figura 4.3: Función general del modelo.
36
4.3 ¿Qué es un patrón?
4.3.5. La Vista
La vista es la interfaz de usuario, en la figura 4.4. Contiene los elementos de la inter-
faz que permiten al usuario interactuar con la aplicación, tales como botones, menús,
imágenes, etc
Figura 4.4: Función general de la vista. (Tahuiton, 2011)
37
4. ARQUITECTURA DE SOFTWARE PARA APLICACIONES WEB
4.3.6. El Controlador
El controlador es el intermediario entre la vista y el modelo (figura 4.5). Es quien
administra las interacciones del usuario solicitando los datos al modelo y entregándose
a la vista para que sean presentados al usuario.
Figura 4.5: Función general del controlador.
38
Caṕıtulo 5
Implementación del Patrón Modelo Vista
Controlador
“La mejor teoŕıa está inspirada en la práctica. La mejor práctica está inspirada en la
teoŕıa.”
Donald Knuth.
Con el fin de mostrar un caso práctico del patrón arquitectónico Modelo Vista Con-
trolador, se realizó la creación de la aplicación “Metáfora Acatlán”, con el objetivo de
describir el papel que juega cada etapa del proceso de desarrollo de software.
5.1. Caso práctico: Metáfora Acatlán
”Metáfora Acatlán”surge del trabajo en conjunto con un alumna del Doctorado de
Pedagoǵıa de la Facultad de Estudios Superiores Acatlán. Con esta aplicación se busca
apoyar la investigación de campo, en la recolección, clasificación y procesamiento de la
información.
5.1.1. Identificación del problema
La investigación de campo surge para comprender y resolver alguna necesidad o pro-
blema en un entorno determinado, en este caso, para obtener la información, se recurre
a cuestionarios para la recolección de la misma, siendo esta una tarea no complicada,
sin embargo, el siguiente paso de homologación de la información, clasificación y proce-
samiento. Esta es una tarea que el investigador tuviese que realizar de manera manual
39
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
que consistiŕıa en la captura de cada uno de los elementos recabados, siendo una tarea
tediosa que sin duda alguna tiene un impacto en el tiempo de la investigación. En la
figura 5.1 se muestra el cuestionario propuesto para la recolección de la información.
Figura 5.1: Propuesta inicial de los requerimientos.
40
5.2 Implementación del patrón MVC en Metáfora Acatlán
5.2. Implementación del patrón MVC en Metáfora Acatlán
Para la creación de la aplicación Metáfora Acatlán, se siguieron las fases marca-
das en la ingenieŕıa de software, mencionadas en el caṕıtulo tres, además de utilizar el
patrón Modelo Vista Controlador como arquitectura de la aplicación.
5.2.1. Propuesta de solución
Poder reducir tiempos en el procesamiento y concentración de la información dis-
para la propuesta de creación de Metáfora Acatlán, el contar con un aplicativo de fácil
acceso a través de Internet y que además, apoye en el análisis y administración de los
datos en el transcurso de la investigación.
Este software que estará publicado en Internet generará un impacto importante
para la optimización de tiempos en la captura de los datos, ya que puede ser accedido
desde cualquier dispositivo con conexión a Internet.
5.2.2. Análisis de requerimientos
Inicialmente se partirá del planteamiento del problema descrito en la sección 5.2.1.
Se propuso el desarrollar un aplicación Web que estará disponible en Internet para
poder recabar la información por medio de dos formularios, uno para la recolección de
la información de los profesores y otro para la información solicitada a los alumnos.
Además se busca colocar una pequeña encuesta de satisfacción en forma deretroali-
mentación de la aplicación.
Posteriormente es indispensable que los datos se expongan en una interfaz para que,
el investigador pueda visualizar los datos recolectados para poder realizar descarga de
la información consultada para poder operar la información de manera personalizada.
Requerimientos funcionales:
1. Es necesario recabar la información de profesores y alumnos por medio de dos
cuestionarios.
2. Se necesita un panel de control donde se pueda visualizar, procesar y descargar
la información obtenida.
3. Se realizará una breve encuesta de opinión sobre la aplicación y las información
solicitada en los formularios.
41
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
4. Se necesita una manera de notificar a los usuarios que participen en ingresar a
responder los formularios.
5. Es importante un módulo para env́ıo de correos electrónico masivo, para el env́ıo
de las notificaciones.
6. Se identifican 2 usuarios principales: participantes (profesores y alumnos) y el
investigador que visualiza y procesa la información.
7. Se creará un módulo para el análisis estad́ıstico.
Requerimientos no funcionales:
1. La recolección de la información tendrá que ser de manera amigable y lo más
rápida posible, con la finalidad de que el mayor número de personas participe.
2. Es importante que la interfaz sea amigable.
3. Se podrá acceder a los cuestionarios por medio de un navegador web, en disposi-
tivo con conexión a internet, computadora. tablet o bien dispositivos móviles.
Con base a la obtención de los requerimientos se obtienen los diagramas de casos de
uso. El modelado de casos de uso sirve entre otras cosas para delimitar el alcance del
sistema, esbozar quienes trabajarán con el aplicativo a modo de actores, y determinar
cuáles son las funcionalidades esperadas para cada uno de ellos (Fontela, 2011).
En el al análisis de requerimientos realizado se identifican a tres actores que parti-
cipan en el uso del software (figuras 5.2, 5.3, 5.4)
Profesores
Alumnos
Investigador
42
5.2 Implementación del patrón MVC en Metáfora Acatlán
Figura 5.2: Diagrama de casos de uso del profesor.
Figura 5.3: Diagrama de casos de uso del alumno.
43
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
Figura 5.4: Diagrama de casos de uso del investigador.
44
5.2 Implementación del patrón MVC en Metáfora Acatlán
5.2.3. Diseño del software
En el apartado anterior se identifican dos grandes procesos del software: la captura
de la información y la parte del aplicativo que mostrará los datos clasificados de una
manera más accesible. En consecuencia del análisis anterior se puede visualizar de ma-
nera analógica por medio del siguiente diagrama, mostrado en la figura 5.5.
Figura 5.5: Diagrama general del sistema Metáfora Acatlán.
Tomando en cuenta el diagrama general del aplicativo, se continúa con el diseño
de la arquitectura, el software se encontrará disponible en Internet, lo cual implica que
se encuentre bajo un modelo de aplicación distribuida, en el que las tareas se reparten
entre el servidor y los clientes, quienes solicitan recursos a este para poder comenzar la
interacción.
Figura 5.6: Diagrama de la arquitectura general de Metáfora Acatlán.
45
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
Como se observa en la figura 5.6 el aplicativo necesitará almacenar los datos de
cada uno de los cuestionarios, para esto es necesario utilizar un Sistema Gestor de Base
de Datos para el almacenamiento de la misma. Este es un punto importante en todo
desarrollo de software ya que es donde se define el modelado de los datos. En la figura
5.7, se muestra el modelo relacional de la base datos ya normalizado.
Figura 5.7: Diagrama entidad relación de la aplicación.
Una vez realizado el diseño de las arquitecturas de la aplicación, sigue la creación
de las interfaces que contendrá el sistema, aunque parezca un paso sencillo, es el punto
que debe de realizarse con el mayor cuidado posible para que en este punto el ciclo de
desarrollo pueda continuar y no retrasarse por mala definición de requerimientos.
En las figuras (5.8, 5.9), se muestra el diseño de las interfaces de cuestionarios y el
acceso al sistema (panel de administración).
46
5.2 Implementación del patrón MVC en Metáfora Acatlán
Figura 5.8: Cuestionario alumno. (https://www.metaforacatlan.net/student)
47
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
Figura 5.9: Cuestionario profesor. (https://www.metaforacatlan.net/proffesor)
Figura 5.10: Acceso al sistema. (https://www.metaforacatlan.net/acceso)
48
5.2 Implementación del patrón MVC en Metáfora Acatlán
5.2.4. Arquitectura de la aplicación
La definición de la arquitectura forma parte de la etapa de diseño, misma que se
menciona en la sección 3.3.3, sin embargo, para fines demostrativos de la implementa-
ción del patrón arquitectónico se decidió describir este punto por separado.
Tomando como referencia, el caṕıtulo 4, el uso de una arquitectura de software y
espećıficamente el del patrón arquitectónico Modelo Vista Controlador, mantiene el
orden en cada uno de los módulos del aplicativo, además de que auxiliará a que el
aplicativo sea fácilmente escalable. A continuación se describe el cómo el patrón ar-
quitectónico fue implementado para la creación del aplicativo “Metáfora Acatlán”. La
primera pregunta que surge al implementar el patrón arquitectónico es: ¿Dónde coloco
los archivos, los modelos, las vistas, los controladores?
En la figura 5.11, se muestra la implementación del patrón MVC en el aplicativo, en
el ejemplo se muestra la división de componentes para el módulo de acceso al sistema
Figura 5.11: Módulo: Acceso al sistema.
Ahora ya se tiene identificado los componentes bajo el patrón MVC, en la figura
5.12, se ven cada uno de los archivos que conforman al módulo.
49
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
Figura 5.12: Archivos del módulo, bajo el patrón MVC.
Cada uno de los módulos tendrá la misma estructura, en consecuencia se sugiere
tener un directorio ordenada en base a cada componente del patrón MVC. en la figura
5.13, se muestra el directorio del aplicativo.
50
5.2 Implementación del patrón MVC en Metáfora Acatlán
Figura 5.13: Directorio del aplicativo Metáfora Acatlán.
En el directorio base del aplicativo se propone colocar las siguientes carpetas para
el proyecto.
1. Application. Carpeta en donde se colocarán los archivos que ejecutarán los
procesamientos en el lenguaje que el servidor web interpreta, conocido como back-
end.
2. CSS. Aqúı será el lugar donde se almacenarán las hojas de estilo (archivos css)
para el aplicativo. Estas no son ejecutadas por el servidor si no, por el navegador
y ayudan a crear interfaces amigables.
3. Fonts. En el caso de este aplicativo utilizará una letra fuente proporcionada por
google, para fines de velocidad se decidió descargar estas fuentes y colocarlas en
el directorio.
4. Icons. Lugar donde se encontrarán los iconos para la aplicación.
5. Images. Carpeta para las imágenes.
6. Js. Esta carpeta se encontraran los archivos extensión .js (java script), que ayudan
al procesamiento de información y animaciones en el navegador Web, en el que
se esté ejecutando la aplicación.
7. Directorio ráız. En este se busca colocar el menor número de archivos posibles,
con la finalidad de mantener buen orden y manejo de los directorios.
51
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
Es importante mencionar que los directorios pueden tener subdirectorios, inicial-
mente veremos la organización que tendrá la carpeta application, en ella se encon-
trarán los elementos que conforman el patrón arquitectónico MVC. ver figura 5.14.
Figura 5.14: Directorio MVC.
1. Controllers. Aqúı se almacenarán los controladores, se propone crear un con-
trolador por módulo, ya que como se menciona en el caṕıtulo 4 elcontrolador es
el intermediario entre el modelo y las vistas a procesar, en el caso de Metáfora
Acatlán el directorio de controladores, como se muestra en la siguiente figura 5.15
Figura 5.15: Directorio del controlador.
52
5.2 Implementación del patrón MVC en Metáfora Acatlán
Cada página es un módulo llamado por medio de la url, por ejemplo:
https://www.metaforacatlan.net/acceso
Con esto el controlador, se encargará de llamar a las vistas o modelos que corres-
pondan.
2. Models. Se podrán encontrar los archivos con los métodos que realizan tran-
sacciones con las bases de datos, se puede identificar como la última capa de la
aplicación antes de la base de datos, aqúı se podrán encontrar las consultas SQL.
Ver figura 5.16.
Figura 5.16: Directorio del modelo.
3. Vistas. Es el lugar en donde se encontrarán los archivos con las interfaces que
serán llamadas por el controlador. Ver figura 5.17.
Figura 5.17: Directorio de las vistas.
53
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
4. Resources y utils. Estas carpetas no forman parte del Patrón arquitectónico,
sin embargo, son propuestas para colocar archivos con métodos que ayudarán a
tareas espećıficas del aplicativo como por ejemplo, configuración para env́ıo de
correos electrónicos, métodos para el cifrado de la información etc.
Finalmente se puede decir, que la parte lógica y transaccional se encuentra en la
carpeta de application y dentro de ella los controladores, modelos y vistas. En las
demás se encuentra la parte que se ejecuta en el cliente (navegador Web), llamado
“Front-End”.
5.2.5. Construcción de la aplicación
Una vez finalizadas la etapas de Análisis de requerimientos y diseño se continúa
con la etapa de construcción, que es en donde la abstracción de las etapas anteriores
se vuelve realidad, llevándolo a cabo por medio de lenguajes de programación en este
caso PHP. Es importante mencionar que el desarrollo del aplicativo Metáfora Acatlán,
es basado en el paradigma de programación orientado a objetos.
Se identifican dos grandes partes en el desarrollo de la aplicación, la primera es la
captura de información y la segunda la clasificación, muestra y procesamiento de los
datos. En base a lo anterior se decidió separar la construcción en dos grandes fases
inicialmente la construcción de los formularios y posteriormente la del panel en el cual
se desplegará la información. Cada una de las etapas se describe por medio de los dia-
gramas mostrados en las figuras 5.18 y 5.19.
54
5.2 Implementación del patrón MVC en Metáfora Acatlán
Figura 5.18: Primera fase del desarrollo del aplicativo.
La figura 5.18 explica la primera etapa del desarrollo de la aplicación. Básicamente
consistió en crear el modelo de base de datos y también probar que la conexiones entre
el servidor del aplicativo y el de la base de datos funcionará de manera correcta.
Figura 5.19: Diagrama de etapas de desarrollo del aplicativo.
55
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
En la figura 5.19, se muestran cada una de las etapas, que se llevaron a cabo en la
etapa de desarrollo, en el modelo incremental cada uno de los ćırculos representa una
fase entregada y finalizada. La idea principal fue realizar entregas lo más pronto posible
para que la aplicación pasará por periodos de pruebas.
5.2.6. Pruebas
Para el software Metáfora Acatlán se realizaron pruebas incrementales para poder
encontrar errores, principalmente en el módulo de recolección de la información, este
es considerado como una parte cŕıtica del aplicativo.
El ciclo de pruebas se realizó como sigue:
1. Pruebas en entorno local: Fueron realizadas en el entorno de desarrollo con
la finalidad de que en el momento de la construcción del aplicativo se puedan
corregir antes de proporcionar el aplicativo como una versión estable disponible
a pruebas para otros usuarios.
2. Prueba Piloto: Con la finalidad de contar con un aplicativo de calidad se propuso
una convocatoria a un número limitado de personas a probar el software, con la
finalidad de que se tuviese una retroalimentación sobre el aplicativo.
Para el lanzamiento de esta prueba piloto se invitó a los usuarios por correo electróni-
co, obteniendo los siguientes resultados, mosrados en la tabla 5.1 :
Tabla 5.1: Contabilización de las pruebas.
Cuestionario Profesores 4
Cuestionario Alumnos 10
Total de Pruebas Exitosas 14
56
5.2 Implementación del patrón MVC en Metáfora Acatlán
En la tabla 5.2, se exponen los comentarios obtenidos durante la prueba piloto del
aplicativo.
1 Buenas preguntas.
2 Tuve algunos problemas cuando intenté utilizar algu-
nos signos de puntuación.
3 Excelente recurso para trabajos de investigación.
Tabla 5.2: Comentarios obtenidos.
En la figura 5.20, se muestra la invitación para la realización de la prueba piloto.
Figura 5.20: Invitación enviada v́ıa correo electrónico.
En el ciclo de pruebas descrito anteriormente, se concluye que el aplicativo se en-
cuentra listo para ponerlo en marcha para la recolección de la información, ya que los
errores que existieron se corrigieron de manera pronta y no impactaron en el modelo
del software planteado inicialmente.
57
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
5.2.7. Implementación
Una vez que la aplicación respondió a las pruebas de manera exitosa, se continua
con la implementación del aplicativo, es decir, la puesta en marcha. Para esto es nece-
sario un servidor Web, que interprete el lenguaje PHP y que cuente con un servicio de
Base de datos con el manejador de MySQL.
En seguida se describe las caracteŕısticas del servidor web en donde se aloja la apli-
cación:
1. Servidor Web Apache versión 2.4.29
2. Servicio de Base de datos MySQL 10.1.28-MariaDB
3. Memoria RAM 2GB
4. Espacio en Disco Duro 8 GB
5. Protocolo https (certificado de seguridad ssl)
6. Sistema operativo Debian 7
El aplicativo contará con el nombre de dominio siguiente:
https://www.metaforacatlan.net
Una vez desplegado el código en el servidor productivo anteriormente descrito, se
podrá visualizar el aplicativo de la siguiente manera, figura 5.21.
Figura 5.21: Página de inicio. (https://www.metaforacatlan.net/)
58
5.2 Implementación del patrón MVC en Metáfora Acatlán
Panel de administración: La fase dos de desarrollo del software fue la imple-
mentación del panel de administración para que el investigador pueda visualizar la
información que se consiguió por medio de los formularios, figura 5.22.
Para acceder al Panel de administración es necesario colocar la siguiente dirección
en el navegador:
https://www.metaforacatlan.net/acceso
Se desplegará la siguiente pantalla, donde solicitará usuario y contraseña:
Figura 5.22: Acceso. (https://www.metaforacatlan.net/acceso)
Una vez entrando al panel de administración se podrán consultar los datos regis-
trados, figura 5.23.
59
5. IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA CONTROLADOR
Figura 5.23: Vista de los datos recolectados.
5.3. Análisis de resultados de la implementación
El aplicativo, “Metáfora Acatlán”, tuvo una respuesta aceptable y se logró cumplir
el objetivo de recolectar la información, también se logro abrir el panorama para seguir
impulsando este tipo de aplicaciones como herramientas para apoyar investigaciones de
posgrado u otras.
5.3.1. Resultados a nivel aplicativo
Metáfora Acatlán, obtuvo grandes resultados la aplicación es decir, estuvo disponi-
ble la mayor parte del tiempo a partir de la fecha de su liberación, además de mostrar
una facilidad para que los usuarios lograrán registrar su información.
A nivel técnico la aplicación quedó en una forma muy sencilla y estable con la fina-
lidad de que la transferencia de conocimiento sea rápida y que cualquier persona que
se encuentre interesado en continuar en el desarrollo del proyecto pueda hacerlo con
rapidez. A su vez la implementación del patrón arquitectónico ayudó