UNIVERSIDAD VERACRUZANA. Diseño de un prototipo de Mesa de Ayuda en ambiente Web (JSP-Ajax) T E S I S. para obtener el Título de:

Transcripción

1 UNIVERSIDAD VERACRUZANA Facultad de Contaduría y Administración Diseño de un prototipo de Mesa de Ayuda en ambiente Web (JSP-Ajax) T E S I S para obtener el Título de: Licenciado en Sistemas Computacionales Administrativos Presenta: Citlali Rodríguez Ceballos Asesor: MTI. Raúl De La Fuente Izaguirre Xalapa-Enríquez, Veracruz Noviembre 2013

2

3 UNIVERSIDAD VERACRUZANA Facultad de Contaduría y Administración Diseño de un prototipo de Mesa de Ayuda en ambiente Web (JSP-Ajax) T E S I S para obtener el Título de: Licenciado en Sistemas Computacionales Administrativos Presenta: Citlali Rodríguez Ceballos Asesor: MTI. Raúl De La Fuente Izaguirre Xalapa-Enríquez, Veracruz Noviembre 2013

4 AGRADECIMIENTOS Antes que nada quiero agradecer a mi Mami cuyo cariño y comprensión me han acompañado a lo largo de mi vida y mi carrera, y seguramente me acompañaran hasta el día que muera, porque sin su apoyo, confianza e inmensa paciencia no habría podido lograr hoy uno de mis anhelados sueños y metas. Gracias por sacrificar cada pensamiento e incluso alegría y comodidad en mi felicidad y la de mis hermanas, te debemos todo lo bueno que hoy en día somos. A mi Papá por darme los sustentos económicos y la determinación de estudiar y superarme y hoy poder culminar mi carrera. A mis hermanas Xo y Ame por ser mis amigas de siempre, mis compañeras incondicionales por ser un ejemplo de superación y dedicación. Gracias Xo por darme la oportunidad de conocer el amor sincero e inocente de tres angelitos que llegaron a llenarnos de alegría y a motivarnos a seguir adelante; Rubí, Alexa y Naomi. Gracias Ame porque siempre fuiste nuestro ejemplo y nuestro soporte. A esos amigos que me han acompañado a lo largo de mi carrera, o aquellos de antaño que tengo la fortuna de seguir contando con su amistad y cariño, por aquellos que en poco tiempo se volvieron especiales, por todas las memorias juntos: Irmita, Arturo, Dare, Luis, Miguel, Alberto, Manuel, Alejandro, Danfer y Jesús. Gracias a mi sección 02 y a los chicos comité, siempre los llevare como un gran recuerdo de compañerismo. Al Departamento de Atención Técnica a Usuarios por las facilidades que me brindaron para la realización de esta tesis, en especial a mi jefe y a todos los miembros del departamento quienes han sido muy amables, por su alegría y ese gran ambiente de trabajo. A Carlos por encaminarme en este inmenso mundo del JSP, por tu paciencia y compañerismo, gracias.

5 A mi asesor el maestro Izaguirre, gracias por creer en mí, por siempre tener altas expectativas de mis capacidades, por sacarme de aquella clase que quedara para la historia, por su apoyo y paciencia para la realización de este proyecto, gracias. A mis sinodales la maestra Patricia y la maestra Mayra por el tiempo que dedicaron a este trabajo y porque tuve la fortuna de tener a ambas como catedráticas de las que me llevo un gran aprendizaje, gracias. Y por supuesto a mi novio, compañero y mejor amigo, con quien he vivido momentos llenos de felicidad; Ernesto, cuya compañía, comprensión y amor han marcado mi vida, por aguantar mis malos ratos y por estar siempre lleno de sorpresas y detalles, por entender mi forma de ser y no intentar cambiarme, por todas las aventuras que hemos vivido y las que viviremos juntos, gracias. A todas las personas que me acompañaron y que participaron directa o indirectamente en la culminación de esta meta, por su amistad y cariño, gracias. En memoria de quienes hoy ya no están conmigo, siempre llevaré su recuerdo y sus enseñanzas. Para luna, me diste pocos pero maravillosos días en los que pude disfrutar de tu compañía y afecto, te recordare siempre, si existe otro lugar ahí te volveré a ver. Lo único que nos da miedo cuando nos asomamos a la muerte y a la oscuridad es lo desconocido. *Albus P. W. B. Dumbledore Kelpie

6 ÍNDICE RESUMEN... 1 INTRODUCCIÓN... 2 CAPÍTULO I: MARCO CONTEXTUAL Antecedentes Definición del problema Objetivos General Específicos Limitaciones Justificación Hardware y software Situación actual Hipótesis CAPITULO II: MARCO TEÓRICO Java Server Pages (JSP) Ventajas JSP Elementos de JSP Elementos de scripts Directivas JSP Acciones JSP Objetos implícitos JSP Ajax Ventajas representativas del uso de Ajax Inconvenientes de la utilización de Ajax Funcionamiento de Ajax Métodos y propiedades del objeto XMLHttpRequest Seguridad JavaScript Ventajas y desventajas III

7 2.4 Frameworks y librerías JQuery Características Funciones para AJAX Eclipse Apache Tomcat SQL Server 2008 Management Studio Express CAPITULO III: DISEÑO DEL PROTOTIPO Metodología: Modelo por prototipos Identificación de requerimientos Análisis de requerimientos Requerimientos funcionales Requerimientos no funcionales Estructura de la Base de Datos Diseño de la Base de Datos Servidores Descripción de tablas Diagrama Entidad-Relación Prototipo inicial Proceso del Departamento de Atención Técnica a Usuarios Modelo jerárquico de la aplicación Código y estructura del prototipo Optimización de procedimientos almacenados Interfaz Grafica CAPITULO IV: RESULTADOS Evaluación Cualitativa Cuantitativa Aplicación actual vs Prototipo Análisis e interpretación de resultados Diseño y aplicación del instrumento Análisis IV

8 4.3.3 Resultados Interpretación de resultados CONCLUSIONES FUENTES DE INFORMACIÓN ANEXO I ANEXO II ANEXO III GLOSARIO ÍNDICE DE FIGURAS ÍNDICE DE TABLAS ÍNDICE DE GRÁFICAS V

9 RESUMEN Una de las formas de administrar los problemas de tecnología de información que utilizan actualmente las empresas es la creación de una Mesa de Ayuda, la Universidad Veracruzana forma parte de estas instituciones, controla un número de incidencias que deben atenderse y solucionarse que está en constante crecimiento. Es por ello que se plantea la propuesta de mejorar el funcionamiento y eficacia de la Mesa de Ayuda utilizada, debido a que ha presentado lentitud en su ejecución aumentando esta en los diferentes campus con los que cuenta. Se presenta un prototipo apoyado de Ajax y basado en JSP que fusione sus beneficios y ofrezca una versión tangible de su funcionalidad y agilización. En el presente trabajo se describe el análisis y diseño del prototipo propuesto y finalmente se contrasta con la aplicación que actualmente se utiliza para probar así la mejora en su diseño, ejecución y funcionamiento. 1

10 INTRODUCCIÓN

11 Día con día los sistemas de información evolucionan, en cualquier ambiente que se desarrollen, en un principio las características de un sistema de información se basaban principalmente en el cumplimiento de las tareas que se pretendía que lograran, actualmente se busca un sistema que cumpla pero que a su vez ofrezca una alternativa que fusione la rapidez, sencillez y funcionalidad, un sistema con un gran número de código y con un gran tamaño de componentes no está directamente ligado con un funcionamiento eficaz y eficiente. En este caso los sistemas de información en ambiente web SIAW, se han convertido en la forma más utilizada de comunicación empresarial, por la infinidad de beneficios que brindan, tanto para los directivos como para los usuarios finales directos. La información oportuna en las organizaciones es una de las necesidades más importantes, así como la comunicación entre los niveles jerárquicos que son aún muy lejanos en algunos casos, así bien cada departamento dentro de una organización requiere cierto tipo de información para trabajar, y es exactamente esta necesidad de información la que nos lleva siempre a querer tenerla en tiempo y forma. Estas necesidades dentro de la Universidad Veracruzana son hoy una realidad electrónica, dado que la institución ha progresado de forma importante y necesita que cada día la información sea centralizada debido a sus diversos campus ubicados alrededor del estado de Veracruz: Poza Rica, Veracruz, Xalapa, Orizaba y Coatzacoalcos. La Universidad Veracruzana es una institución de nivel superior reconocida en todo México por sus investigaciones, docentes y destacados alumnos, se fundó el 11 de septiembre de 1945 y ha ido evolucionando, con una comunidad que asciende a los 80 mil estudiantes, académicos y administrativos. Hoy por hoy la Universidad Veracruzana tiene un gran prestigio y cuenta con múltiples certificaciones, además que cuenta con un portal electrónico mediante el 3

12 cual no solo da a conocer sus diversos campus y facultades, sino que también le permite tanto a administrativos, académicos y alumnos, tener acceso a la información que necesitan, no solo las calificaciones de los alumnos si no también, múltiples módulos que permiten llevar a cabo una administración de la institución. De forma particular el Departamento de Atención técnica a Usuarios, lleva uno de los registros más importantes de información dentro de la Universidad Veracruzana, ya que realiza un reporte de las incidencias ocurridas periódicamente dentro de la institución, de forma que sirva como apoyo para la toma de decisiones. Previamente todos los reportes se tenían que entregar en programas como Excel, posteriormente se comenzó la iniciativa de desarrollar un software que cubriera con estas necesidades, de forma que se pensó como un sistema de ambiente web que permitiera la interacción no solo de los técnicos sino también de los solicitantes del servicio. Es así como surge la aplicación de La mesa de ayuda que hoy es la encargada de llevar un control de los reportes solicitados por los usuarios, así como las causas de las incidencias más frecuentes, tiene un control de los diferentes técnicos que pueden atender los servicios además de un historial de los usuarios con más problemáticas presentadas. De forma general tiene el objetivo de establecer un punto de contacto único para el reporte y solución de incidencias y/o servicios en el uso y manejo de Tecnologías de Información. La aplicación fue desarrollada en el año 2011 con una visión a largo plazo que superó las expectativas dentro del departamento, por lo que se liberó para las regiones un año después y fue entonces cuando la lentitud de la aplicación se hizo evidente, no solo por el largo trayecto de las llamadas del servidor que actualmente se encuentra en Xalapa, sino también porque al crecer los usuarios creció también el tráfico de procedimientos, y la evidencia de que el desarrollo de la aplicación podría ser optimizada. 4

