Instituto Tecnologico Superior de Misantla

Jerarquıa de clases parala creacion de un

framework responsivomediante ECMAScript 6

Modulo: Jefes de Carrera del SITM

TESISQUE PARA OBTENER EL GRADO DE:

Maestra en Sistemas Computacionales

Presenta:

Carmen Juliana Aguilar Fernandez

Director:

Dr. Jorge Mario Figueroa Garcıa

Misantla, Veracruz Septiembre de 2018

ii

Agradecimientos

El proyecto SITM es un proyecto con una magnitud superior a un software tradicional, porello y gracias a la perspectiva del Dr. Jorge Mario Figueroa Garcıa, es que este proyecto tomola forma que actualmente tiene y en la cual mi companero Maestro en Sistemas Computacio-nales: Francisco Adolfo Aguilar Gomez y yo, culminamos satisfactoriamente.

Agradezco al Consejo de Ciencia y Tecnologıa (CONACYT) por su apoyo para la elabo-racion de este proyecto de investigacion.

Numero de Becario:60733

Numero de CVU:786738

Numero de apoyo:447745

iii

Dedicatoria

Gracias Dios por darme la vida, la salud y la fuerza necesaria para culminar esta meta per-sonal.La realizacion de esta Tesis, sin lugar de dudas esta dedicada a mas de una persona, quetodos siempre me han apoyado y motivado para seguir adelante. Gracias a mi familia, mispapas y mis hermanas por su apoyo incondicional, lo mejor que tengo en la vida.Madrina Clara, Gaby y Danielito su risas y companıa me llenan de mucha alegrıa y fortalezaMadrina Chela, gracias porque aun estando lejos fısicamente de la familia siempre estas alpendiente de nosotros.Tıa Mica, gracias por escucharme siempre que lo necesite.Tia Irma, gracias por tus animos y palabras de aliento.Mis companeros de clase y maestrıa: Gracias por los momentos compartidos, los mejorescomplices que me pude haber encontrado.

iv

Resumen

El Sistema Integral del Tecnologico de Misantla (SITM) es un ERP (Enterprise ResourcePlanning) que se esta desarrollando para integrar y automatizar los procesos docentes y ad-ministrativos primordiales sobre una plataforma web para el Instituto Tecnologico Superiorde Misantla. En su desarrollo se usan los principios de Programacion Orientada a Objetos(POO) con la finalidad de implementar la reutilizacion de componentes de software en loscodigos que generan la interfaz y en la transferencia de informacion entre los clientes y elservidor. Se trabaja bajo el analisis y diseno del modelo en espiral, debido a la adaptaciongradual que este proporciona y como patron de diseno se tomo como referencia el ModeloVista Controlador.El sistema esta dividido en un subsistema BackEnd (ya concluido, probado e implantado enotros sistemas), que lleva a cabo una representacion orientada a objetos de las bases de datosy sus elementos, logrando con ello una gestion arbitrada de un cluster de base de datos hete-rogeneas de forma relativamente simple. El segundo subsistema es un FrontEnd compuestopor clientes web asıncronos y adaptativos que extienden una o mas clases ECMAScript6 quesirven de plantilla y dotan a sus extensiones de las capacidades necesarias para interactuarcon el BackEnd.Se obtuvo un modelo de comunicacion con el servidor muy simple, transferencia de codigosy datos reducida al mınimo, una eficiente renderizacion de los componentes de interfaz, y deforma inherente se ha elevado la seguridad del sistema.Actualmente ambos subsistemas se encuentran operando satisfactoriamente, por el lado dela FrontEnd, no se han encontrado vulnerabilidades de inyeccion de codigo SQL, ademasla plantilla opera segun la modificacion realizada al Modelo Vista-Controlador habiendoseprobado en diferentes navegadores y funcionando tambien de manera adecuada el disenoresponsivo en diferentes dispositivos Moviles.

v

Abstract

The Integral System of the Technological of Misantla (SITM) is an ERP (Enterprise Re-source Planning) that is being developed to integrate and automate the primary educationaland administrative processes on a web platform for the Higher Technological Institute ofMisantla. In its development the principles of Object Oriented Programming (OOP) areused with the purpose of implementing the reuse of software components in the codes thatgenerate the interface and in the transfer of information between the clients and the server.Work is carried out under the analysis and design of the spiral model, due to the gradualadaptation it provides and as a design pattern the Controlled View Model was taken asreference.The system is divided into a BackEnd subsystem (already concluded, tested and implemen-ted in other systems), which carries out an object-oriented representation of the databasesand their elements, thus achieving an arbitrated management of a base cluster of data. hete-rogeneous data in a relatively simple way. The second subsystem is a FrontEnd composed ofasynchronous and adaptive web clients that extend one or more ECMAScript6 classes thatserve as templates and endow their extensions with the necessary capabilities to interactwith the BackEnd.A communication model with the very simple server was obtained, code and data transferwas reduced to a minimum, efficient rendering of the interface components, and inherentlythe security of the system has been increased.Currently both subsystems are operating satisfactorily, on the FrontEnd side, no SQL codeinjection vulnerabilities have been found, and the template operates according to the mo-dification made to the Vista-Controller model, having been tested in different browsers andalso working properly Responsive design in different Mobile devices.

vi

Indice general

Autorizacion de impresion III

Agradecimientos III

Dedicatoria IV

Resumen V

Abstract VI

Indice de figuras IX

Indice de tablas XI

1. Generalidades 121.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2.1. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.5. Alcances y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.5.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.5.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.6. Estructura de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2. Marco teorico 162.1. Patron de Fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.1. Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2. FrontEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1. MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.2. Navegador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

vii

2.3. Interfaz de Comunicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4. BackEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.1. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3. Estado del arte 23

4. Desarrollo de la solucion 264.1. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2. El enfoque del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3. Diseno del FrontEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3.1. Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.2. Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.3. Interfaz de comunicacion . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4. Diseno del BackEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4.1. Clases para describir el modelo de datos . . . . . . . . . . . . . . . . 294.4.2. Intercomunicacion con los clientes web . . . . . . . . . . . . . . . . . 31

4.5. Diagramas de Flujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.6. Diagramas de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.7. Diagrama de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5. Analisis de resultados 415.1. Pruebas de Verificacion y Validacion . . . . . . . . . . . . . . . . . . . . . . 41

5.1.1. Lıneas de Codigo: Libreria mensajes.js . . . . . . . . . . . . . . . . . 415.1.2. Analisis de Seguridad Web . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2. Compatibilidad entre navegadores . . . . . . . . . . . . . . . . . . . . . . . . 425.3. Diseno Responsivo en diferentes tamanos de Pantalla . . . . . . . . . . . . . 42

5.3.1. Validacion de la Arquitectura . . . . . . . . . . . . . . . . . . . . . . 43

6. Conclusiones y Trabajos futuros 476.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Referencias 48

Anexos 506.3. Encuesta sobre Navegadores mas utilizados . . . . . . . . . . . . . . . . . . . 506.4. Codigo HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

viii

Indice de figuras

2.1. Variante del modelo en espiral . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2. Modelo Vista Controlador tradicional. . . . . . . . . . . . . . . . . . . . . . 18

4.1. Arquitectura MVC adaptadada al FrontEnd Fuente: Propia del Proyecto . . 274.2. Imagen muestra la manera en la que se consume cada una de las clases para

implementar tabla, registro y campo. . . . . . . . . . . . . . . . . . . . . . . 284.3. Imagen muestra la manera en la que se consume cada una de las clases para

implementar bloques, materias y materia. . . . . . . . . . . . . . . . . . . . . 284.4. Modelo de factorizacion Down-Top aplicado en la implementacion del BackEnd 304.5. Comunicacion de los diferentes cliente con el Servidor mediante peticiones Ajax. 324.6. Diagrama de Flujo de carga de la Pantalla para el modulo de Jefes de Carrera. 334.7. Diagrama de Flujo de la Opcion Carga Academica. . . . . . . . . . . . . . . 344.8. Diagrama de Clases FrontEnd del modulo Jefes de carrera. . . . . . . . . . . 354.9. Diagrama de Clases de los descriptores del Backend. . . . . . . . . . . . . . . 364.10. Diagrama de Secuencia para la funcion de Carga Academica. . . . . . . . . . 374.11. Diagrama de Secuencia para la opcion de Especialidades dentro de la funcion

de Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.12. Diagrama de Secuencia para la opcion de Administrar Grupos la funcion de

Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.13. Diagrama de Secuencia para la opcion de Permisos de Inscripcion dentro de

la funcion de Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1. Imagen del modulo Jefes de Carrera con el navegador Chrome. . . . . . . . . 435.2. Imagen del modulo Jefes de Carrera con el navegador Edge . . . . . . . . . . 445.3. Imagen del modulo Jefes de Carrera con el navegador Firefox. . . . . . . . . 445.4. Imagen del modulo Jefes de Carrera, opcion carga academica. . . . . . . . . 455.5. Imagen del modulo Jefes de Carrera, opcion configuracion. . . . . . . . . . . 455.6. Cronograma de actividades modulo: Adeudos. . . . . . . . . . . . . . . . . . 46

6.1. Resultado de JavaScript Orientado a Objetos. . . . . . . . . . . . . . . . . . 546.2. Plan de Estudios Ing. Ambiental. . . . . . . . . . . . . . . . . . . . . . . . . 556.3. Plan de Estudios Ing. Bioquımica. . . . . . . . . . . . . . . . . . . . . . . . . 566.4. Plan de Estudios Ing. Civil. . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.5. Plan de Estudios Ing. Electromecanica. . . . . . . . . . . . . . . . . . . . . . 58

ix

6.6. Plan de Estudios Ing. en Gestion Empresarial. . . . . . . . . . . . . . . . . . 596.7. Plan de Estudios Ing. Industrial. . . . . . . . . . . . . . . . . . . . . . . . . . 606.8. Plan de Estudios Ing. Petrolera. . . . . . . . . . . . . . . . . . . . . . . . . . 616.9. Plan de Estudios Ing. en Sistemas Computacionales. . . . . . . . . . . . . . . 626.10. Plan de Estudios Ing. en Tecnologıas de la Informacion y Comunicaciones. . 63

x

Indice de tablas

5.1. Comparativa de la librerıa mensajes, alertify y boostrap.dialog en Javascript 415.2. Comparativa entre entre SITM e implementaciones del SII . . . . . . . . . . 42

6.1. Uso de exploradores segun la w3Schoool para el mes de Mayo de 2018 . . . . 50

xi

Capıtulo 1

Generalidades

1.1. Introduccion

El Sistema Integral del Tecnologico Superior de Misantla (SITM) surge de la necesidadde adecuar a las condiciones actuales los sistemas informaticos que hoy intervienen en losprocesos administrativos y academicos del Tecnologico de Misantla y por la necesidad desistematizar aquellos que aun no lo estan. Mediante el SITM, se interconectan los diversosdepartamentos y/o funciones que intervienen en los procesos de gestion y docencia de lainstitucion y se integra software de terceros y a terceras entidades; se dota ası de la interco-nectividad, posibilidades de expansion y eficiencia que los sistemas actuales de la institucionno poseen. El sistema esta divido en dos subsistemas: Un Backend y un FrontEnd. El Bac-kEnd es un subsistema totalmente autonomo, compuesto por un agente listener extensible yconfigurable junto con un conjunto de clases que permiten llevar a cabo una representacionorientada a objetos de las bases de datos y sus elementos, con la capacidad de interactuarcon uno o mas cluster de bases de datos heterogeneas [1] que pueden o no estar localizadasen un mismo lugar. El FrontEnd es un subsistema compuesto por un grupo de clientes webasıncronos y adaptativos que extienden una o mas clases ECMAScript6 (European Compu-ter Manufacturers’ Association) (International, 2018) que sirven de plantilla y dotan a susextensiones de las capacidades necesarias para interactuar con el listener del BackEnd y ge-nerar dinamicamente los elementos que componen la interfaz de usuario. Como resultado seha obtenido un modelo de comunicacion con el servidor muy simple, transferencia de codigosy datos reducida al mınimo, una eficiente renderizacion de los componentes de interfaz, y deforma inherente se ha elevado la seguridad del sistema.

1.2. Planteamiento del Problema

En el Instituto Tecnologico Superior de Misantla (ITSM) se cuenta actualmente con unsistema monolıtico poco flexible para la gestion de los servicios escolares y jefaturas de ca-rrera, el cual es considerado desfasado para las necesidades actuales que tiene la institucion,

12

carente ademas de capacidades de interconectividad entre sistemas e imposible de modificarpara agregar nuevos modulos. Por estrategia, el ITSM apuesta hacia el uso y explotacion delas Tecnologıas de la Informacion y las Comunicaciones (TICs) en la gestion e imparticionde carreras que en su interior se brindan. Tras un analisis de la parte directiva con la parteoperativa se concluyo que: es necesario contar con un sistema de gestion que integre la parteacademica, administrativa, operativa y directiva en sus diferentes niveles y que sea capaz deinterconectar con otros sistemas heterogeneos.

Un ejemplo de los problemas con el sistema actual es en la reinscripcion de un alumno. Eldepartamento de servicios escolares debe cerciorarse que el solicitante no tenga adeudos. Losadeudos pueden ser un pago, un libro o una actividad requerida por el plan de estudios, todosestos adeudos son registrados en otra base de datos sin conexion a la de servicios escolares,ası que si el alumno por ejemplo, realiza un pago en caja pero servicios escolares no registraeste pago en su propia base de datos, el joven queda como deudor cuando realmente el ya hapagado su cuenta en caja. Para registrar los adeudos, servicios escolares actualizan su basede datos cada semestre de forma manual a partir de una lista impresa, la cual fue extraıda dela base de datos en otro departamento, esta es una actividad extra para servicios escolares,ademas hace necesario rectificar muchas veces su propia informacion y este proceso se realizapor cada alumno inscrito.

Otro ejemplo es la asignacion de horarios de los docentes. Los jefes de carrera fijan loshorarios de cada grupo, si se trata de un grupo regular el horario se asigna con sucesionininterrumpida de horas, pero hay casos en que el grupo no es regular y hace necesario abrirun curso que esta marcado fuera de la planeacion escolar, estos casos especiales son muy re-currentes y hacen estragos en las actividades haciendo mas difıcil crear una carga academicapor grupo. Pero no solo el problema termina en el grupo, tambien hay alumnos que no sonregulares y los cuales deben armar de forma individual sus horarios sin negarles los cursosmarcados por el plan de estudios con los pocos docentes compartidos entre carreras en lainstitucion. Estos y muchos mas son los problemas que el jefe de carrera debe de resolver alcrear los horarios.

1.2.1. Justificacion

Debido al incremento de alumnado que ha tenido el ITSM desde su fundacion, los recur-sos administrativos y docentes han crecido en consecuencia, siendo necesario crear sistemasheterogeneos que satisfagan las necesidades principales, mismos que han carecido de capaci-dades de interconectividad. Se pretende beneficiar principalmente a la Comunidad: Docente,Estudiantil, Directiva y Administrativa de la Institucion brindandoles un servicio mas agily unificado que el que actualmente se tiene. En segundo termino tambien seran beneficiadoslos aspirantes a alumnos y los Padres de Familia. La aportacion al area de la computaciones que esta plantilla debido a que se siguieron los lineamientos del Tecnologico Nacional de

13

Mexico, puede ser utilizada por cualquier otro campus dependiente de ella.Ademas se requiere una base de datos normalizada para integrarla al BackEnd del sistemapara la gestion de un cluster heterogeneo para la misma.

1.3. Objetivos

1.3.1. Objetivo general

Disenar e implementar una jerarquıa de clases en ECMAScript 6 para reducir al mınimolos codigos generados mediante componentes reutilizables y adaptativos.

1.3.2. Objetivos especıficos

Analizar, disenar e implementar clases para la Plantilla que utilizaran los modulos queası lo requieran para la reutilizacion de codigo.

Adaptar las funciones y caracterısticas del modulo de Jefes de Carrera al Backend pararepresentar la informacion orientada a objetos de la Base de Datos.

Analizar, disenar e implementar la funcion de Carga Academica para que los Jefes deCarrera puedan ofertar las materias de cada semestre.

Analizar, disenar e implementar la funcion de Alumnos para que el Jefes de carrerapueda acceder a los datos de Asistencia y Kardex de los alumnos.

Analizar, disenar e implementar la funcion de Configuracion para que el Jefe de carrerapueda acceder a Definir Especialidades, Administrar grupos y Permisos de Inscripcion.

1.4. Hipotesis