13 En el año actual se tenía la visión de que existía una tecnología que podría mejorar el rendimiento de la Mesa de Ayuda, esta tecnología es Ajax, a pesar del desconocimiento sobre la tecnología se tenía la idea de lo que podría llegar a hacer por ella, y es así como surge la iniciativa de desarrollar un prototipo que se apoye de Ajax para mejorar el rendimiento de la aplicación. Es por esto que el prototipo se convierte en una versión tangible de lo que se podría llegar a lograr con ayuda de esta tecnología, dentro de la aplicación de la mesa de ayuda, que nos ayudaría a comprobar si realmente Ajax puede mejorar en cuanto a rapidez la aplicación actual. Este trabajo de tesis es para recibir el grado de Licenciado en Sistemas Computacionales Administrativos por parte de la Universidad Veracruzana. En esta tesis se desarrolla un prototipo de mesa de ayuda en ambiente web, basada en el lenguaje de programación JSP y apoyado de Ajax. El trabajo está dividido en cuatro capítulos que se distribuyen de la siguiente forma; el primer capítulo se refiere a todo el marco contextual del trabajo que se refiere a los objetivos, las limitaciones, así como todo lo que gira alrededor de la realización de este trabajo, el segundo capítulo nos da una marco teórico de la realización de este trabajo, abarcando desde el lenguaje JSP su concepto y funcionamiento, el concepto de Ajax sus ventajas e inconvenientes, así como de un leve panorama de las herramientas externas que se usan como complemento, y finalizando con el software utilizado para la realización del prototipo. El tercer capítulo se enfoca en el análisis y desarrollo del prototipo, el cual incluye la descripción del proceso de atención dentro del departamento de atención técnica a usuarios, la descripción de la base de datos, así como de una breve descripción de algunas de las modificaciones para el prototipo y la interfaz final de este. Por último el cuarto capítulo se enfoca a los resultados obtenidos del prototipo en contraste con la aplicación actual. 5

14 CAPÍTULO I: MARCO CONTEXTUAL

15 1.1 Antecedentes En la actualidad no existe ningún trabajo recepcional dentro de la Universidad Veracruzana en el cual se desarrolle una Mesa de Ayuda, o algún sistema de información con el lenguaje Java Server Page (JSP), ya que la mayoría de los estudiantes ha utilizado como lenguaje básico PHP. Se han desarrollado ya los temas que se manejaran aquí, por ser un prototipo Web el que se desarrollará, tales como CSS, JavaScript y Ajax (en complemento del lenguaje PHP). Pero hoy en día, las instituciones utilizan en su mayoría los lenguajes populares y han pasado por alto las alternativas que existen de programación web, en el Departamento de Atención Técnica a Usuarios de la Universidad Veracruzana se pretende fomentar el manejo de este lenguaje de programación, que en su mayoría no se le da la oportunidad debido al desconocimiento tanto de usuarios como de analistas y/o programadores y es por ello que su aplicación utiliza JSP como lenguaje base. 1.2 Definición del problema Como se mencionó la Mesa de ayuda que actualmente se utiliza dentro del Departamento de Atención Técnica a Usuarios, ha presentado algunos inconvenientes en cuanto a los tiempos de respuesta en el sistema en ámbito local y en mayor medida en las diferentes regiones con las que cuenta la institución, evidenciando en problema de lentitud que podría ir en aumento de no hacerse algo al respecto, por el constante crecimiento tanto de la institución como del alcance de la aplicación. 7

16 Actualmente se requiere que los sistemas que se utilizan dentro de las organizaciones, realmente cumplan con su objetivo, que es el facilitar el acceso a la información a distancia. Por lo tanto es sumamente importante la agilidad con la que cualquier transacción se realice en casi cualquier punto del mundo. 1.3 Objetivos General Diseño de un prototipo en base a una réplica actual de la Mesa de Ayuda, utilizando las nuevas tecnologías que permitan una vista más amable al público y que a su vez agilicen la respuesta del sistema Específicos Adquirir y reafirmar conocimientos en el desarrollo de aplicaciones ejecutadas en un servidor institucional en lenguaje JSP y SQL Server como manejador de base de datos. Investigar y aplicar conocimientos de marcos de trabajo basado en JavaScript que le permitan a la aplicación ofrecerle al usuario una mejor experiencia. Estructurar y aplicar consultas mediante procedimientos almacenados que permitan la disminución de llamadas al servidor y por lo tanto optimicen el tiempo de respuesta. Evaluar y comparar el sistema actual contra el prototipo propuesto. 1.4 Limitaciones Diseño y comparación del prototipo con la actual Mesa de ayuda. Realización una nueva página principal de acuerdo al formato actual del portal de la Universidad Veracruzana. 8

17 Implementación de librerías OpenSource y/o frameworks desarrollados a base de JavaScript que nos permitan realizarlo de una forma más sencilla, eficaz y con mayor amigabilidad. El prototipo estará orientado a los usuarios por lo tanto las formas optimizadas serán las que sean de mayor impacto a este. 1.5 Justificación El Departamento de Atención técnica a usuarios ha crecido en cuanto a su recepción de información y la necesidad de ella, en la medida en que la Universidad Veracruzana ha aumentado la cantidad de equipos dentro de la institución, así como a su vez el número de personal que lo opera también crece constantemente. Es por ello que existe la necesidad de ofrecer un servicio que cada día sea más rápido y fácil de navegar por parte de los usuarios, por lo tanto se requiere una optimización de la actual mesa de ayuda que permita mejorar el tiempo de respuesta de la aplicación ante el incremento de usuarios que necesitan la atención que se brindan dentro del departamento. 1.6 Hardware y software Debido a que únicamente será un prototipo (no liberado), se desarrollara en base a una réplica de la Mesa de Ayuda actual, siguiendo el esquema de lenguaje de programación JSP (Java Server Page). El software utilizado para el desarrollo será Elipse, que es un software libre y multiplataforma que nos servirá para gestionar todo el proyecto sobre el que se trabajará, y que además provee un servidor local mediante el cual se pueden realizar pruebas. Además de que se trabajará con una réplica actual de la base de datos utilizada dentro del departamento, la cual utiliza el manejador de datos SQL Server

18 Management Studio Express, en el que se incorporaran nuevos procedimientos almacenados. Hardware sobre la que se realizó el prototipo: Computadora de escritorio HP 4.0 GB en memoria RAM Servidor de pruebas. Software utilizado para el desarrollo: Sistema Operativo Windows 7 Professional Eclipse Apache Tomcat SQL Server 2008 Servidor de desarrollo Sistema operativo Windows 7 Professional SQL Server 2008 Management Studio Express Servidor Apache Tomcat Servidor de pruebas Sistema operativo Debian Server. 1.7 Situación actual La Mesa de Ayuda dentro de la Universidad Veracruzana ha venido funcionando de manera correcta, pero posiblemente poco optimizada debido a los siguientes problemas detectados: Presenta lentitud al momento de cargar los JSP que contiene la página maestra. Tiene desarrollo CSS pero con posibilidades amplias de optimización. 10

19 Recurre a muchas llamadas de procedimientos almacenados, lo cual se ve reflejado en el rendimiento general de algunos de los JSP. Otro de los inconvenientes es la falta de conocimiento que tienen los usuarios de la existencia del portal de la mesa de ayuda. Es por esto que se ha optado por probar una solución que incluya las posibilidades que brinda Ajax para mejorar el rendimiento de la aplicación. 1.8 Hipótesis Puede la implementación de tecnologías actuales en desarrollo web como Ajax y la disminución de procedimientos almacenados en la estructura actual de la Mesa de ayuda, lograr una mejora en la eficacia y rapidez de respuesta de la aplicación? 11

20 CAPITULO II: MARCO TEÓRICO

21 2.1 Java Server Pages (JSP) La tecnología JSP (Java Server Pages) es una especificación abierta desarrollada por Sun Microsystems como una alternativa a Active Server Pages (ASP) de Microsoft. Muchos de los servidores de aplicaciones comercialmente disponibles (como BEA WebLogic, IBM WebSphere, Live JRun, Orion, etcétera) ya utilizan tecnología JSP. Esta tecnología permite desarrollar páginas web con contenido dinámico y supone una evolución frente a la tecnología CGI, y los Servlets. Un fichero JSP puede contener etiquetas HTML normales, y elementos especiales para generar el contenido dinámico. Base de datos Regresa Datos Ejecuta PA Servlet Cacha variables Envía variables JSP Figura 2.1 Funcionamiento de JSP-Servlet (elaboración propia). 13

22 La página JSP pasa por tres etapas en la evolución de su código, administradas por el contenedor de JSP: Código fuente JSP: lo escribe el desarrollador, se encuentra en un archivo de extensión.jsp en el que se mezcla HTML y código Java, con el fin de generar una página Web para dar servicio a una petición de usuario. Código fuente Java: el contenedor de JSP traduce el código fuente JSP a código fuente de un Servlet Java equivalente. Clase Java compilada: Como cualquier otra clase Java compilada el código Servlet se compila en una clase Java que se guarda en un fichero.class preparado para ser cargado y ejecutado. En caso que se modifique el código fuente JSP el contenedor vuelve a hacer todo el proceso de recompilado automáticamente basándose en la situación temporal del archivo. De esta forma aunque es muy costoso crear el Servlet cuando se hace la primera petición, las posteriores peticiones no provocan volver a pasar por todos los pasos, por lo que es una buena práctica que el desarrollador visite la página por primera vez, para que cuando llegue el primer cliente obtenga una respuesta rápida Ventajas JSP Podemos crear aplicaciones web que se ejecuten en varios servidores web, de múltiples plataformas, ya que Java es en esencia un lenguaje multiplataforma. Las páginas JSP están compuestas de código HTML/XML mezclado con etiquetas especiales para programar scripts ejecutables en el servidor en sintaxis Java. Por lo tanto, las JSP podremos escribirlas con nuestro editor HTML/XML habitual. Es compatible con todas las librerías actuales que inicialmente están pensadas o mayormente documentadas para PHP. 14

23 2.1.2 Elementos de JSP Además del HTML normal, hay tres tipos de construcciones JSP que se embeberán en una página: elementos de script, directivas y acciones. Como se describen en los siguientes apartados Elementos de scripts Son elementos que se pueden mezclar en acciones y plantillas y existen diferentes como: Comentarios: Su sintaxis es <%-- comentario%>, a diferencia de los comentarios escritos en código HTML (<!--comentario>) no se muestran en el navegador, lo que hace que sea más seguro para el desarrollador realizar anotaciones en el código. Expresiones: Su sintaxis es <%=expresión%>, operaciones que pueden ser evaluadas y que devuelven un valor determinado en la página, pudiendo ser utilizado como valor de cualquier elemento HTML y que sustituye el código completo de.out.print() La expresión indicada es evaluada y ejecutada por el compilador JSP, sustituyendo la etiqueta completa por el valor que se genera como resultado de la ejecución de dicha expresión. Puede tomar el valor tanto de variables recibidas desde el servlet principal del JSP, como de cualquier librería interna de java. Declaraciones: Su sintaxis es <! Declaraciones> se utiliza esta sintaxis para declarar tanto variables como funciones como parte de la clase servlet, lo que significa que el contenido de estas etiquetas es insertado directamente en el cuerpo del servlet. 15

24 Podrán ser utilizadas de igual forma en expresiones o scriptlets de la misma página. Scriptlets: Su sintaxis es <% Cualquier código java %> son trozos de código Java que se pueden insertar dentro de las página JSP para realizar cualquier tipo de procesamiento lógico (no generan ninguna salida directa como ocurre con las etiquetas de "Expresiones"). El contenido de estas etiquetas es insertado directamente en la función "_jspservice()" de la clase servlets a que es convertida la página JSP, por lo que podrán contener definición de variables (que serán locales a dicha función, y no miembro de la clase), pero no de funciones. Desde estos scripts se tiene acceso a las variables predefinidas (objetos implícitos). Estos scripts pueden contener sentencias condicionales, iterativas, etc., ya que el código utilizado es Java, y de esta forma se tiene toda la funcionalidad del mismo. Un posible ejemplo que muestra un mensaje distinto en función de un valor aleatorio sería el siguiente: <% if (Math.random() < 0.5 ) { %> Mensaje 1 <% } else { %> Mensaje 2 <% } %> Asimismo, otro ejemplo con la declaración de una variable, que sería local a la función "_jspservice()" sería: <%! int var = 1; if (1 < int) int var2 = 0; else int var3 = 1; %> 16

25 2.1.4 Directivas JSP Proporcionan al motor JSP información sobre lo que éste debe hacer a la hora de procesar la página. Estas acciones pueden ser estándar (ya definidas por la especificación JSP) o etiquetas personalizadas. Las directivas son instrucciones procesadas por el compilador JSP cuando la página se compila a un Servlet. En JSP se definen tres tipos diferentes de directivas: 1) Include La sintaxis que presenta esta directiva es la siguiente: <%@ include file="url_relativa_del_fichero_a_incluir" %> (directiva de inclusión de ficheros): sirve para insertar ficheros en una página en el momento en que ésta es solicitada, de modo que el contenido del fichero indicado se inserta directamente sin su interpretación previa. (y no cuando se traduce a servlet). 2) Page La sintaxis que presenta es la siguiente: <%@page contenttype="text/html" pageencoding="utf-8"%> <%@page import="ejemplo.clasedeejemplo"%> (directiva de página): se usa para definir atributos que se aplican a toda página JSP completa así como a cualquier fichero estático que se incluya con la directiva include o "<jsp:include>" (no se aplican sobre ficheros dinámicos incluidos). Esta directiva puede usarse más de una vez en una misma página JSP, aunque por norma general su situación siempre suele estar al comienzo del fichero. Si se usa en múltiples ocasiones, nunca se deberán asignar diferentes valores para el mismo atributo, salvo en el caso del atributo import, el cual, dado que su semántica es similar al import de Java, puede usarse una vez por cada fichero a importar. Como atributos destacables podemos citar los siguientes: 17

26 language="java": define el lenguaje de script usado tanto en los scripts como en las declaraciones y expresiones del fichero JSP y de cualquier fichero incluido. En la especificación actual de JSP el único lenguaje permitido es Java, por lo que este atributo, en caso de especificarse, tendrá siempre este valor. import="{paquete.clase paquete.*},...": indica una lista (separada por comas) de uno o más paquetes o clases que el fichero JSP debería importar. De esta manera, las clases importadas pueden ser utilizadas por los scriptlets, expresiones, declaraciones y etiquetas del fichero JSP. errorpage="url_relativa": indica un fichero que se encargará de manipular las excepciones que se produzcan. contenttype="{tipomime [ ; charset= juegocaracteres ] text/html ; charset = ISO }": indica el tipo de contenido que se envía como respuesta al cliente así como el juego de caracteres utilizado (por defecto se usa el juego de caracteres europeo normal). c) Taglib La sintaxis de esta directiva es la siguiente: <%@ taglib uri="uridelalibreríadeetiquetas" prefix="prefijolibrería" %> (directiva de librería de etiquetas): permite ampliar el conjunto de etiquetas que el intérprete JSP puede usar, ampliando así de manera casi ilimitada la funcionalidad del mismo. Su sintaxis contiene los siguientes atributos uri="uridelalibreríadeetiquetas": dirección absoluta (posición dentro el árbol de directorios "WEB-INF") o relativa (nombre virtual definido desde el descriptor de despliegue de la aplicación "web.xml") del descriptor de despliegue de la librería de etiquetas (TLD). 18

27 prefix="prefijolibrería": prefijo a usar dentro de la página para hacer uso de las etiquetas definidas en la librería de etiquetas indicada (pudiendo tener así etiquetas con igual nombre en distintas librerías). Cada etiqueta podrá ser accedida mediante "prefijolibrería:nombreetiqueta" Acciones JSP Proporcionan información global de la página e indican lo que el motor JSP debe hacer con la página JSP a la hora de la traducción de la página a servlet. Las acciones son el elemento que se encarga de controlar el funcionamiento del motor JSP y siguen el formato clave/valor: <accion parametro=valor... /> Las distintas directivas JSP son las siguientes: a) jsp:forward: sirve para reenviar la petición a otra página que se especifica en el único atributo "page" que esta acción contiene. b) jsp:include: sirve para incluir ficheros dentro de la página JSP cuando ésta es traducida a un servlet. El texto que se inserta en la página JSP debe corresponder siempre a código estático, de manera que si el fichero referenciado es: o o Estático (en general, código que no debe contener las etiquetas "<html>", "</html>", "<body>" ni "</body>"): el texto del fichero se añade al fichero JSP como si fuera parte del mismo. Dinámico (otro fichero JSP o un fichero Java): el fichero se procesa y el resultado estático que se genera es lo que se inserta en la página JSP. c) jsp:usebean: permite cargar y utilizar un JavaBean en la página JSP. d) jsp:getproperty: sirve para recuperar por pantalla el valor de una propiedad de un JavaBean que ha sido creado con la acción jsp:usebean. 19

28 Para usar esta acción se debe indicar el JavaBean a usar (atributo name) y la propiedad que se quiere recuperar (atributo property). e) jsp:setproperty: sirve para establecer el valor de una propiedad de un JavaBean que ha sido creado con la acción jsp:getproperty. Para usar esta acción se debe indicar el JavaBean a usar (atributo name), la propiedad que se quiere configurar (atributo property) y el valor de la misma (atributo value). f) jsp:plugin: permite insertar un elemento OBJECT o EMBED específico del navegador utilizado. g) jsp:params y jsp:param: se utiliza para proporcionar información adicional, referida a otras acciones. h) jsp:text: envía su contenido directamente a la salida. i) jsp:output: permite indicar indica el tipo de documento XML (DTD). j) jsp:element: genera un elemento XML (como una etiqueta HTML) de forma dinámica. k) jsp:attribute: indica el valor de un atributo de una etiqueta HTML generada dinámicamente con "jsp:element". l) jsp:body: indica el valor del cuerpo de una etiqueta HTML generada dinámicamente con "jsp:element". m) jsp:root: define elementos JSP y atributos del espacio de nombres de una librería de etiquetas. n) jsp:invoke: invoca un fragmento indicado como atributo de la etiqueta (no utilizable dentro de una página JSP, sólo en ficheros ".tag"). o) jsp:dobody: invoca el cuerpo de la etiqueta (no utilizable dentro de una página JSP, sólo en ficheros ".tag") Objetos implícitos JSP El motor JSP dispone de una serie de objetos implícitamente creados, los cuales no necesitan ser declarados para ser usados, sino que pueden usarse directamente. Estos objetos resultan muy útiles para acceder a determinadas 20

29 propiedades que no se conseguirían de otra manera. Las principales objetos implícitos son: request: es el objeto HttpServletRequest asociado con la solicitud del cliente. Con esta variable se puede acceder a los parámetros recibidos del formulario del cliente, así como a las cabeceras HTTP. response: es el objeto HttpServletResponse asociado con la respuesta al cliente. session: es el objeto HttpSession (sesión) asociado con la solicitud del cliente. out: corresponde al objeto de la clase Java PrintWriter que posee todo objeto de tipo response, usándose para enviar la salida al cliente o a otra página. page: sinónimo de this en lenguaje Java. 2.2 Ajax Ajax es la conformación de varias tecnologías web que se fusionan para crear una alternativa asíncrona muy eficaz, el termino fue publicado por primera vez en un artículo llamado "Ajax: A New Approach to Web Applications" ( Ajax: Un nuevo enfoque para aplicaciones web ) del autor Jesse James en 2005, pero sus inicios se pueden marcar años atrás con productos como Exchange 2000, Internet Explorer 5 y Outlook Web Access. Ajax es un acrónimo de Asynchronous JavaScript + XML ( JavaScript asíncrono + XML ), las tecnologías que conforman a AJAX son: XHTML y CSS, para crear una presentación basada en estándares. DOM, para la interacción y manipulación dinámica de la presentación. XML, XSLT y JSON, para el intercambio y la manipulación de información. XMLHttpRequest, para el intercambio asíncrono de información. JavaScript, para unir todas las demás tecnologías. 21