El diseno de un framework orientado a objetos en ECMAScript 6 disminuira la transferen-cia de informacion entre el cliente y el servidor, ademas facilitara la elaboracion de modulosen periodos cortos de tiempo, permitiendo inherentemente mantenimientos y actualizacionesmas rapidas.

1.5. Alcances y limitaciones

1.5.1. Alcances

Para el modulo de Jefes de Carrera, se tiene contemplado incluir las funciones de:

Carga Academica

14

Tutorıas

Docentes

� Consulta de Asistencia

� Planeaciones

Alumnos

� Consulta de Asistencia

� Consulta de Kardex

Configuracion

� Definir Especialidades

� Administrar Grupos

� Permisos de Inscripcion

1.5.2. Limitaciones

Para la generacion de horarios de la carga academica de alumnos y docentes es necesarioque las retıculas de todas las carreras que se ofertan en el ITSM se encuentren completas,es decir que se conozca que materias seran impartidas en el transcurso de los semestres.La carrera de Ingenierıa Petrolera al ser una carrera de reciente creacion no cuenta con lainformacion completa de las materias de especialidad que impartira.

1.6. Estructura de la Tesis

En el capıtulo 2: Marco Teorico, se presentan los conceptos que existen sobre el tema ainvestigar, se explica el patron de Fase usado para el diseno de software que es cascada, sedefinen tambien los conceptos principales en los que se dividio el proyecto, el FrontEnd, elBackEnd y la Interfaz de comunicacion entre ellos.

En el capıtulo 3: Estado del arte, se muestra una recopilacion de los autores e institucionesque en Artıculos y Tesis han abordado el tema que es objeto de estudio, se realiza un analisisde los artıculos mencionados donde se resume el conocimiento y las conclusiones relacionadascon el area de estudio.

En el capıtulo 4: Desarrollo de la solucion, primeramente se indican las herramientasutilizadas y las premisas necesarias para el desarrollo, se profundiza la manera en la trabajael FrontEnd y la manera en la que se comunica con el Backend ası como el diseno del mismo.Se incluyen al final los diagramas de Flujo, Clases y Secuencia.

En el capıtulo 5: Analisis de Resultados, se indican las pruebas de verificacion y validacionrealizadas, se muestran tambien como el sistema funciona en los navegadores seleccionadosy ademas como el diseno responsivo se visualiza en diferentes dispositivos.

15

Capıtulo 2

Marco teorico

2.1. Patron de Fase

El patron de fase define la secuencia de las actividades estructurales que ocurren dentrodel proceso, aun cuando el flujo general de las actividades sea de naturaleza iterativa. Laliteratura senala 3 patrones de fase principalmente: Cascada, Basada en Componenetes yEspiral, esta ultima descrita a continuacion:

2.1.1. Espiral

Propuesto en primer lugar por Barry Boehm, el modelo espiral es un modelo evolutivodel proceso del software y se acopla con la naturaleza iterativa de hacer prototipos con losaspectos controlados y sistemicos del modelo de cascada. Tiene el potencial para hacer undesarrollo rapido de versiones cada vez mas completas. Boehm describe el modelo del modosiguiente:El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por elriesgo, que se usa para guiar la ingenierıa concurrente con participantes multiples de sistemasintensivos en software. Tiene dos caracterısticas distintivas principales. La primera es elenfoque cıclico para el crecimiento incremental del grado de definicion de un sistema y suimplementacion, mientras que disminuye su grado de riesgo. La otra es un conjunto de puntosde referencia de anclaje puntual para asegurar el compromiso del participante con solucionesfactibles y mutuamente satisfactorias.Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas.Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. Enlas iteraciones posteriores se producen versiones cada vez mas completas del sistema cuyaingenierıa se esta haciendo (Pressman y Troya, 1988). En la Figura 2.1 se muestra el modeloespiral definido.

16

Figura 2.1: Variante del modelo en espiral(Pressman, 2010)

2.2. FrontEnd

El Front-End basicamente es todo lo relacionado con lo que el usuario ve, incluido eldiseno y algunos lenguajes como HTML, CCS y Javascript.

2.2.1. MVC

El Model View Controller (modelo-vista-controlador) o MVC es un patron de diseno quepermite separar en capas nuestra aplicacion para lograr un menor acoplamiento entre elcodigo. Es una solucion que sirve en todo tipo de aplicaciones no solo las de tipo ricas eninternet. El patron de diseno sugiere que se divida nuestra aplicacion en 3 Capas, y dentro deuna aplicacion AJAX una metodologıa de aplicacion del patron MVC(Figura 2.2) es separarnuestro desarrollo en:

17

Figura 2.2: Modelo Vista Controlador tradicional.(Pantoja, 2004)

Vista

Es la encargada de mostrar informacion al usuario y recibir su interaccion, por lo que esel archivo XHTML junto al CSS que define la estructura de los elementos que el usuario vejunto con un identificador (id) a cada elemento con el que se quiere interactuar. El XHTMLno contendra codigo JavaScript alguno, ni siquiera la definicion de un onClick.HTML Hoja de estilo en cascada (CSS):La hoja de estilo en cascada o CSS (siglas en inglesde cascading style sheets) es un lenguaje usado para definir la presentacion de un docu-mento estructurado escrito en HTML y derivados. El W3C es el encargado de formular laespecificacion de las hojas de estilo que serviran de estandar para los agentes de usuario onavegadores.La idea que se encuentra detras del desarrollo de CSS es separar la estructura de un docu-mento de su presentacion.La informacion de estilo se define en un documento separado, anteriormente se manejabao en el mismo documento HTML, pero esto genera malas practicas. En este ultimo casopodrıan definirse estilos generales en la cabecera del documento o en cada etiqueta particu-lar mediante las etiquetas ((style))((/style)) (W3C, 2015).Diseno web adaptativo: Se aplican los principios de la web adaptativa, existen tres elementosfundamentales para lograr un diseno web adaptativo, que son:

Cuadrıcula fluida: Este concepto lo que propone es usar porcentajes para definir lostamanos de las columnas o divs, en lugar de pıxeles.

Imagenes flexibles: Las imagenes no tienen anchos fijos sino un maximo (max-width),

18

que en una computadora de escritorio o laptop suele mostrarse al 100 % y se ajustaraal tamano de su contenedor si este reduce su tamano.

Media queries: Con el uso de estilos CSS permite que se personalice utilizando un anchomınimo y maximo del navegador (min-max width) (Marcotte, 2011).

Controlador

Es el que recibe el aviso de la interaccion del usuario y decide que es lo que hay que hacer.No se encarga de hacerlo, dado que para eso invoca al Modelo, es un archivo JavaScript elque controla ala Vista mencionada antes, por lo general con el mismo nombre que el archivoXHTML, que al cargarse inicializara todo el comportamiento inicial de la aplicacion y sedescargara de administrar la interaccion entre la vista y el modelo.

Modelo

Son distintos archivos JavaScript invocados desde el controlador. Son los que mantienenla logica del negocio, los que se comunican con el servidor cuando sea necesario y los que leavisan al controlador de los cambios en el estado (Firtman, 2008).

2.2.2. Navegador

En una arquitectura de tipo cliente-servidor, el usuario interactua y obtiene informaciondesde su computadora a traves de una aplicacion cliente. En la Web estas aplicaciones se co-nocen bajo el nombre generico de ”browsers”(tambien llamadas en nuestro idioma ”visores”,”visualizadores”, ”navegadores”o ”exploradores”), y cumplen dos funciones basicas:

1. Transmitir a los servidores remotos las ordenes que le imparte el usuario.

2. Presentar la informacion en forma asequible a quien la solicite (Valzacchi, 2003).

Segun Net MarketShare que incluye datos sobre la distribucion y el reparto del mercado denavegadores, sistemas operativos y buscadores en ordenadores personales, tabletas y telefonosmoviles, los tres principales navegadores usados en el ano 2017 fueron: Chrome con 58.90 %,Firefox con 13.29 % e Internet Explorer con 13.00 (NetMarketShare, 2018)