30 Ajax integra todas estas tecnologías ofreciendo así una opción asíncrona de la comunicación web, de forma que se omita el refrescar toda la página para traer un elemento en específico. Las peticiones HTTP al servidor se sustituyen por peticiones JavaScript que se realizan al elemento encargado de AJAX. Las peticiones más simples que no requieren intervención del servidor, suelen tener una respuesta es inmediata. Si la interacción requiere una respuesta del servidor, la petición se realiza de forma asíncrona mediante AJAX Ventajas representativas del uso de Ajax La experiencia de usuario en la navegación es mucho más rica. Ya no se refresca la página constantemente al interactuar con ella. El tiempo de espera para una petición se reduce. El usuario al hacer un pedido (request) al servidor, no envía toda la página. Por la razón anterior el tráfico al servidor se reduce Inconvenientes de la utilización de Ajax El botón de atrás se ve afectado, debido a que la carga es de forma dinámica y no se tiene un historial al cual regresar El botón de actualizar también se afecta, debido a que la posición original no es igual a la que se pudo haber logrado mediante la navegación con Ajax. Si se guarda la página en favoritos, es probable que no se guarde la posición que se tiene actualmente. Debido a que la actualización no causa el flashazo o ventanazo de la página en blanco cuando se recarga, en los casos que la carga de la información es instantánea, algunas personas no son capaces de detectar las pistas visuales. Algunas de las alternativas que solucionan el problema de las opciones de los navegadores, suponen aumentar la codificación, además que incorporan la utilización de memoria cache para su funcionamiento, muchas de las cuales aún 22

31 no funcionan de forma eficiente. Para el caso de la actualización, a veces es necesario, insertar un indicador de carga, debido a que Ajax por ser asíncrono, no desencadena el icono de carga del navegador, en muchos de los casos un simple texto Cargando o un gif de carga solucionan ese problema Funcionamiento de Ajax El funcionamiento de Ajax se puede reducir a un esquema comparativo con el funcionamiento tradicional de las páginas web, el funcionamiento de Ajax es totalmente asíncrono lo que permite al usuario seguir visualizando la página actual sin aquellas molestas páginas en blanco o paginas congeladas en cuanto pulsamos a alguna llamada al servidor. Figura 2.2 Comunicación tradicional vs asíncrona (elaboración propia) Métodos y propiedades del objeto XMLHttpRequest Para el correcto funcionamiento, Ajax se apoya en el objeto XMLHttpRequest que es una interfaz empleada para realizar peticiones HTTP y HTTPS a servidores Web El objeto XMLHttpRequest posee muchas propiedades y métodos. A continuación se incluye una lista completa de todas las propiedades y métodos del objeto y todos los valores numéricos de sus propiedades. 23

32 Las propiedades definidas para el objeto XMLHttpRequest son: Propiedad Descripción readystate Valor numérico (entero) que almacena el estado de la petición responsetext El contenido de la respuesta del servidor en forma de cadena de texto responsexml El contenido de la respuesta del servidor en formato XML. El objeto devuelto se puede procesar como un objeto DOM status El código de estado HTTP devuelto por el servidor (200 para una respuesta correcta, 404 para "No encontrado", 500 para un error de servidor, etc.) statustext El código de estado HTTP devuelto por el servidor en forma de cadena de texto: "OK", "Not Found", "Internal Server Error", etc. Tabla 2.1 Propiedades del objeto XMLHttpRequest (Eguiluz Perez, s.f.) Los valores de la propiedad readystate son los siguientes: Valor Descripción 0 No inicializado (objeto creado, pero no se ha invocado el método open) 1 Cargando (objeto creado, pero no se ha invocado el método send) 2 Cargado (se ha invocado el método send, pero el servidor aún no ha respondido) 3 Interactivo (se han recibido algunos datos, aunque no se puede emplear la propiedadresponsetext) 4 Completo (se han recibido todos los datos de la respuesta del servidor) Tabla 2.2 Valores de la propiedad readystate (Eguiluz Perez, s.f.) Los métodos disponibles para el objeto XMLHttpRequest son los siguientes: abort() Método Descripción Detiene la petición actual 24

33 getallresponseheaders() getresponseheader("cabecera") onreadystatechange open("metodo", "url") send(contenido) setrequestheader("cabecera", "valor") Devuelve una cadena de texto con todas las cabeceras de la respuesta del servidor Devuelve una cadena de texto con el contenido de la cabecera solicitada Responsable de manejar los eventos que se producen. Se invoca cada vez que se produce un cambio en el estado de la petición HTTP. Normalmente es una referencia a una función JavaScript Establece los parámetros de la petición que se realiza al servidor. Los parámetros necesarios son el método HTTP empleado y la URL destino (puede indicarse de forma absoluta o relativa) Realiza la petición HTTP al servidor Permite establecer cabeceras personalizadas en la petición HTTP. Se debe invocar el método open() antes que setrequestheader() Tabla 2.3 Métodos del objeto XMLHttpRequest (Eguiluz Perez, s.f.) El método open() requiere dos parámetros (método HTTP y URL) y acepta de forma opcional otros tres parámetros. Definición formal del método open(): open(string metodo, string URL [,boolean asincrono, string usuario, string password]); Por defecto, las peticiones realizadas son asíncronas. Si se indica un valor false al tercer parámetro, la petición se realiza de forma síncrona, esto es, se detiene la ejecución de la aplicación hasta que se recibe de forma completa la respuesta del servidor. 25

34 No obstante, las peticiones síncronas son justamente contrarias a la filosofía de AJAX. El motivo es que una petición síncrona congela el navegador y no permite al usuario realizar ninguna acción hasta que no se haya recibido la respuesta completa del servidor. La sensación que provoca es que el navegador se ha colgado por lo que no se recomienda el uso de peticiones síncronas salvo que sea imprescindible. Los últimos dos parámetros opcionales permiten indicar un nombre de usuario y una contraseña válidos para acceder al recurso solicitado. Por otra parte, el método send() requiere de un parámetro que indica la información que se va a enviar al servidor junto con la petición HTTP. Si no se envían datos, se debe indicar un valor igual anull. En otro caso, se puede indicar como parámetro una cadena de texto, un array de bytes o un objeto XML DOM Seguridad La ejecución de aplicaciones JavaScript puede suponer un riesgo para el usuario que permite su ejecución. Por este motivo, los navegadores restringen la ejecución de todo código JavaScript a un entorno de ejecución limitado y prácticamente sin recursos ni permisos para realizar tareas básicas. Las aplicaciones JavaScript no pueden leer ni escribir ningún archivo del sistema en el que se ejecutan. Tampoco pueden establecer conexiones de red con dominios distintos al dominio en el que se aloja la aplicación JavaScript. Además, un script sólo puede cerrar aquellas ventanas de navegador que ha abierto ese script. La restricción del acceso a diferentes dominios es más restrictiva de lo que en principio puede parecer. El problema es que los navegadores emplean un método demasiado simple para diferenciar entre dos dominios ya que no permiten ni subdominios ni otros protocolos ni otros puertos. 26

35 Afortunadamente, existe una forma de solucionar parcialmente el problema del acceso a recursos no originados exactamente en el mismo dominio. La solución se basa en establecer el valor de la propiedad document.domain Así, si el código alojado en establece la variabledocument.domain = "ejemplo-seguridad.com"; y por otra parte, el código alojado en establece la variable document.domain = "ejemplo-seguridad.com";los recursos de ambos códigos pueden interactuar entre sí. La propiedad document.domain se emplea para permitir el acceso entre subdominios del dominio principal de la aplicación. Evidentemente, los navegadores no permiten establecer cualquier valor en esa propiedad, por lo que sólo se puede indicar un valor que corresponda a una parte del subdominio completo donde se encuentra el script. 2.3 JavaScript JavaScript es un lenguaje interpretado, es decir, que no requiere compilación, utilizado principalmente en páginas web, con una sintaxis semejante a la del lenguaje Java y el lenguaje C. Al contrario que Java, JavaScript no es un lenguaje orientado a objetos propiamente dicho, ya que no dispone de Herencia, es más bien un lenguaje basado en prototipos, ya que las nuevas clases se generan clonando las clases base (prototipos) y extendiendo su funcionalidad. Todos los navegadores interpretan el código JavaScript integrado dentro de las páginas web. Para interactuar con una página web se provee al lenguaje JavaScript de una implementación del DOM. El lenguaje fue inventado por Brendan Eich en la empresa Netscape Communications, que es la que fabricó los primeros navegadores web 27

36 comerciales. Apareció por primera vez en el producto de Netscape llamado Netscape Navigator 2.0 Tradicionalmente, se venía utilizando en páginas web HTML, para realizar tareas y operaciones en el marco de la aplicación únicamente cliente, sin acceso a funciones del servidor. JavaScript se ejecuta en el agente de usuario al mismo tiempo que las sentencias van descargándose junto con el código HTML. Los autores inicialmente lo llamaron Mocha y más tarde LiveScript pero fue rebautizado como JavaScript en un anuncio conjunto entre Sun Microsystems y Netscape, el 4 de diciembre de Ventajas y desventajas Ventajas y desventajas respectivas de los lenguajes de scripting y los lenguajes compilados: Seguro y fiable, puede ser filtrado; para el mismo Javascript, la seguridad es casi total y sólo en su primera versión el CIAC (Computer Incident Advisory Committee) señaló problemas de leve entidad, entre ellos la lectura de la caché y de los sitios visitados, de la dirección y de los file presentes en el disco. Sin embargo, estos fallos se corrigieron ya en las versiones de Netscape sucesivas a la 2.0 Permite la creación de efectos dinámicos tales como imágenes dinámicas y presentaciones de diapositivas, donde su uso se ha convertido algo común hoy en día. los script tienen capacidades limitadas, por razones de seguridad, por lo cual no es posible hacer todo con Javascript, sino que es necesario usarlo conjuntamente con otros lenguajes evolucionados, posiblemente más seguros, como Java. El código es visible y puede ser leído por cualquiera, incluso si está protegido con las leyes del copyright. 28

37 el código Javascript se ejecuta en el cliente por lo que el servidor noes solicitado más de lo debido. La mayoría de los navegadores es compatible con javascript Es fácil de descargar y fácil de integrar 2.4 Frameworks y librerías Las aplicaciones web son cada vez más complejas, ya que incluyen efectos e interacciones que hasta hace poco tiempo eran exclusivas de las aplicaciones de escritorio. Al mismo tiempo, la programación de estas aplicaciones avanzadas se complica por varios motivos. En primer lugar, las aplicaciones comerciales deben funcionar correctamente e igual de bien en al menos cinco navegadores diferentes: Internet Explorer 6 y 7, Firefox, Opera y Safari. En segundo lugar, el tiempo disponible para el desarrollo de cada nueva característica se reduce cada vez más por la necesidad continua de incluir novedades en las aplicaciones antes de que las incluya la competencia. Algunas ventajas de utilizar un framework son: El programador no necesita plantearse una estructura global de la aplicación, sino que el framework le proporciona un esqueleto que hay que "rellenar". Facilita la colaboración. Cualquiera que haya tenido que "pelearse" con el código fuente de otro programador ( o incluso con el propio, pasado algún tiempo!) sabrá lo difícil que es entenderlo y modificarlo; por tanto, todo lo que sea definir y estandarizar va a ahorrar tiempo y trabajo a los desarrollos colaborativos. Es más fácil encontrar herramientas (utilidades, librerías) adaptadas al framework concreto para facilitar el desarrollo. 29

38 La utilización de un framework en el desarrollo de una aplicación implica un cierto coste inicial de aprendizaje, aunque a largo plazo es probable que facilite tanto el desarrollo como el mantenimiento. Entonces un framework es un esquema para el desarrollo y/o la implementación de una aplicación, que proporciona un marco de referencia para los desarrolladores. Ofrecen muchas facilidades al programador o diseñador que los utiliza, debido a su sencillez y la manera en que facilitan la programación. También es posible que el framework defina una estructura para una aplicación completa, o bien sólo se centre en un aspecto de ella. Por todo lo anterior, han surgido librerías y frameworks específicos para el desarrollo de aplicaciones con JavaScript. Utilizando estas librerías, se reduce el tiempo de desarrollo y se tiene la seguridad de que las aplicaciones funcionan igual de bien en cualquiera de los navegadores más populares. Existen multitud de frameworks orientados a diferentes lenguajes, funcionalidades, etc. En este caso los frameworks basados en el lenguaje Javascript son popularmente conocidos y utilizados debido a la simplificación del proceso de desarrollo que les representan a los desarrolladores, ya que proporcionan soporte a infinidad de librerías GNU o de distribución libre que permitan la modificación y adaptación a las necesidades de la organización. 2.5 JQuery Creada por el desarrollador John Resig y presentada el 14 de enero de 2006 en BarCampNYC, jquery es una biblioteca de JavaScript que simplifica la interacción con documentos HTML, el manejo de animaciones y que permite optimizar tiempo y espacio, utilizando menos caracteres, de forma que se obtienen resultados increíbles con un mínimo de esfuerzo, como también un código simple, sencillo y entendible. Sitios web como google, amazon, twitter y Microsoft utilizan la biblioteca jquery. 30

39 Es un software libre y de código abierto, bajo la licencia MTI así como GPL lo cual representa que cualquier persona es libre de descargar y modificarlo de acuerdo a sus necesidades, sin siquiera tener que dar créditos por ello Características JQuery tiene infinidad de funciones y aplicaciones y muchas de las librerías actuales la utilizan como soporte para su funcionalidad, algunas de sus características más representativas son: Selección de elementos DOM. Interactividad y modificaciones del árbol DOM, incluyendo soporte para CSS 1-3 y un plugin básico de XPath. Eventos. Manipulación de la hoja de estilos CSS. Efectos y animaciones. Animaciones personalizadas. AJAX. Soporta extensiones. Utilidades varias como obtener información del navegador, operar con objetos y vectores, funciones para rutinas comunes, etc. Compatible con los navegadores Mozilla, Firefox 2.0+, Internet Explorer 6+, Safari 3+, Opera y Google Chrome 8+. La característica principal de resaltar debido al tema a tratar, es que interacciona con Ajax y simplifica la utilización de este, de forma que se obtengan los mismos resultados con el mínimo de código Funciones para AJAX Las funciones y utilidades relacionadas con AJAX son parte fundamental de jquery. El método principal para realizar peticiones AJAX es $.ajax() (importante no olvidar el punto entre $ y ajax). A partir de esta función básica, se han definido 31

40 otras funciones relacionadas, de más alto nivel y especializadas en tareas concretas: $.get(), $.post(),$.load(), etc. La sintaxis de $.ajax() es muy sencilla: Código JQuery: $.ajax(opciones); La URL que se solicita también se incluye dentro del array asociativo de opciones. A continuación se muestra un ejemplo básico realizado con $.ajax(): Código JQuery: $.ajax({ url: '/ruta/hasta/pagina.php', type: 'POST', async: true, data: 'parametro1=valor1&parametro2=valor2', success: procesarespuesta, error: muestraerror }); La siguiente tabla muestra todas las opciones que se pueden definir para el método $.ajax(): Opción async beforesend Descripción Indica si la petición es asíncrona. Su valor por defecto es true, el habitual para las peticiones AJAX Permite indicar una función que modifique el objeto XMLHttpRequest antes de realizar la petición. El propio objeto XMLHttpRequest se pasa como único argumento de la función 32

41 complete Permite establecer la función que se ejecuta cuando una petición se ha completado (y después de ejecutar, si se han establecido, las funciones desuccess o error). La función recibe el objeto XMLHttpRequest como primer parámetro y el resultado de la petición como segundo argumento contenttype Indica el valor de la cabecera Content-Type utilizada para realizar la petición. Su valor por defecto es application/x-www-formurlencoded data Información que se incluye en la petición. Se utiliza para enviar parámetros al servidor. Si es una cadena de texto, se envía tal cual, por lo que su formato debería ser parametro1=valor1&parametro2=valor2. También se puede indicar un array asociativo de pares clave/valor que se convierten automáticamente en una cadena tipo query string datatype El tipo de dato que se espera como respuesta. Si no se indica ningún valor, jquery lo deduce a partir de las cabeceras de la respuesta. Los posibles valores son: xml (se devuelve un documento XML correspondiente al valorresponsexml), html (devuelve directamente la respuesta del servidor mediante el valor responsetext), script (se evalúa la respuesta como si fuera JavaScript y se devuelve el resultado) y json (se evalúa la respuesta como si fuera JSON y se devuelve el objeto JavaScript generado) error Indica la función que se ejecuta cuando se produce un error durante la petición. Esta función recibe el objeto XMLHttpRequest como primer parámetro, una cadena de texto indicando el error como segundo parámetro y un objeto con la excepción producida como tercer parámetro ifmodified Permite considerar como correcta la petición solamente si la respuesta recibida es diferente de la anterior respuesta. Por defecto su valor es false 33

42 processdata Indica si se transforman los datos de la opción data para convertirlos en una cadena de texto. Si se indica un valor de false, no se realiza esta transformación automática Success Permite establecer la función que se ejecuta cuando una petición se ha completado de forma correcta. La función recibe como primer parámetro los datos recibidos del servidor, previamente formateados según se especifique en la opción datatype Timeout Indica el tiempo máximo, en milisegundos, que la petición espera la respuesta del servidor antes de anular la petición Type El tipo de petición que se realiza. Su valor por defecto es GET, aunque también se puede utilizar el método POST url La URL del servidor a la que se realiza la petición Tabla 2.4 Opciones del método $.ajax(). (Eguiluz Perez, s.f.) Además de la función $.ajax() genérica, existen varias funciones relacionadas que son versiones simplificadas y especializadas de esa función. Así, las funciones $.get() y $.post() se utilizan para realizar de forma sencilla peticiones GET y POST: // Petición GET simple $.get('/ruta/hasta/pagina.php'); // Petición GET con envío de parámetros y función que // procesa la respuesta $.get('/ruta/hasta/pagina.php', { articulo: '34' }, function(datos) { alert('respuesta = '+datos); }); Las peticiones POST se realizan exactamente de la misma forma, por lo que sólo hay que cambiar$.get() por $.post(). La sintaxis de estas funciones son: $.get(url, datos, funcionmanejadora); El primer parámerto (url) es el único obligatorio e indica la URL solicitada por la petición. Los otros dos parámetros son opcionales, siendo el segundo (datos) los 34

43 parámetros que se envían junto con la petición y el tercero (funcionmanejadora) el nombre o el código JavaScript de la función que se encarga de procesar la respuesta del servidor. La función $.get() dispone a su vez de una versión especializada denominada$.getifmodified(), que también obtiene una respuesta del servidor mediante una petición GET, pero la respuesta sólo está disponible si es diferente de la última respuesta recibida. jquery también dispone de la función $.load(), que es idéntica a la función Ajax.Updater() de Prototype. La función $.load() inserta el contenido de la respuesta del servidor en el elemento de la página que se indica. La forma de indicar ese elemento es lo que diferencia a jquery de Prototype: <div id="info"></div> $('#info').load('/ruta/hasta/pagina.php'); Al igual que sucedía con la función $.get(), la función $.load() también dispone de una versión específica denominada $.loadifmodified() que carga la respuesta del servidor en el elemento sólo si esa respuesta es diferente a la última recibida. Por último, jquery también dispone de las funciones $.getjson() y $.getscript() que cargan y evalúan/ejecutan respectivamente una respuesta de tipo JSON y una respuesta con código JavaScript. status statustext Explicación 100 Continue Una parte de la petición (normalmente la primera) se ha recibido sin problemas y se puede enviar el resto de la petición 101 Switching protocols El servidor va a cambiar el protocolo con el que se envía la información de la respuesta. En la cabecera Upgrade indica 35