ECMAScript 6: Es un lenguaje de programacion orientado a objetos para realizar calcu-los y manipular objetos computacionales dentro de un entorno host. ECMAScript como sedefine aquı no pretende ser computacionalmente autosuficiente; de hecho, no hay disposicio-nes en esta especificacion para la entrada de datos externos o salida de resultados calculados.En su lugar, se espera que el entorno computacional de un programa ECMAScript propor-cione no solo los objetos y otras instalaciones descritas en esta especificacion sino tambienciertos objetos especıficos del entorno, cuya descripcion y comportamiento estan mas alla delalcance de esta especificacion excepto para indicar que puede proporcionar ciertas propieda-des a las que se puede acceder y ciertas funciones que se pueden invocar desde un programa

19

ECMAScript (International, 2015b).

2.3. Interfaz de Comunicacion

Los formatos para la transferencia de datos entre el FrontEnd y el BackEnd mas comunesy ligeros: XML y JSON, siendo este ultimo el que se elige por ser mucho mas practico demanejar.

2.3.1. JSON

JSON: (JavaScript Object Notation - Notacion de Objetos de JavaScript es un formatoligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras quepara las maquinas es simple interpretarlo y generarlo. Esta basado en un subconjunto delLenguaje de Programacion JavaScript, Standard ECMA-262 3rd Edition - Diciembre 1999.JSON es un formato de texto que es completamente independiente del lenguaje pero utilizaconvenciones que son ampliamente conocidos por los programadores de la familia de len-guajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estaspropiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos. JSON estaconstituido por dos estructuras:

Una coleccion de pares de nombre/valor. En varios lenguajes esto es conocido comoun objeto, registro, estructura, diccionario, tabla hash, lista de claves o un arregloasociativo.

Una lista ordenada de valores. En la mayorıa de los lenguajes, esto se implementa comoarreglos, vectores, listas o secuencias.

Estas son estructuras universales; virtualmente todos los lenguajes de programacion lassoportan de una forma u otra. Es razonable que un formato de intercambio de datos que esindependiente del lenguaje de programacion se base en estas estructuras (Json.org, 2013).

2.4. BackEnd

Frecuentemente un programador comienza creando una estructura de datos en un Len-guaje estructurado de consultas(SQL), y a continuacion escribe un programa en algun otrolenguaje (como PHP) para dar acceso a estos datos (Harris, 2009).

2.4.1. Base de Datos

Base de datos: Cada dıa, la mayorıa de nosotros nos encontramos con actividades querequieren algun tipo de interaccion con una base de datos (ingreso en un banco, reserva de

20

una entrada para el teatro, solicitud de una suscripcion a una revista, compra de productos,etc.) Estas interacciones son ejemplos de lo que se llama aplicaciones tradicionales de basesde datos (basicamente informacion numerica o de texto), aunque los avances tecnologicoshan permitido que tambien existan: bases de datos multimedia, sistemas de informaciongeografica (GIS), almacenes de datos, sistemas de proceso analıtico on-line, . . .

Una base de datos se entendera como una coleccion de datos relacionados entre sı yque tienen un significado implıcito.

Por datos queremos decir hechos conocidos que pueden registrarse y que tienen unsignificado implıcito.

Para manipular y gestionar las bases de datos surgieron herramientas software denomi-nadas: sistemas gestores de bases de datos. (Guevara, 2018).

Diagrama E-R

Los diagramas son simples y claros, cualidades que pueden ser responsables del amplio usodel modelo E-R. Tal dia grama consta de los siguientes componentes principales: Rectangu-los, que representan conjuntos de entidades.Elipses, que representan atributos.Rombos, que representan relaciones.Lıneas, que unen atributos a conjuntos de entidades y conjuntos de entidades a conjuntosde relaciones.Elipses dobles, que representan atributos multivalorados.Elipses discontinuas, que denotan atributos derivados.Lıneas dobles, que indican participacion total de una entidad en un conjunto de relaciones.Rectangulos dobles, que representan conjuntos de entidades debiles (Korth y Silberschatz,1993).

Normalizacion

La idea principal de la Normalizacion es la de separar nuestros datos o informacion enun serie de tablas que tengan relacion entre sı. Cuando una base de datos es disenada demanera correcta se evitan problemas con datos inconsistentes, problemas con los datos deoperacion y/o problemas con los campos listados. Para que una tabla de una base de datosse considere normalizada debe estar al menos en la tercera forma normal.Primera Forma Normal (Eliminar Campos Listados): Una tabla esta en la primera formanormal si y solo sı representa una relacion, no permite nulos o filas. El objetivo de esta formanormal eliminar repeticiones en la base de datos.Segunda Forma Normal (Eliminar Redundancias): Para que una tabla este dentro de la

21

segunda forma normal, debera estar en la 1FN y ademas cada uno de sus atributos no prin-cipales deberan de ser completamente dependientes de solo una llave primaria o candidata.Tercera Formal Normal (Asegura la dependencia Funcional) : Una tabla estara dentro de la3FN si esta dentro de la segunda forma Normal ademas debera tener una sola clave primariaen cada campo.(Elmasri, 2008).

22

Capıtulo 3

Estado del arte

Las investigaciones mencionados en esta seccion, son una recopilacion de resultados quese toman en consideracion por su alta relacion con el tema seleccionado, se han elegidoartıculos, tesis y un prototipo. Se ha buscado que las investigaciones relacionadas no pasende 6 anos de antiguedad, pues el area de Tecnologıas de la Informacion y Comunicacionesconstantemente ofrece nuevas mejoras.Lin & Chen muestran atraves de la aplicacion en proyectos reales como AJAX trabaja contipos de datos Diferentes, XML(mas robusto) y JSON(un poco mas ligero), se realizan doscomparaciones. La primera consiste en comparar la velocidad de transmision entre el clientey el servidor usando cantidades de datos entre 100 y 2000, dando menores tiempos los DatosJSON. La segunda comparacion es del lado del cliente, muestra como AJAX trabaja conlos dos formatos de datos(con cantidades de datos entre 100 y 500), dando menor tiempode respuesta y mayor estabilidad con JSON. Los autores consideran que AJAX-JSON y sucorrespondiente variedad de kit de desarrollo y sus caracterısticas de sintaxis concisas y legi-bles, proporcionan una gran comodidad para los desarrolladores de aplicaciones. (Lin, Chen,Chen, y Yu, 2012).Dhoti, & Sarate realizan un analisis de complejidad de pruebas de rendimiento en aplicacio-nes web basadas en Ajax, indican que las pruebas hechas comunmente a aplicaciones webtradicionales deben ser modificadas y mejoradas para entornos basados en AJAX, proponenen primer lugar definir metas de rendimiento y metricas relevantes, como utilizacion de lared, numero de calculos en el cliente o servidor y la capacidad de respuesta de la aplicacion,ası tambien se debera probar la matriz de compatibilidad con los navegadores, sistemas ope-rativos, hardware del cliente, topologıa de red y velocidades de red. Proponen pruebas deblackbox, que simulen las acciones de los usuarios en los navegadores. La atencion deberacentrarse en la estabilidad y los tiempos de respuesta. Los autores concluyen que para tenerexito, se debe identificar los desafıos especiales involucrados e incorporar soluciones en unametodologıa bien disenada (Dhote y Sarate, 2013).Bray, T. en el documento elimina las incoherencias con otras especificaciones de JSON yreparan los errores de especificacion y ofrece una guıa de interoperabilidad del formato. Eldocumento contiene la gramatica, tipos de datos y como expresarlos, ası como los valores

23

validos que se reconocen. Ademas se incluye informacion sobre los parsers y generadores, semenciona las aplicaciones que han usado JSON para intercambiar datos y finaliza comen-tando los problemas de seguridad con los lenguajes de scripting. (Bray, 2014).Chimoy Garcıa & all. desarrollan una tesis en la institucion educativa Salesiano: La imple-mentacion del sistema web en la institucion para optimizar los procesos administrativos.Utilizan el lenguaje de programacion del Hypertext Preprocessor (P.H.P) en base al modelo,vista, controlador (M.V.C) y como gestor de base de datos MySql que es de codigo abiertoy multiplataforma. Como resultado tienen un sistema donde registran, modifican o eliminanla informacion acerca de los alumnos, y de esta manera la institucion logro la disminucionde la perdida de informacion, tiempos de atencion mas cortos(de 40 min. a 17). (Chimoy,2016).Gude & Munawat realizan un estudio empırico sobre un gran corpus de programas escritosen JavaScript, puesto que los avances en este no han sido respaldados por estudios empıricosa gran escala. El documento abarca dos caracterısticas: Una es como se declaran las varia-bles, su alcance dentro del bloque y su alcance de la funcion, la segunda caracterıstica es laforma en que las sentencias for in son usadas. Los programas recolectados para el corpus seobtuvieron de 3 maneras: 1.-Rastreadores web, 2.- Lista de 100 sitios top y 3.- Complementosde Mozilla Firefox. El corpus fue analizado mediante Los complementos de Mozilla FirefoxV8 que es el motor de JavaScript de codigo abierto de Google. En los resultados, en el usode variables sugiere la declaracion de variables locales que se puede implementar medianteel estandar EcmaScript 6, para que las variables solo existan en el bloque declarado.(Gude,Hafiz, y Wirfs-Brock, 2014)Montenegro describe diferentes formatos de marcado que permiten generar fragmentos en-riquecidos dentro de una pagina Web, comenta que estos fragmentos permiten mejorar losresultados de busqueda en la web. Menciona que los fragmentos enriquecidos son entidadesusadas en las paginas Web para describir un tipo concreto de informacion. Comenta el autorque el objetivo del artıculo es mostrar paso a paso las actividades que deben ser ejecutadaspor un editor de paginas Web para enriquecer fragmentos de codigo HTML con informacionsemantica. Mejorando la visibilidad de sitios Web usando tecnologıa semantica (Montenegro,Ochoa, y Espinoza-Mejıa, 2016).Sanchez realiza una investigacion e implentacion de un ERP de gestion, que cubriera lasareas funcionales de la empresa Servi Frio. El autor realiza una aplicacion en un modelo deconexion de tres capas. La primera Capa (Capa de presentacion) utiliza un servidor apachey un framework de diseno bootstrap, la segunda capa (Capa de Negocio) es programada enPHP, recibe las peticiones hechas por el usuario desde la capa de presentacion y se envıanlas respuestas despues de realizar los procesos correspondientes, y por ultimo la tercera capa(Capa de Datos) cuenta con un motor de base de datos MySQL permite el almacenamiento,modificacion y extraccion de la informacion. El autor concluye que al usar herramientas deSoftware Libre se reducen significativamente los costos de implementacion y recomienda unmantenimiento periodico(Sanchez Lopez, 2017).Kulkarni et. all examinan los diferentes ERP en el mercado del entorno educativo. Primera-mente identifican los factores crıticos para cada una de las 6 fases, y elijen cuatro productos

24

con sus caracterısticas y definen sus caracterısticas principales. Seguido de ello proponen seispasos para una evaluacion ERP efectiva y seleccion de software, dentro de estos pasos resaltanuna Lista de requisitos genericos detallados que ayudan a analizar de manera cuantitativa.Realizan una tabla comparativa tomando en cuenta una muestra, indican la metodologıa ylos aspectos claves estudiados. Los autores consideran que esta eleccion y/o consideracionesse deben tomar mucho en cuenta, ya que las implementaciones pueden llegar a durar 10anos o mas. Los autores concluyen que el estudio ayuda a elegir la solucion correcta paralas instituciones educativas en funcion de los factores mencionados anteriormente(Kulkarniy cols., 2015).Wan Deng indican en su artıculo el diseno y la aplicacion de Front-End MVCC Frameworksoftware basado en la plataforma de gestion, proponen un modelo de desarrollo similar alMVC basado en el front end, combinado con las necesidades de la aplicacion web para me-jorar el codigo complejo que resulta al elaborar un proyecto de grandes magnitudes. Indicanque con el uso de JQuery para controlar la vista se vuelve cada vez mas obsoleto por lo quees necesario integrar caracterısticas de gestion para disenar frameworks distintos de JQuery.El modelo MVVW que proponen cuenta con enlace de datos bidireccional, modularidad,separacion entre el cliente y el servidor y el control de ruta. Los autores resumen medianteel modelo propuesto se puede desarrollar un sistema contractil y ampliable, que sea facil demantener(WANG y DENG, 2016).Huang & Sundberg registran una patente que ellos definen como: ”metodo, aparato y pro-ducto de programa utilizable por ordenador para almacenar datos de sesion del HTTP”, estese utiliza para introducir a un navegador web estados en dentro de una aplicacion. Comentanlos autores que otro metodo que existe actualmente para la persistencia de datos es almace-nar los datos de sesion mediante cookies, pero es frecuente que la configuracion del navegadorno permita almacenarlas y ademas estas son almacenadas en memoria lo que podrıa ocasio-nar que gran cantidad de informacion pudiera saturarle, tambien mencionan otros metodosmenos efectivos como reescritura de URL’s y almacenamiento de datos de sesion en una basede datos, siendo este ultimo mas lento para la recuperacion de datos.(Huang y Sundberg,2016)

25

Capıtulo 4

Desarrollo de la solucion

4.1. Herramientas

Estrictamente todas las herramientas son del tipo OpenSource, se utiliza; PHP Version7.1.1, HTML5, Apache Version 2.4.25, MariaDB Version 10.1.21, Sublime-Text Version 3(version sin registro). Se desarrollo sobre plataforma Windows y plataforma Linux. Comoparadigma de programacion, la orientacion a objetos (POO).

4.2. El enfoque del sistema

Se establecieron las siguientes premisas:

Mediante la reutilizacion y el uso de la herencia reducir al mınimo los codigos genera-dores de la interfaz de usuario y tambien la transferencia de la informacion entre losclientes y el servidor.

Un cliente web debe estar basado o extender un componente plantilla adaptativo.

Los principios de la POO deben prevalecer a lo largo de todo el desarrollo con lafinalidad de promover la creacion de componentes de software y la reutilizacion.

Todas las herramientas de desarrollo han de ser OpenSource en categorıa de estables.

La comunicacion entre los clientes y el servidor siempre sera asıncrona y solo seraposible mediante el listener del modulo BackEnd, el cual arbitra el acceso al servidor.

4.3. Diseno del FrontEnd

La Arquitectura de Software utilizada es inspirada en el MVC(Modelo Vista Controla-dor) al que se le adapto un Motor de Comunicaciones basado en Ajax. Los principios delMVC(Gonzalez y Romero, 2012) han sido la base de la Arquitectura aplicada, por ejemplo,

26

se aplica la separacion de los datos de la logica de negocio con la finalidad del mejoramientode reusabilidad, mantenimiento y escalabilidad del codigo. Con la utilizacion de este en-foquese estara previendo que, cuando se realice alguna modificacion en las vistas tenga el menorimpacto en la logica de los datos. En la figura 4.1 se describe los elementos.

Figura 4.1: Arquitectura MVC adaptadada al FrontEnd Fuente: Propia del Proyecto

4.3.1. Vista

En la vista destacan dos elementos implementados: El Diseno Web adaptativo y las Clasesutilizadas.

Diseno Web Adaptativo

Se aplican los principios de la web adaptativa (Marcotte, 2011). Marcotte indica que exis-ten tres elementos fundamentales para lograr un diseno web adaptativo, que son: CuadrıculaFluida, Imagenes Flexibles y Media queries.

Clases utilizadas

Dado el numero de veces que se podrıa ocupar en diferentes clientes el componente dematerias y tablas, se decidio la implementacion de las siguientes clases escritas en el len-guaje de programacion JavaScript que en conjunto son capaces de llevar una representacionorientada a objetos. De forma descendente la clase superior consume a la clase inferior comolo indica la Figura 4.3 y Figura 4.2. Actualmente se utiliza en el modulo de Alumnos y elModulo de Jefes de Carrera.Tabla: Con esta clase se define una estructura que puede agrupar uno o mas objetos detipo registro segun se requiera, esta agrupacion que se hace con la ayuda del contenedor divpermite representar la informacion al usuario final como una tabla.Registro:Permite la agrupacion multiples objetos de tipo Campo, tantos como sea necesarioincluir dentro de un mismo registro, para mostrarlos en la interfaz se utiliza un contenedor

27

de tipo div.Campo: Esta clase se utiliza para crear un campo que es la unidad mınima que contie-ne el dato JSON que estamos recibiendo, en el constructor se recibe nombre y contenido dedicho campo, estos datos se muestran en la interfaz por medio de un contenedor de tipo span.

Figura 4.2: Imagen muestra la manera en la que se consume cada una de las clases paraimplementar tabla, registro y campo.

Figura 4.3: Imagen muestra la manera en la que se consume cada una de las clases paraimplementar bloques, materias y materia.

28

4.3.2. Controlador

El cliente inicia con la clase modulo ev.js, la cual crea una instancia de modulo.js que asu vez extiende a sitm.js.En la clase modulo.js se definen los parametros necesarios para armar los componentes juntocon sus funciones, se agregan elementos en el area de contenido y se ob-tiene la Data enSession Store proveniente de la consulta hecha al BackEnd retornada por Ajax.js.La clase sitm.js es la plantilla y es la responsable del armado de la vista, en ella se realizanlas funciones de:

Designar la estructura y areas correspondientes para insertar cada componente.

Define la estructura de los componentes principales (Menu lateral, Menu superior yencabezado).

Define el comportamiento y las propiedades de cada componente principal.

Realiza el insertado de cada componente principal al finalizar su creacion

4.3.3. Interfaz de comunicacion

El segmento de interfaz de comunicacion esta constituido por la clase denominada ajax.jsque crea y envıa peticiones asıncronas de metodos AJAX consumiendo objetos de tipo Ec-maScript6 que son convertidos a JSON para ser enviados al servidor, este a su vez devuelveuna respuesta en formato JSON que se convierte en respuesta ES6 al cliente. JSON es con-sumido a traves de los metodos select, insert, update y delete que reali-zan consultas basicasa la base de datos de manera trasparente al cliente, mientras que el metodo method realizala solicitud para realizar una operacion al servidor donde se obtienen datos relevantes deacceso del cliente y mejorar la seguridad.

4.4. Diseno del BackEnd

Dada su magnitud, el BackEnd, fue enfocado desde una perspectiva Down-Top. Aplicandodiseno en espiral, la implementacion concluyo en cuatro clases, que, en conjunto, son capacesde llevar a cabo una representacion orientada a objetos de una base de datos y sus elementos.De forma descendente, la clase superior consume a la clase inferior, sin embargo, cada clasepor sı misma permite la construccion de objetos autonomos y autodescriptivos. En la Figura4.4 se resume la logica de implementacion aplicada.

4.4.1. Clases para describir el modelo de datos

Existen 4 Clases que forman parte del modelo de datos, programadas en PHP.Campo: Constituye el molde para crear la unidad mınima que puede ser representada en unsistema de bases de datos, el campo. Su constructor permite definir el nombre, el tipo de

29

Figura 4.4: Modelo de factorizacion Down-Top aplicado en la implementacion del BackEnd

dato e indicar si se trata de un campo clave. Posee tambien un metodo con el cual se puedegenerar una representacion JSON(International, 2015a) de sı mismo.Registro: Encapsula el conjunto de campos que definen un registro de base de datos. Emulan-do polimorfismo, su constructor permite crear objetos de diferentes mane-ras para satisfacerlas necesidades de construccion que fueron detectadas durante el diseno. Posee tambien unmetodo para crear un objeto JSON con la descripcion del registro y los valores de sus campos.Estos objetos tambien sirven de contenedores para las consultas o procedimientos almacena-dos donde el resultado es un valor o un solo registro. Adicionalmente es capaz de generar elcodigo SQL de las consultas SELECT, INSERT, UPDATE y DELETE tomando como basesu propia estructura y los valores de sus campos.Tabla: Los productos de esta clase son capaces de almacenar tantos objetos de tipo Registrocomo sean necesarios para describir la estructura de una tabla de base de datos, pueden serempleados para ejecutar procedimientos almacenados de la base de datos a la cual hayan sidoasociados en donde el resultado sea un valor, un registro o un con-junto de registros y soncapaces de contener el dataset resultante de una consulta SQL en array dinamico de objetosde tipo Registro. Su constructor polimorfico satisface las necesidades de creacion Tablas quefueron detectados durante el diseno. Adicional-mente es capaz de derivar los tipos de datosde los campos de los registros cuando el dataset resultante puede emitir uno u otro tipo dedatos.BD: Esta clase es una extension de la librerıa PDO(Popel, 2007) de PHP 7.0 que consigue co-

30

nectar de forma transparente a diversos gestores de bases de datos como MySQL o MarıaDB,MSSQL, Oracle y SQLite ente otros. Es capaz de contener un array de tablas o resultados deconsultas que pueden ser cargadas de inicio para poderlas enviar al cliente como un paquetede datos de tipo JSON. Puede ejecutar la operacion SELECT, INSERT, UPDATE Y DE-LETE de un registro o una tabla. Los descendientes de esta clase, quedan habilitados paraimplementar un Singleton y ası evitar la sobrecarga de conexiones que podrıa ocasionar unasolicitud masiva de peticiones de un cliente. Por defecto, el constructor de la clase conectacon un gestor MySQL.

4.4.2. Intercomunicacion con los clientes web

Como interfaz de comunicacion con los clientes web, se programo la clase “Proceso.php”lista para ser extendida para crear clases que definan el comportamiento de objetos cuyafuncion sera trabajar como un listener y dar atencion a los mensajes POST que llegan alservidor.Cada cliente que se comunique con el server debe hacerlo mediante una peticion asıncronade tipo AJAX y enviar/recibir datos en formato JSON. Inicialmente, el cliente solicitara alinterprete de PHP la creacion de un objeto listener especıfico, el cual, se mantendra a laescucha de sus peticiones y llevara a cabo las solicitudes de operacion que indique, siemprey cuando estas sean legales.El objeto listener, funge tambien como un arbitro que acepta o rechaza solicitudes y sirve deintermediario entre las bases de datos alojadas en el server y las necesidades de informaciony actualizacion de ellas que indican los clientes comunicantes, de tal forma que el acceso a lasbases de datos solo sera posible cuando la operacion solicitada sea legal, los parametros seanlos correctos y este expresado en el formato especıfico, de lo contrario, el servidor asumirauna amenaza de ataque y devolvera un mensaje de error que quizas terminarıa ocasionandoun mal funcionamiento en el cliente. Lo anteriormente descrito se muestra en la Figura 4.5.

4.5. Diagramas de Flujo

Se elaboraron diagramas de fluja para facilitar el entendiento de manera grafica el algorit-mo o proceso para cada una de las opciones del menu del modulo de jefes de carrera (Figura4.6) y ademas se indica el diagrama de flujo para la opcion de Carga Academica, siendo estaultima la clave y proceso principal del modulo anteriormente mencionado (Figura 4.7).

4.6. Diagramas de Clases

En los diagramas de clase que se muestran a continuacion(Figura 4.8 y Figura 4.9 ), sedescribe la estructura del sistema Front End mostrando las clases del sistema y sus relacionesentre ellos. En la Figura 4.8 se muestra el diagrama de clases del modulo Jefes de carrera y

31

Figura 4.5: Comunicacion de los diferentes cliente con el Servidor mediante peticiones Ajax.

en la Figura 4.9 se indica la herencia de los descriptores de la clase descriptor.php con queestan contenidas dentro del backend.

4.7. Diagrama de Secuencia

Los diagramas de secuencia mostrados a continuacion indican la interaccion entre elusuario, el Frontend y el Backend. El primer diagrama de secuencia ilustra el comportamientode la opcion de carga academica (ver Figura 4.10), seguido de el diagrama de secuenciapara la opcion de Especialidades dentro de la funcion de Configuracion (ver Figura 4.11),el diagrama para la opcion de Administrar Grupos la funcion de Configuracion (ver Figura4.12) y finalmente el diagrama para la opcion de Permisos de Inscripcion dentro de la funcionde Configuracion (ver Figura 4.13).

32

Figura 4.6: Diagrama de Flujo de carga de la Pantalla para el modulo de Jefes de Carrera.

33

Figura 4.7: Diagrama de Flujo de la Opcion Carga Academica.

34

Figura 4.8: Diagrama de Clases FrontEnd del modulo Jefes de carrera.

35

Figura 4.9: Diagrama de Clases de los descriptores del Backend.

36

Figura 4.10: Diagrama de Secuencia para la funcion de Carga Academica.

37

Figura 4.11: Diagrama de Secuencia para la opcion de Especialidades dentro de la funcionde Configuracion

38

Figura 4.12: Diagrama de Secuencia para la opcion de Administrar Grupos la funcion deConfiguracion

39

Figura 4.13: Diagrama de Secuencia para la opcion de Permisos de Inscripcion dentro de lafuncion de Configuracion

40

Capıtulo 5

Analisis de resultados

5.1. Pruebas de Verificacion y Validacion

Las pruebas de verificacion que se muestran a continuacion garantizan que el software seimplementa correctamente una funcion especıfica. Tal es el caso de la librerıa de mensajesque fue construida en base a las premisas que se establecieron dentro del desarollo de laprupuesta en el capıtulo 4.

5.1.1. Lıneas de Codigo: Libreria mensajes.js

Alertify.js1 es una pequena biblioteca que ofrece dialogos de navegador ligeros, boostrap-dialog es igualmente una librerıa de codigo abierto usada para el framework Boostrap2,mensajes.js es una pequena libreria creada esclusivamente para el proyecto sitm.

mensajes alertify boostrap-dialogVersion 1 1.11.0

Lineas de codigo 102 3595 1394Peso (kb) 6.4 136 47

Responsivo Si Si SiUso JQuery No No Si

Cuadro 5.1: Comparativa de la librerıa mensajes, alertify y boostrap.dialog en Javascript

Al comparar la libreria mensajes.js vs alertify y boostrap en cuadro 5.1.1, observamosque mensajes.js tiene menos lıneas y kb, por lo que la transferencia de datos entre el clientey el servidor se vera reducida, mantiene aun ası su diseno responsivo y elimina el uso deljquery haciendolo mas eficiente.

1Librerıa de codigo abierto, disponible desde http://alertifyjs.com/2Librerıa de codigo abierto, disponible desde https://getbootstrap.com/docs/4.0/

components/modal/

41

5.1.2. Analisis de Seguridad Web

Acunetix Vulnerability Scanner 3 es un aplicacion sobre un entorno web que realizapruebas de seguridad de aplicaciones web automatizadas. Se han sometido a un analisis lasaplicaciones web de SII Minatitlan 4, Veracruz5 y Ciudad Madero6, estos sistemas fueronelegidos debido a que a las Instituciones pertenecen al Tecnologico Nacional de Mexico, paraque el analisis fuera en igualdad de condiciones, el SITM se monto sobre un servidor ApacheVersion 2.4.34. A continuacion se comparan las vulnerabilidades de cada sistema SII y delSITM.

Sistema / Vulnerabilidades Alta Media Baja InformacionalSITM 0 0 3 14

SII Madero 20 24 3 24SII Veracruz 0 6 2 4

SII Minatitlan 5 5 3 1

Cuadro 5.2: Comparativa entre entre SITM e implementaciones del SII

En el cuadro 5.1.2 podemos ver como el SITM no tiene vulnerabilidades de alta magnitudcomparados con sistemas similares pertenecientes al TecNM. Las vulnerabilidades principalesque mostraron los SII de Madero y Minatitlan fueron de Inyeccion de Codigo SQL y Cross-site Scripting.

5.2. Compatibilidad entre navegadores

Debido a que los navegadores responden de diferente manera con un mismo codigo, setomo en cuenta los 3 navegadores mas utilizados actualmente: Chrome, Edge/IE y Firefox.A continuacion se muestran como el contenido se adapta a ellas Figuras: 5.1, 5.2, y 5.3,.

5.3. Diseno Responsivo en diferentes tamanos de Pantalla

En ambas Figuras 5.4 y 5.5 se puede ver como se distribuyen las pantallas en equiposcon diferentes sistemas operativos. Se tomaron como base 1 dispositivo por cada uno de lossistemas operativos mas utilizados (Mac OS, Android y Linux).

3Software para auditar seguridad Web, disponible desde https://www.acunetix.com/vulnerability-scanner/ version trial

4https://sii.itmina.edu.mx/5https://http://sii.itver.edu.mx/6https://http://sii.itcm.edu.mx//

42

Figura 5.1: Imagen del modulo Jefes de Carrera con el navegador Chrome.

5.3.1. Validacion de la Arquitectura

La validacion de la arquitectura y metedologıa propuesta se realizo mediante la construc-cion del modulo Adeudos, este modulo tienen Acceso tanto Jefes de Departamento donde serealizen prestamos o evaluaciones, ası como los alumnos. El objetivo fue demostrar que elsistema que se esta modelando con la arquitectura opera satisfactoriamente. En la Fig. 5.6se muestra el cronograma de actividades seguidas.

43

Figura 5.2: Imagen del modulo Jefes de Carrera con el navegador Edge

Figura 5.3: Imagen del modulo Jefes de Carrera con el navegador Firefox.

44

Figura 5.4: Imagen del modulo Jefes de Carrera, opcion carga academica.

Figura 5.5: Imagen del modulo Jefes de Carrera, opcion configuracion.

45

Figura 5.6: Cronograma de actividades modulo: Adeudos.

46

Capıtulo 6

Conclusiones y Trabajos futuros

6.1. Conclusiones

El proyecto SITM se encuentra en fase de desarrollo. Su enfoque orientado a componen-tes permite establecer un sistema de mantenimiento en cascada y hacerlo crecer mediante laintegracion de nuevos modulos que cumplan las premisas de desarrollo que fueron estableci-das.La capacidad de reutilizacion del modulo BackEnd y los componentes de la plantilla delFrontEnd podran ser utilizados en futuros desarrollos de software.Mediante la reutilizacion y la herencia se redujeron significativamente las lıneas de codigopor lo que la transferencia entre el cliente y el servidor sera mas rapida.El sistema en fase alfa mediante las pruebas de verificacion y validacion que se realizaronreflejaron un comportamiento aceptable frente a aplicaciones similares.Las pruebas de seguridad realizadas permitieron corroborar que el sistema no permite lainyeccion de codigo sql.

6.2. Trabajo futuro

Mediante la utilizacion de alguna tecnica de Inteligencia Artificial se propone realizar lageneracion automatica de horarios. La estructura actual de la base de datos permite crearmatrices de restricciones duras y blandas para optimizar horarios flexibles, que cumplan lasrestricciones duras y optimicen las restricciones blandas. Alguna de las tecnicas abordadasen la literatura, son los algoritmos geneticos, colonia de hormigas y sistemas multiagentes. Alconcluir la primera implantacion del sistema se procedera a agregar un modulo que integreal SITM la gestion de la biblioteca, tutorıas y los examenes en lınea.

47

Referencias

Bray, T. (2014). The javascript object notation (json) data interchange format.Chimoy, T. (2016). Implementacion de un sistema de matrıcula web para optimizar los

procesos administrativos utilizando la metodologıa del Modelo Vista Controlador enla Institucion Educativa Salesiano.

Dhote, M. R., y Sarate, G. (2013). Performance testing complexity analysis on ajax-basedweb applications. IEEE software, 30 (6), 70–74.

Elmasri, R. R. (2008). Fundamentals of database systems (n.o Sirsi) i9789701513286).Firtman, M. R. (2008). Ajax: Web 2.0 para profesionales (n.o Sirsi) i9789701513286).Gonzalez, Y. D., y Romero, Y. F. (2012). Patron modelo-vista-controlador. Revista Telem@