44 el nuevo protocolo Tabla 2.5 Códigos de información (Eguiluz Perez, s.f.) status statustext Explicación 200 OK La petición se ha recibido correctamente y se está enviando la respuesta. Este código es con mucha diferencia el que más devuelven los servidores 201 Created Se ha creado un nuevo recurso (por ejemplo una página web o un archivo) como parte de la respuesta 202 Accepted La petición se ha recibido correctamente y se va a responder, pero no de forma inmediata 203 Non-Authoritative Information La respuesta que se envía la ha generado un servidor externo. A efectos prácticos, es muy parecido al código No Content La petición se ha recibido de forma correcta pero no es necesaria una respuesta 205 Reset Content El servidor solicita al navegador que inicialice el documento desde el que se realizó la petición, como por ejemplo un formulario 206 Partial Content La respuesta contiene sólo la parte concreta del documento que se ha solicitado en la petición Tabla 2.6 Códigos de petición y respuesta correctas (Eguiluz Perez, s.f.) status statustext Explicación 300 Multiple Choices El contenido original ha cambiado de sitio y se devuelve una lista con varias direcciones alternativas en las que se puede encontrar el contenido 301 Moved Permanently El contenido original ha cambiado de sitio y el servidor devuelve la nueva URL del contenido. La próxima vez que solicite el contenido, el navegador utiliza la nueva URL 36

45 302 Found El contenido original ha cambiado de sitio de forma temporal. El servidor devuelve la nueva URL, pero el navegador debe seguir utilizando la URL original en las próximas peticiones 303 See Other El contenido solicitado se puede obtener en la URL alternativa devuelta por el servidor. Este código no implica que el contenido original ha cambiado de sitio 304 Not Modified Normalmente, el navegador guarda en su caché los contenidos accedidos frecuentemente. Cuando el navegador solicita esos contenidos, incluye la condición de que no hayan cambiado desde la última vez que los recibió. Si el contenido no ha cambiado, el servidor devuelve este código para indicar que la respuesta sería la misma que la última vez 305 Use Proxy El recurso solicitado sólo se puede obtener a través de un proxy, cuyos datos se incluyen en la respuesta 307 Temporary Redirect Se trata de un código muy similar al 302, ya que indica que el recurso solicitado se encuentra de forma temporal en otra URL Tabla 2.7 Códigos de redirección (Eguiluz Perez, s.f.) status statustext Explicación 400 Bad Request El servidor no entiende la petición porque no ha sido creada de forma correcta 401 Unauthorized El recurso solicitado requiere autorización previa 402 Payment Código reservado para su uso futuro Required 403 Forbidden No se puede acceder al recurso solicitado por falta de permisos o porque el usuario y contraseña indicados no son correctos 37

46 404 Not Found El recurso solicitado no se encuentra en la URL indicada. Se trata de uno de los códigos más utilizados y responsable de los típicos errores de Página no encontrada 405 Method Not Allowed El servidor no permite el uso del método utilizado por la petición, por ejemplo por utilizar el método GET cuando el servidor sólo permite el método POST 406 Not Acceptable El tipo de contenido solicitado por el navegador no se encuentra entre la lista de tipos de contenidos que admite, por lo que no se envía en la respuesta 407 Proxy Authentication Required Similar al código 401, indica que el navegador debe obtener autorización del proxy antes de que se le pueda enviar el contenido solicitado 408 Request Timeout El navegador ha tardado demasiado tiempo en realizar la petición, por lo que el servidor la descarta 409 Conflict El navegador no puede procesar la petición, ya que implica realizar una operación no permitida (como por ejemplo crear, modificar o borrar un archivo) 410 Gone Similar al código 404. Indica que el recurso solicitado ha cambiado para siempre su localización, pero no se proporciona su nueva URL 411 Length Required El servidor no procesa la petición porque no se ha indicado de forma explícita el tamaño del contenido de la petición 412 Precondition Failed No se cumple una de las condiciones bajo las que se realizó la petición 413 Request Entity Too Large La petición incluye más datos de los que el servidor es capaz de procesar. Normalmente este error se produce cuando se adjunta en la petición un archivo con un tamaño demasiado grande 38

47 414 Request-URI Too Long La URL de la petición es demasiado grande, como cuando se incluyen más de 512 bytes en una petición realizada con el método GET 415 Unsupported Media Type Al menos una parte de la petición incluye un formato que el servidor no es capaz procesar 416 Requested Range Not Suitable El trozo de documento solicitado no está disponible, como por ejemplo cuando se solicitan bytes que están por encima del tamaño total del contenido 417 Expectation Failed El servidor no puede procesar la petición porque al menos uno de los valores incluidos en la cabecera Expect no se pueden cumplir Tabla 2.8 Códigos de error del navegador (Eguiluz Perez, s.f.) status statustext Explicación 500 Internal Server Error Se ha producido algún error en el servidor que impide procesar la petición 501 Not Implemented Procesar la respuesta requiere ciertas características no soportadas por el servidor 502 Bad Gateway El servidor está actuando de proxy entre el navegador y un servidor externo del que ha obtenido una respuesta no válida 503 Service Unavailable El servidor está sobrecargado de peticiones y no puede procesar la petición realizada 504 Gateway Timeout El servidor está actuando de proxy entre el navegador y un servidor externo que ha tardado demasiado tiempo en responder 505 HTTP Version Not Supported El servidor no es capaz de procesar la versión HTTP utilizada en la petición. La respuesta indica las versiones de HTTP que soporta el servidor Tabla 2.9 Códigos de error del servidor (Eguiluz Perez, s.f.) 39

48 2.6 Eclipse Figura 2.3 Imagen del software Eclipse (Eclipse 2013). La utilización de Eclipse como plataforma de desarrollo del prototipo es fundamental debido a que ofrece la característica principal buscada dentro del departamento, es open source por lo que no requiere la adquisición de una licencia para su manejo, Eclipse se distribuye bajo licencia EPL (Eclipse Public License). La licencia EPL permite usar, modificar, copiar y distribuir nuevas versiones del producto licenciado. Fue desarrollado en un principio por IBM y actualmente por la fundación Eclipse,sin fines de lucro que formenta el código abierto. Es multiplataforma debido a que es basado casi en su totalidad en Java, además que cuenta con infinidad de funciones para la correcta administración del proyecto como la disposición de un editor de texto con resaltado de sintaxis, lo cual ayuda mucho al desarrollador para identificar y corregir errores, así como encontrar variables, métodos, correspondencia de llaves, etc. Cuenta con compilación en tiempo real lo que facilita la detección y correccion de errores. Además tiene funciones específicas para la creación de proyectos web que incluye editores de fuentes para HTML, JavaScript, CSS, JSP, SQL, XML, DTD, XSD y WSDL. Eclipse es entonces un programa bastante completo y de gran utilidad al momento de desarrollar infinidad de aplicaciones. 40

49 2.7 Apache Tomcat Figura 2.4 Logotipo del servidor web Apache Tomcat (Apache 2013) Para las pruebas locales se utilizó un servidor web llamado Apache Tomcat en su versión 6.0, que implementa las aplicaciones de los servlets y de los JSPs, debido a que es basado en Java, y al ser éste un lenguaje multiplataforma, funciona en cualquier sistema operativo que cuente con la máquina virtual de Java. Su nombre significa gato (Tomcat), y se refiere al hecho de ser independiente. Antiguamente fue utilizado únicamente para las pruebas de desarrollo de aplicaciones, pero actualmente es el servidor web de muchas aplicaciones funcionales, soportando grandes tráficos de datos. Sus componentes son los ya conocidos Catalina, Coyote y Jasper. Catalina es el que implementa todas las especificaciones de los servlets y JSP, integrándose donde ya existe una comprobación de autentificación por la base de datos. Coyote es un conector que admite el protocolo HTTP, además que escucha los puertos TPC que se especifican por el servidor, enviando una solicitud a Tomcat para que este a su vez mande una respuesta al cliente. Jasper es nada menos que el encargado de hacer posible la compilación de los JSP y servlets, que se desencadena cada vez que se hace alguna modificación. 41

50 Lo que nos permite una compilación en tiempo real. Apache es muy popular dentro de los desarrolladores, debido a su cierto nivel de simplicidad y sobre todo a su correcto funcionamiento, ideal para realizar infinidad de pruebas. 2.8 SQL Server 2008 Management Studio Express Figura 2.5 Imagen del manejador de base de datos SQL Server Management Studio (SQL Server 2013) Microsoft SQL Server 2008 Management Studio Express es un sistema manejador de base de datos, basado en el modelo relacional. Características: Soporta transacciones. Soporta procedimientos almacenados. Trabaja bajo el modelo cliente-servidor, donde la información y/o datos se alojan en el servidor y los clientes sólo acceden a la información. Permite administrar información de otros servidores de datos. Se deicidio utilizar esta versión de Microsoft debido a que es específica para servidores y además siguiendo la línea de los requerimientos del software es gratuito. 42

51 CAPITULO III: DISEÑO DEL PROTOTIPO

52 3.1 Metodología: Modelo por prototipos En el diseño de sistemas de información existen diferentes metodologías que nos permiten llevar una secuencia del proceso de diseño, algunos de los modelos que existen son: Cascada Prototipos Iterativos, dentro del cual se encuentran: Espiral Evolutivo Estabilización Sincronización El modelo por prototipos resulta ser una forma rápida y eficiente de mostrar al usuario o cliente, la posible imagen y funcionalidad final que tendrá el sistema, pudiendo de esta forma retroalimentar al desarrollador en cuanto a información extra necesaria, imagen, estructura y demás funciones de un sistema de información. Un prototipo dentro de los sistemas de información se refiere a una versión previa de lo que será el sistema basado en requerimientos propuestos por el usuario final que son la primera impresión del desarrollador de lo que podrían ser sus necesidades de información y/o diseño, que varían desde simples pantallas que pueden estar hechas en papel, hasta versiones funcionales que se parecen mucho a las que finalmente se utilizan. 44

53 Se decidió esta metodología debido a la rapidez de su diseño y la necesidad de tener una versión funcional, y de esta forma poder visualizar claramente la mejora en la rapidez del sistema. 3.2 Identificación de requerimientos La Mesa de Ayuda sirve como un punto de encuentro entre usuarios y técnicos, para atender las necesidades de todas las dependencias dentro de la Universidad Veracruzana, la actual aplicación es aun joven en cuanto a desarrollo y en poco tiempo se ha convertido en una herramienta crucial dentro del Departamento de Atención Técnica a Usuarios, debido a que mediante ella se puede llevar un mejor control de los reportes atendidos. Hoy en día la institución como tal ha revelado una nueva imagen de su portal en general, con el empleo de nuevas tecnologías y tratando de optimizarlo, es debido a ello que existe la necesidad de una aplicación de acuerdo a este cambio institucional, no solamente en el aspecto estético sino también en la funcionalidad. Es por esto que se requiere una reestructuración en su página maestra que permita la agilización de la creación de reportes, atención y control de ellos Análisis de requerimientos De acuerdo a la recopilación de información dentro del departamento de atención técnica a usuarios, basada en la observación de los procesos realizados para la atención de un servicio, así como la revisión de la documentación utilizada en papel para su control, y finalmente respondiendo a las necesidades e inquietudes de los técnicos y de los usuarios, los requerimientos obtenidos se pueden dividir en dos grandes apartados: Requerimientos funcionales Un requerimiento funcional se define como las necesidades de entradas y salidas de información del prototipo, para este caso los requerimientos funcionales son: 45

54 Usuarios: Los datos que generan los usuarios que solicitan un servicio a la mesa de ayuda, en este caso la captura. El reporte que debe tener a su alcance el usuario para poder tener un control de lo que solicito. Técnicos: Control de reportes solicitados por usuarios, en este caso la forma de reportes pendientes La información proporcionada por usuarios de forma personal, telefónica o vía por la que se genera el servicio, este caso la captura. Seguimiento que permita saber en qué etapa del proceso de atención se encuentra el servicio. Reportes de causas de incidencias que permitan la toma de decisiones oportuna Requerimientos no funcionales Los requerimientos no funcionales son aquellos que nos indican las características tanto cualitativas como cuantitativas del prototipo que para este caso serían: Agilizar la navegación dentro de la mesa de ayuda lo cual incluye: Un desplazamiento entre formas más desahogado. Eliminando submenús repetitivos innecesarios. Formas internas más rápidas que utilicen Ajax para optimizar su carga. Reducir a un mínimo las validaciones dentro de la página maestra. Cargando de forma asíncrona los elementos necesarios. Actualización del diseño de la interfaz ajustada al tema actual del portal universitario. 46

55 3.3 Estructura de la Base de Datos Diseño de la Base de Datos El diseño de una base de datos es esencial para el correcto procesamiento de la información del sistema, porque es precisamente de la que se extraerán los datos necesarios que serán transformados en información útil para los usuarios. Un correcto diseño de una base de datos reduce al mínimo la redundancia y permite tener la información de forma rápida y oportuna. La base de datos utilizada para este prototipo, será una réplica de la que actualmente se maneja dentro del departamento, debido a que se requiere igualar el funcionamiento y afectar lo menos posible el manejo de la información Servidores En Departamento de Atención Técnica a Usuarios cuenta con un servidor de base de datos principal, que es la base de datos original y la que se utiliza para a aplicación web que se tiene corriendo principalmente. Independientemente de ella se tienen dos réplicas de esta: La primera utilizada para el desarrollo y prueba local de las personas encargadas de la programación en el departamento. La segunda es utilizada para la prueba de cualquier modificación futura de la mesa de ayuda, desde un servidor de prueba con la aplicación. Ambas se restauran con periodicidad de forma que la información con la que se pruebe sea la más actualizada Descripción de tablas Debido a la confidencialidad de la información manejada dentro del sistema, únicamente se describirán las tablas con las que se cuenta actualmente en la 47

56 mesa de ayuda de forma general. Resaltando individualmente las tablas que conciernen a la información que se le dará prioridad. Tabla Descripción Administrador Tabla que guarda la información de los usuarios con perfil de administrador para cada región. Alumno Tabla que guarda la información de los alumnos de la Universidad Veracruzana. CatalogoEquipo Catalogo estándar del equipo utilizado actualmente en la institución. CatalogoTiposUbicacionSupervision Catalogo estándar de áreas dentro de la institución. Catálogo de dependencias que utilizan actualmente el SIIU CatalogoUbicacionesSIIU CatalogoProblema Catalogo que contiene los problemas presentados a nivel institucional Direccion Conformada por la información de todas las dependencias dentro de la institución DireccionTecnicoNumeralia Se conforma de la información de los usuarios o técnicos con privilegios para guardar información de numeralia. Equipo Conformada por la información de equipamiento por dependencia EquipoIPMAC Contiene las direcciones IP y MAC de todos los equipos así como la fecha en la que se modificaron. Inventario Contiene la información de todo el inventario MedioComunicación. Tipo de medio utilizado para la petición 48

57 Numeralia PersonalAtiende PersonalSolicita Prioridad Region Reporte ReporteTipodeProblema Seguimiento ServicioPerAtiende SubRegion SupervisionEspecifica SupervisionGeneral TecnicoNumeralia TiempoMuerto de un servicio. Contiene las características de obsolescencia del equipo. Guarda la información de los técnicos. Guarda la información de todos los usuarios que pueden solicitar un servicio. Catalogo que cuenta con la información de los tipos de prioridad y sus tiempos de respuesta. Tiene la información de las cinco regiones de la institución. Contiene toda la información de los reportes atendidos en el departamento. Tabla que guarda el id del reporte y lo relaciona de acuerdo a su categoría en cuanto a problema Contiene las observaciones y así como información del reporte Contiene la relación del servicio con su técnico encargado. Conformada por la información de las sub regiones y su estado actual. Contiene la información detallada de equipos en las diferentes dependencias. Contiene la información general de la dependencia de la cual se captura el equipo de forma específica. Contiene la información del personal autorizado para la captura de numeralia Guarda la información del tiempo muerto por reporte. 49

58 TipoPersonal TipoProblema Vehiculo Catálogo de la clasificación del personal Contiene la información del problema así como su descripción Contiene la información de los vehículos. Tabla 3.1 Descripción de tablas de la base de datos HELPDESK (elaboración propia) Las tablas descritas que nos interesan dentro de este trabajo son las que conciernen a los servicios solicitados por los usuarios, que son la realización de reportes, se puede observar mejor su funcionamiento en el diagrama entidad relación. En el diagrama de la figura 3.1 se puede observar como la tabla Reporte es la encargada de centralizar toda la información mediante las llaves foráneas almacenadas de las diferentes tablas que se relacionan. Mediante el Reporte se puede acceder a su seguimiento, situación, además de relacionarlo con la información del solicitante y del técnico que está encargado de su atención y solución. La prioridad del reporte está directamente relacionado con el solicitante, además que mediante esta tabla se pueden obtener infinidad de consultas relacionadas con tipos de incidencias, usuarios recurrentes, técnicos con mayor reportes atendidos, tiempo de atención, reportes atendidos contra reportes solicitados. 50

59 3.3.4 Diagrama Entidad-Relación MedioComunicacion (1,n) (1,1) Tiene Reporte (n,1) Atiende (n,1) PerAtiende (1,1) (1,1) (1,1) (1,1) Solicita Pertenece Corresponde Tiene (1,n) (1,n) (1,1) (1,n) PerSolicita Servicio Seguimiento Prioridad Figura 3.1 Diagrama Entidad-Relación de un extracto de la Base de Datos (elaboración propia). 51

60 3.4 Prototipo inicial Proceso del Departamento de Atención Técnica a Usuarios El procedimiento con el que se atiende un servicio dentro del Departamento de Atención Técnica a Usuarios (DATU) suele ser muy variado debido a que pueden ser solicitados, vía telefónica, chat, correo electrónico, o mediante un oficio para su atención dentro del departamento. Algunos de los casos más comunes de servicios de acuerdo a esta clasificación son: Presenciales: Accesos al SIIU, ya sea por problemas de acceso, generación de reportes, o creación del mismo entre otros. Atención dentro del departamento: Usualmente encabezados por formateo de equipos que presentan problemas o equipos nuevos que requieren del sistema institucional, diagnóstico y en ocasiones reparación de algún equipo de cómputo, entre otros. Remoto: Estos suelen ser variados y únicamente se realizan con usuarios recurrentes que aceptan ese tipo de ayuda, debido a que el técnico se conecta de forma remota a su equipo y soluciona el problema mientras el usuario puede observar todo el procedimiento. Una vez que el usuario solicita el servicio se genera un folio de servicio, asignado a un técnico encargado de darle solución a este, el técnico regularmente llena un formato (ver Anexo I) que en un principio solo incluye el folio del servicio y la información del usuario que solicita, este formato es la forma física de recabar información para posteriormente vaciarla en el sistema y es entonces cuando comienza el proceso de atención. 52

61 Solicitud de Servicio Atención Cierre de Servicio Figura 3.2 Proceso de Atención dentro de DATU (elaboración propia). En la Figura 3.2 se muestra el proceso de atención, dentro de este proceso, la forma de atención como ya se menciono es muy variada, por lo que los caminos que puede tomar varían de acuerdo al tipo de problema que se resolverá. Una vez generado el reporte de servicio, los técnicos cuentan con una consulta que les permite conocer el detalle del servicio que están realizando así como la rapidez con la que se debe atender. Para esto cuentan con diferentes indicadores, tienen un indicador de prioridad que le dicen al técnico en qué orden de importancia debe atender un servicio: 1) Alta.- Con un tiempo de respuesta de 30 min. 2) Media.- Con una tolerancia de 2 horas. 3) Baja.- Cuenta con 7 horas hábiles en tiempo de atención. Así mismo cuentan con un estado que representa el tiempo en que el técnico debe atender determinado servicio y no debería rebasar ese tiempo para dar un buen servicio. a) En tiempo: Como su nombre lo indica significa que el servicio aún está dentro del tiempo aceptable. b) En límite de tiempo: Significa que está por cumplir el tiempo que se estableció para su atención c) En tiempo excedido: Quiere decir que el tiempo que se ha demorado en atender el servicio supera el definido en la prioridad. d) Pausados: Indica que el servicio no se ha podido completar por alguna situación ajena al departamento, por ejemplo algún disco duro, cable o acción que se requiera externa y que no se tenga al momento de empezar el servicio. 53