tica, 11 (1), 47–57.Gude, S., Hafiz, M., y Wirfs-Brock, A. (2014). Javascript: The used parts. , 466–475.Guevara, L. V. D. (2018). Gestion de bases de datos. https://media.readthedocs

.org/pdf/gestionbasesdatos/latest/gestionbasesdatos.pdf.Harris, A. (2009). Programacion con php 6 y mysql. Anaya Multimedia.Huang, S., y Sundberg, S. M. (2016, octubre 4). Implementing browser based hypertext

transfer protocol session storage. Google Patents. (US Patent 9,459,888)International, E. (2015a). 404: The json data interchange format. , 9 .International, E. (2015b). Ecmascript 6, tipo @ONLINE. Descargado 2018-

02-15, de https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

International, E. (2018). Ecmascript® 2018 language specification. https://media.readthedocs.org/pdf/gestionbasesdatos/latest/gestionbasesdatos.pdf.

Json.org. (2013). Introduccion a json. Descargado 2018-02-15, de https://www.json.org/json-es.html

Korth, H., y Silberschatz, A. (1993). Fundamentos de bases de datos. Madrid.Kulkarni, A., Hegde, N., Sharma, M., Kulkarni, A. A., Hegde, N., y Sharma, M. (2015).

Educational erp systems in the market a comparative study. International Journal ofInnovative Research Science in Technology , 1 .

Lin, B., Chen, Y., Chen, X., y Yu, Y. (2012). Comparison between json and xml in appli-cations based on ajax. , 1174–1177.

Marcotte, E. (2011). Responsive web design (2da Edition ed.). A Book Apart.

48

Montenegro, L., Ochoa, V., y Espinoza-Mejıa, M. (2016). Mejorando la visibilidad de sitiosweb usando tecnologıa semantica. Maskana, 6 (Ed. Esp.).

NetMarketShare. (2018). Browser market share. Descargado 2018-02-22, de https://netmarketshare.com

Pantoja, E. B. (2004). El patron de diseno modelo-vista-controlador (mvc) y su implemen-tacion en java swing. Acta Nova, 2 (4), 493.

Popel, D. (2007). Learning php data objects. Packt Publishing Ltd.Pressman, R. S. (2010). Ingenierıa del software (7ma Edition ed.). McGraw-Hill.Pressman, R. S., y Troya, J. M. (1988). Ingenierıa del software. McGraw Hill.Sanchez Lopez, S. I. (2017). Sistema erp orientado a la web para el control de inventarios de

productos y servicios de la empresa servi frio en la ciudad de quevedo. (B.S. thesis).Valzacchi, J. R. (2003). Internet y educacion aprendiendo y ensenando en los espacios