62 Para el caso del usuario también es posible ver el proceso de realización de su servicio mediante la aplicación web, además se le notifica por correo electrónico que su servicio está siendo atendido. Una vez atendido el servicio se le pide al usuario que firme de conformidad, en la mayoría de los casos, excepto en los casos que se solucionan vía telefónica. Y cuanto el técnico cierra el servicio, se envía nuevamente un correo de notificación al usuario con el cierre del servicio y una encuesta que evalúa la atención recibida. Este proceso se repite una y otra vez, alimentando así al sistema, tanto de incidencias como de usuarios recurrentes, técnicos con mayor número de servicios y demás estadísticas útiles para la toma de decisiones Modelo jerárquico de la aplicación La mesa de ayuda se conforma de una estructura de privilegios que se respetará en el prototipo, debido a que estos no se han modificado. 1) Administrador 2) Avanzado 3) Limitado El perfil de administrador es aquel que tiene acceso a todas las formas existentes dentro de la mesa de ayuda, como gráficas, estadísticas, reportes entre otros usos que actualmente se le agregan a la mesa de ayuda en base a las necesidades del departamento, tiene dos finalidades: otorgar acceso absoluto al web master y a su vez al encargado del departamento. El perfil de avanzados, es más estricto en cuanto al control que debería poder llevar un técnico, únicamente de sus pendientes, los servicios solucionados y la posibilidad de capturar servicios nuevos. 54

63 Por último los usuarios limitados que solo tienen acceso a la captura de un servicio y el reporte de la situación actual de algún servicio en curso, que en resumen serían todos aquellos usuarios que solicitan algún servicio al departamento Código y estructura del prototipo Para la realización de este prototipo el primer paso fue analizar a profundidad el funcionamiento inicial de la mesa de ayuda, ya que debía igualarse en cierta forma la navegación de la aplicación mejorando la carga de las formas. El orden de desarrollo fue el siguiente, se modificó como parte primordial la página maestra, después las formas afectadas como son Captura y Reportes, a la par se modificaron las cascadas de estilos para brindarle la imagen actual deseada además de otras formas menos importantes a las cuales también se les debió hacer modificaciones. Página Maestra Se hicieron cambios significativos de código, los cuales consisten en la reducción de líneas de código mayormente compuestas por validaciones, lo cual optimiza la navegación por el sistema sin las excesivas validaciones que alentaban tanto la carga de la página. En la figura 3.3 se muestra la nueva estructura de la página. Figura 3.3 Estructura de la página maestra (elaboración propia). 55

64 Se redujeron las validaciones clasificando los tres tipos de usuarios en diferentes JSP lo que nos permite cargar según el perfil del usuario en el div del menú de la como se muestra en la figura 3.4. Figura 3.4 Extracto de código JQuery de la página maestra (elaboración propia). Además que los estilos para la ubicación de la página se hicieron a base JavaScript y CSS eliminando así todas las validaciones que alentaban el menú, agregando a cada opción del menú un evento onclick con el que se le cambia la cascada de estilo enviando el id en el evento. Figura 3.5 Extracto de código JavaScript del menú de administrador (elaboración propia). Se utiliza el evento onclick que ejecuta la función colormuestra1 que le aplicara estilo al menú mediante el id enviado (figura 3.5). Con estas sencillas modificaciones se evita tener innumerables líneas de validaciones e if anidados para poder dar estilo a una pequeña sección del menú 56

65 Captura de Reportes La captura de los reportes es una de las formas más utilizadas, debido a que es a principal fuente de alimentación del sistema, es con ella que se puede conocer qué tipo de incidencia se atenderá, el usuario y demás, es por ello que su funcionamiento es primordial para la Mesa de ayuda. En esta forma se eliminaron las llamadas a servidor para los catálogos y para todo lo que no fuera totalmente necesario,de forma que estos fueran cargados con Ajax, y que la llamada al servlet fuera únicamente en el caso final. Uno de los casos más vistos con Ajax y que fue necesario utilizar para una de las secciones de esta forma es la carga de combos dependientes, lo que quiere decir que en el momento en que seleccione la opción del primer combo se despliegue otro combo con su respectivo contenido o lo que es lo mismo que el segundo, tercer o cuarto combo se llene en base a la opcion previa seleccionada, estos combos se hicieron con Ajax, con el código que se muestra en la figura 3.7. Se selecciona una opción del primer combo en este caso la dependencia y en base a este se llena el segundo combo que serían las opciones de servicios que se atienden, finalmente el segundo combo también es seleccionada una opción y este a su vez de acuerdo a su contenido despliega la información en el div inferior que es simplemente una descripción del servicio seleccionado todo esto mediante Ajax (Figura 3.6). Figura 3.6 Funcionamiento de combos dependientes (elaboración propia). 57

66 Figura 3.7 Código JavaScript de la forma de captura de reportes (elaboración propia). Reportes Pendientes Así como la captura es la base primordial de entradas de información, una consulta es realmente lo que esperamos lograr de un sistema de información, que nos permita analizar toda la información que ingresamos de otra forma el sistema de información no tiene sentido. En la forma de reportes se sustituyó con Ajax la caga de las consultas que tomaba casi 4 segundos el procesamiento de la consulta de pendientes como se muestra en la figura

67 Figura 3.8 Estructura de la forma Pendientes (elaboración propia). Se agregó un evento a los radio buttons en los que se realiza la consulta, mediante este evento se envía el tipo de consulta realizada, y se muestra mediante Ajax en un div lo que se recibe. Figura 3.9 Extracto de código JavaScript de la forma Pendientes (elaboración propia). 59

68 Figura 3.10 Pantalla del funcionamiento del gif de carga de la forma Pendientes (elaboración propia). En la figura 3.9 se muestra el código xmlhttppostrepen el evento onclick de forma que cuando se pulse sobre el radio button se ejecute la función, y devuelva la consulta que corresponde. Y para hacer más amena la espera en caso de que la consulta sea muy grande se utiliza el gif de carga de la figura Optimización de procedimientos almacenados Un procedimiento almacenado es una serie de instrucciones que se guardan en el motor de base de datos en este caso SQL Server, se les agrega un nombre y pueden recibir parámetros o no, dentro de la mesa de ayuda son utilizados para todas las operaciones de base de datos sean consultar, actualizar, agregar o eliminar. Son llamados desde la aplicación donde se envían los parámetros y se reciben las respuestas en forma de variables, arreglos o matrices. Originalmente la forma en que se manejaba la generación de consultas era la de reutilización de procedimientos almacenados, de forma: 1. Se creaba un nuevo procedimiento almacenado que generara la información necesaria que se tomaría como base (en la mayoría de los casos un arreglo o parámetro). 2. Para obtener la información restante se reutilizaban los procedimientos que arrojaran lo que se deseaba, fuese que el procedimiento retornara un arreglo completo y solo utilizar la posición que se utilizaría, o una variable (por ejemplo un id que se utilizaría para llamar otro procedimiento). 60

69 Uno de los casos que utilizaba esta mecánica era dentro de la forma de Reportes Pendientes, llamando un total de aproximadamente 6 procedimientos almacenados para generar cada matriz de información. Lo que se realizó, fue una reducción a un solo procedimiento almacenado por matriz que arrojara la información deseada, que son los siguientes: Figura 3.11 Procedimiento almacenado obtmatreportegralkel (elaboración propia). En la figura 3.11 se muestra el procedimiento final que se utilizo para la consutla de reportes desde la vista administrador, lo cual quiere decir que se genera una consuitla que muestra los pendientes de todas las regiones, utilizando las llaves 61

70 foraneas es posible acceder a toda la informacion que necesitamos sin la necesidad de ejecutar varios procedimientos almacenados. Otra de las formas que trabajaba bajo este método de procedimientos almacenados excesivos era la consulta de reportes por folio, lo que se realizo fue un procedimiento que arrojara toda la información necesaria para la consulta como se muestra en la figura 3.12, eliminando las múltiples llamadas y así optimizando su funcionamiento. Figura 3.12 Procedimiento almacenado obtdatreportekelpie (elaboración propia) 62

71 3.4.5 Interfaz Grafica A continuación se muestran las interfaces finales del prototipo propuesto, se muestra en primera instancia la interfaz externa que sería a la que podría tener acceso sin necesidad de iniciar sesión, donde se puede encontrar información sobre la Mesa de Ayuda y el departamento de atención técnica a usuarios, una sección de preguntas frecuentes, información sobre la realización de servicio social dentro del departamento, entre otras características. Posteriormente se muestran las pantallas internas de todas las formas incluidas en el prototipo propuesto, tanto de captura como de consultas y gráficas, etc. Figura 3.13 Pantalla: Inicio sin iniciar sesión (elaboración propia). 63

72 Figura 3.14 Pantalla: Inicio con sesión iniciada de usuario avanzado (elaboración propia). Figura 3.15 Pantalla: Inicio con sesión iniciada de usuario administrador (elaboración propia). 64

73 Figura 3.16 Pantalla: Reportes de Pendientes (elaboración propia). Figura 3.17 Pantalla: Captura de Reportes (elaboración propia). 65

74 Figura 3.18 Pantalla: Catalogo de causas de incidencia (elaboración propia). Figura 3.19 Pantalla: Captura de Supervisión Regional (elaboración propia). 66

75 Figura 3.20 Pantalla: Captura de Personal (elaboración propia). Figura 3.21 Pantalla: Consulta de reportes atendidos por técnico (elaboración propia). 67

76 Figura 3.22 Pantalla: Consulta de reportes por folio (elaboración propia). Figura 3.23 Pantalla: Consulta de Reportes Atendidos Mensualmente (elaboración propia). 68