virtuales. INTERAMER.W3C. (2015). Hoja de estilo en cascada (css). Descargado 2018-02-16, de https://

www.w3.org/wiki/Es/CSSWANG, J.-y., y DENG, F. (2016). The design and application of front end mvvc framework

based on management platform. Destech Transactions on Engineering and TechnologyResearch(iceea).

49

Anexos

6.3. Encuesta sobre Navegadores mas utilizados

Los navegadores mas populares segun la W3Schools 1 que en base a mas de 50 millonesde visitas mensuales que recibe, arroja la siguiente informacion:

Navegador Chrome Edge/IE Firefox Safari OperaPorcentaje de uso 79.0 % 3.9 % 10.9 % 3.2 % 1.6 %

Cuadro 6.1: Uso de exploradores segun la w3Schoool para el mes de Mayo de 2018

En la tabla se puede notar como es que los principales navegadores utilizados son Chrome:Edge/IE y Firefox.

6.4. Codigo HTML

Actualmente se esta trabajando para el modulo de Jefes de Carrera, en el apartado deHorarios, donde inicialmente el Jefe de Carrera Visualizara las materias a ofertar en el semes-tre correspondiente. Inicialmente para elaborar el diseno se comenzo a realizar estaticamentepara generar la estructura y los estilos deseados.

Codigo HTML para generar materias dentro de contenedores estaticamente. Son 113lıneas.

Codigo JavaScript. Codigo de JavaScript Orientado a Objeto en el cual se crea el objeto”Materia”.

1 c l a s s mater ia {2 cons t ruc to r ( data ) {3 t h i s . html = ’<div c l a s s=” mater ia ”><span id=” mater ia ”>’+ data . mater ia +’</ span

> <span id=”Cl”>’+ data . c l ave +’</ span><span id=”Ht”>’+ data . hTeoria+’</span><span id=”Hp”>’+ data . hPract i ca +’</ span><span id=”Cr”>’+ data .Cred i tos +’</ span></ div> ’ ;

4 }5 }

1sitio web para aprender tecnologıas web en lınea, disponible desde https://www.w3schools.com/browsers// Mayo 2018

50

Codigo de JavaScript Orientado a Objeto en el cual se crea el objeto Contenedor”que con-tendra a varios objetos de tipo: ”Materia”. Son 5 lıneas.

1 c l a s s contenedor {2 cons t ruc to r ( t i t u l o , id , data ) {3 t h i s . html = ”” ;4 f o r ( var i = 0 ; i <data . l ength ; i++)5 {6 t h i s . html += new mater ia ( data [ i ] ) . html ;7 }8 t h i s . html = ’< s e c t i o n c l a s s=” contenedor ” id=” ’ + id +’”><h3>’+ t i t u l o +’</h3> ’

+ t h i s . html + ’</ s e c t i o n> ’ ;9 }

10 }

Codigo CSSCada estilo utilizado en el sistema esta mostrado a continuacion. Son 10 lıneas.

1 *{2 margin : 0px ;3 padding : 0px ;4 border : 0px ;5 font−f ami ly : Roboto , a r i a l , sans−s e r i f ;6 l i s t −s t y l e : none7 }89

10 . contenedor {11 padding : 20px 0px ;12 width : 94 %;13 margin :10 px 3 %;14 background−c o l o r : #FFF;15 d i s p l a y : f l e x ;16 f l e x−f l ow : row wrap ;17 j u s t i f y−content : c en t e r ;18 }1920 . contenedor h3{21 min−width : 96 %;22 he ight : 20px ;23 margin : 0 2 %;24 margin−bottom : 10px ;25 font−s i z e : . 9 rem ;26 }2728 #o b l i g a t o r i a s h3{29 c o l o r :#4F4F4F ;30 border−bottom : 1px s o l i d #4F4F4F ;31 }32

51

33 #bloque h3{34 c o l o r :#25B22A ;35 border−bottom : 1px s o l i d #25B22A ;3637 }3839 #o p c i o n a l e s h3{40 c o l o r :#E5B803 ;41 border−bottom : 1px s o l i d #F0F000 ;42 }4344 #c o n f l i c t o h3{45 c o l o r : red ;46 border−bottom : 1px s o l i d red ;47 }4849 . mater ia {50 border−rad iu s : 10px ;51 c o l o r : rgb (95 ,95 ,95 ) ;52 max−width : 191px ;53 width : 191px ;54 font−s i z e : . 8 rem ;55 min−width : 191px ;56 border : 1 px s o l i d rgb (264 ,264 ,264) ;57 he ight : 160px ;58 margin : 5px 5px ;59 d i s p l a y : f l e x ;60 f l e x−f l ow : row wrap ;61 font−weight : l i g h t e r ;62 }6364 . mater ia : hover{65 background : #f 2 e f f 1 ;66 t r a n s i t i o n−durat ion : . 5 s ;67 cur so r : po in t e r ;68 }6970 #bloque . mater ia {71 border : s o l i d 3px #25B22A ;72 c o l o r : #000;73 }7475 #o p c i o n a l e s . mater ia {76 border : s o l i d 3px #F0F000 ;77 }7879 #o b l i g a t o r i a s . mater ia {80 border : s o l i d 3px #444343;81 }8283 #c o n f l i c t o . mater ia {

52

84 border : s o l i d 3px red ;85 }8687 #mater ia {88 he ight : 94px ;89 width : 100 %;90 text−a l i g n : c en t e r ;91 d i s p l a y : f l e x ;92 a l i gn−i tems : c en t e r ;93 j u s t i f y−content : c en t e r ;94 }9596 #Cl{97 border−top : 1 px s o l i d rgba ( 0 , 0 , 0 , 0 . 5 ) ;98 border−bottom : 1 px s o l i d rgba ( 0 , 0 , 0 , 0 . 5 ) ;99 he ight : 30px ;

100 width : 100 %;101 j u s t i f y−content : c en t e r ;102 d i s p l a y : f l e x ;103 a l i gn−i tems : c en t e r ;104 }105106 #Ht , #Hp, #Cr{107 width : 32.3 %;108 text−a l i g n : c en t e r ;109 he ight : 30px ;110 j u s t i f y−content : c en t e r ;111 d i s p l a y : f l e x ;112 a l i gn−i tems : c en t e r ;113 }114115 #Hp{116 border− l e f t : 1 px s o l i d rgba ( 0 , 0 , 0 , 0 . 5 ) ;117 border−r i g h t : 1 px s o l i d rgba ( 0 , 0 , 0 , 0 . 5 ) ;118 }

53

Figura 6.1: Resultado de JavaScript Orientado a Objetos.

54

Figura 6.2: Plan de Estudios Ing. Ambiental.

55

Figura 6.3: Plan de Estudios Ing. Bioquımica.

56

Figura 6.4: Plan de Estudios Ing. Civil.

57

Figura 6.5: Plan de Estudios Ing. Electromecanica.

58

Figura 6.6: Plan de Estudios Ing. en Gestion Empresarial.

59

Figura 6.7: Plan de Estudios Ing. Industrial.

60

Figura 6.8: Plan de Estudios Ing. Petrolera.

61

Figura 6.9: Plan de Estudios Ing. en Sistemas Computacionales.

62

Figura 6.10: Plan de Estudios Ing. en Tecnologıas de la Informacion y Comunicaciones.

63