INTRODUCCIÓN. Recientemente se han detectado ciertas falencias tanto funcionales como

Transcripción

1 1 INTRODUCCIÓN Recientemente se han detectado ciertas falencias tanto funcionales como de requerimientos en el sistema académico, motivo por el cual se planteó la realización de un nuevo sistema de apoyo académico computarizado. Uno de los requerimientos planteados es diseñar un módulo especializado en la generación y presentación de información estadística. Básicamente el problema era la cantidad de tiempo y esfuerzo que se invertía en la elaboración de cualquier tipo de información estadística, esto debido a que los usuarios se veían obligados a obtener esta información de manera manual. El presente proyecto plantea una solución a las necesidades actuales de generación y presentación automática de información estadística, dentro del sistema de apoyo académico de la universidad. El objetivo del proyecto es el siguiente: Desarrollar un módulo de generación y presentación de información estadística que forme parte del sistema de control académico computarizado para la Universidad de Guayaquil.

2 2 CAPÍTULO 1 1. TECNOLOGIA OPEN SOURCE 1.1. Problemática Al finalizar los periodos clases en las carreras e institutos que son parte de las facultades que componen a la Universidad de Guayaquil, se establecen las respectivas reuniones que tienen como finalidad conocer la situación de los alumnos y las materias impartidas, pero existen inconvenientes al no contar con los datos necesarios que permitan discernir entre los alumnos y su comportamiento a lo largo de un semestre o año y al mismo tiempo realizar una comparativa entre materias, cursos en los periodos actuales, así como también los datos históricos. Este tipo de procesos pueden tomar varios días y solo están disponibles para el personal administrativo y académico. Al no contar con esta información de forma rápida, exacta y efectiva, no se puede conocer el comportamiento de los alumnos en las materias, conocer si las materias han sufrido algún tipo de cambio de periodo a otro, y, a su vez evitar que errores pasados se vuelvan a presentar en futuros periodos.

3 Solución de la Problemática Ofrecer las opciones necesarias para que la tabulación de la información perteneciente a una institución, sea lo más eficiente y eficaz al momento de visualizarla de forma gráfica, lo que permitirá conocer las condiciones actuales de las actividades realizadas, dando la posibilidad de tomar decisiones futuras. La aplicación fue desarrollada en Jdeveloper, la base de datos utilizada es Postgres, para generar las graficas se ha usado la herramienta Ireport, el cual usa el componente JFreeChart como generador de gráficos estadísticos en dos y tres dimensiones. 1.3 Definición del Proyecto El modulo de estadísticas se genera ya que en la actualidad no se contaba con una herramienta que brinde la facilidad de realizar una consulta y que el resultado de esta no solo se muestre de manera textual sino también grafica. El modulo de estadísticas recolecta la información de los módulos de profesores, matriculación Web y alumnos, ya que básicamente de estos módulos se crearan los criterios de consulta como por ejemplo cuantos

4 4 alumnos están aprobados, suspensos y reprobados en una determinada materia. 1.4 MISIÓN Y VISIÓN Misión Implementación de un sistema académico estadístico, confiable, seguro y flexible a los procesos internos que manejan cada una de las unidades académicas de la Universidad de Guayaquil considerando la implementación practica en la Facultad de Ciencias Matemáticas y Físicas a fin de obtener la satisfacción total del personal administrativo como estudiantil Visión Contribuir con la Universidad y la Facultad de Ciencias Matemáticas y Físicas en su crecimiento tecnológico a fin de cubrir con las necesidades actuales y futuras

5 OBJETIVOS DEL PROYECTO Objetivos Generales Ofrecer las opciones necesarias para que la tabulación de la información perteneciente a una institución, sea lo más eficiente y eficaz al momento de visualizarla de forma gráfica, lo que permitirá conocer las condiciones actuales de las actividades realizadas, dando la posibilidad de tomar decisiones futuras Objetivos Específicos Desarrollar la aplicación en IReport para graficar la información sobre las notas de las materias que se imparten en los diferentes cursos. Permitir la comparación entre el rendimiento de los alumnos y las materias que han tomado para su estudio. Realizar comparativas entre el nivel de captación que tienen los alumnos acorde a la relación maestro materia. Conocer el resultado de la evaluación por parte de los alumnos y conocer la forma de cómo los alumnos asimilan la pedagogía de los profesores.

6 6 Conocer el rendimiento de los profesores y alumnos durante un. período y a su vez comparar con datos anteriores Alcance del Proyecto - Los reportes serán visualizados de forma gráfica para mejor comprensión. - Los datos podrán ser exportados a los siguientes formatos: txt, xls, pdf. - El sistema permitirá evaluar el rendimiento de los alumnos y profesores en las diferentes materias, haciendo uso de la información histórica se encuentre almacenada. - La información procesada dependerá de los datos que se ingresen en los módulos del área académica (alumnos, profesores y matriculación Web) - El módulo mostrará una herramienta que brinde la oportunidad de llevar un control específico de asignaturas, maestros y alumnos.

7 Módulo estadístico del sistema académico 7

8 Cronograma Para este proyecto se ha establecido el siguiente calendario. La fecha de aprobación indica cuándo la actividad en cuestión tiene un estado de completitud suficiente para someterse a revisión, pero esto no quita la posibilidad de su posterior refinamiento y cambios. Actividades Comienzo Finalización Preliminar Coordinación con los módulos Profesor, Alumnos y matriculación Web 18/02 25/02 Establecimientos de objetivos y alcances 26/02 08/03 Revisión de estructura de acuerdo a las posibles tablas 10/03 15/03 Definición de formatos y tipos de reporte 03/03 15/03 Tipos condensados y listados 15/03 20/03 Comparación de datos actuales e históricos Definición de tipos de gráficos estadísticos 22/03 01/04 03/04 15/04 Definición de reportes 15/04 20/04 Diseño de reportes 25/04 20/05 DESARROLLO Desarrollo de reportes 22/05 06/06 Desarrollo de parte grafica 07/06 17/06 Pruebas de reportes 18/06 02/07 Pruebas de integración 05/07 25/07

9 ESTUDIO DE FACTIBILIDAD Factibilidad Operativa. Esencialmente se enfoca a todos aquellos recursos donde intervienen todos los Procesos para la ejecución del Sistema Académico de la Universidad de Guayaquil módulo Estadístico, depende de los recursos humanos que participen durante la operación del proyecto. Durante esta etapa hemos identificado todas aquellas actividades que son necesarias para lograr el objetivo y evaluamos que se cumplirán con los siguientes objetivos: Los datos que se administraran dentro del Sistema Académico de la Universidad sean presentados de forma visual, ágil, precisa y clara. Los reportes se los podrá visualizar por medio de gráficos e informes estadísticos. La información procesada dependerá de los datos que se ingresen en los Módulos del Área Académica tanto como alumnos, profesores y matriculación Web. El Modulo brindará la oportunidad de llevar un control especifico de asignaturas, maestros y alumnos. Automatización optima de procedimientos manuales.

10 10 Reducción de costos de la Universidad mediante la optimización o eliminación de recursos no necesarios Factibilidad Técnica. Se refiere a los recursos necesarios como herramientas, conocimientos, habilidades, experiencia, etc., que son necesarios para efectuar las actividades o procesos que requiere el modulo Estadístico. Generalmente nos referimos a elementos tangibles (medibles) como: Las páginas dinámicas se ejecutan en el propio servidor web. Por lo tanto, dependerán del tipo de servidor que dispongamos, de preferencia Apache. -JSP: Lenguaje script de código abierto. Ampliamente utilizado sobre el servidor web Apache. Además se aplicará la herramienta de Programación J DEVELOPER, que trabaja en 3 capas y permite inspeccionar paso a paso el código, cuenta con un servidor interno que permite evaluar lo que se va realizando. Como manejador de Base de Datos luego del análisis de un conjunto de alternativas se trabajará con POSTGRES que permitirá conectar y administrar la base de datos.

11 11 En contraposición a las tecnologías propietarias, tenemos a nuestra disposición: HTML: lo que casi todos usan para hacer páginas web. CSS: Archivos que manejan los estilos de las páginas; se encarga de los colores de las páginas, tipo, tamaño y color de las letras JavaScript: JavaScript es un estándar. Java, y otros formatos: sí, insertar contenidos externos en una web forma parte del estándar HTML, aunque los plugins sean propietarios. XML: el futuro para estructurar datos; útil en cualquier sitio Factibilidad Económica. Vamos a detallar los recursos económicos y financieros necesarios para desarrollar las actividades, procesos y los recursos básicos que deben considerarse en el desarrollo del Sistema Académico especialmente en el módulo de Estadísticas, los mas importantes son el tiempo de concluir o culminar el modulo, el costo de la realización y el costo de adquirir nuevos recursos, entre otros.

12 12 La factibilidad económica es el elemento más importante a considerar dentro del sistema porque se solventaran las demás carencias de otros recursos ADQUISICIÓN DE HARDWARE: Procesador: Intel Pentium 4 hasta su modelo 630 (3GHz) con tecnología HP. Sistema Operativo: XP Professional, incluido en el precio. Diseño: Disponible en modelos Torre, Escritorio Compacto y Escritorio Ultra compacto Memoria: 512 Megabyte Disco duro: 80 GB Disco óptico: CD-RW/DVD-ROM Monitor: 17" Combo: Teclado y mouse óptico. Se requiere sólo un equipo para cargar el programa, que luego se subirá en los servidores correspondientes Costo: 500 usd. Incluido el IVA

13 Adquisición de Software. Sistema Operativo: Linux Suse Enterprise 9. Base de Datos: Postgres Reporteador: Ireport, JfreeChart, JasperReport Herramientas de Desarrollo: JSP Applet. Costo: Ninguno, descargables desde Internet. Costo total por HW y SW: 500 usd. Elaboración del Anteproyecto: 100 usd Logística: 100 usd Costo total del proyecto: 700 usd. Se consideró la adquisición de hosting, los datos aparecerán en el Anexo 2 Considerar Host

14 RECURSOS Las diferentes herramientas que van a formar parte de este macroproyecto, son los que la Universidad de Guayaquil nos proporciona, con ayuda de recursos propios de cada integrante. Para hacer un estudio pormenorizado de estos recursos los describiremos de la siguiente manera: Recursos Físicos El proyecto se lo desarrollara íntegramente en el Laboratorio de Computación asignado a los cursos de graduación dado por la Carrera de Ingeniería de Sistemas Computacionales de la Universidad de Guayaquil. Muy INDEPENDIENTEMENTE, salvo imprevistos que se susciten durante el transcurso del proyecto, se lo hará en el sitio de trabajo de uno de los integrantes, el cual proveerá el ambiente de trabajo para realizar el desarrollo y pruebas del mismo Recursos Tecnológicos Al igual que el recurso físico, el proyecto se lo realizara con los equipos que hay en los laboratorios de computación asignados a los cursos de graduación. Dichos equipos están a disposición de los

15 15 diferentes grupos que realizaran el desarrollo de los distintos módulos a ellos asignados. Las características mínimas de los equipos son: Computadores Pentium IV de 3.0 Ghz Disco duros de 80 Gigabytes de capacidad. Dispositivos multimedia como CD-WRITER Combo de teclado y mouse optico. Puertos Seriales, Paralelos y USB Monitor de 15 CRT. Drive 3½ Claro esta que uno de los integrantes del proyecto, pondrá a disposición su computador personal para el desarrollo del proyecto de manera PARALELA al que se realiza en la Universidad de Guayaquil. Esto se lo hace con la doble intención de ir avanzando con el proyecto y como medio de respaldo del mismo.

16 Recursos Humanos Está conformado por: Carlos Delgado Encalada. Rommel Mila Torres Tito Ramos Soledispa La asignación de tareas se dada a medida que se avance con el proyecto, debido a que por el momento TODOS los integrantes realizamos la investigación y levantamiento de información para ir estructurando el proyecto Recursos Financieros Financieramente, la Universidad de Guayaquil no realiza NINGUNA APORTACION ECONOMICA, al proyecto encomendado, por lo que los gastos corren exclusivamente por los integrantes, ya sea en la compra de materiales para talleres y/o logística que haya que realizar en el proyecto. Dichos recursos NO SON REEMBOLSABLES por la Universidad de Guayaquil.

17 Presupuesto Los costos por hardware y software, durante el desarrollo del proyecto están dados de manera intrínseca, debido a que el desarrollo se lo hace en el Laboratorio de la Universidad de Guayaquil. Ahora, si no tuviésemos los laboratorios de la Universidad de Guayaquil para el desarrollo del proyecto, entonces tendríamos que adquirir equipo y software para realizarlo. En base a esta premisa, se ha elaborado un análisis de costo de cuanto totalizaría el proyecto (desde 0) METODOLOGÍA A pesar que se había mencionado que todos los integrantes tenían que estar inmersos en la concepción desarrollo y culminación del proyecto, se hace imprescindible asignar tareas y/o responsabilidades para que de esta manera cada quien aporte con su trabajo a que el proyecto cumpla con los objetivos mencionados.

18 18 En la etapa de Análisis: Carlos Delgado Encalada. Rommel Mila Torres Tito Ramos Soledispa En la etapa de Diseño: Carlos Delgado Encalada. Rommel Mila Torres Tito Ramos Soledispa En la Etapa de Desarrollo e Implementación: Carlos Delgado Encalada. Rommel Mila Torres Tito Ramos Soledispa

19 19 En la Etapa de Implementación y Pruebas: Carlos Delgado Encalada. Rommel Mila Torres Tito Ramos Soledispa

20 20 CAPÍTULO 2 2. ANÁLISIS 2.1. Levantamiento de información Conocer la situación académica de los profesores y alumnos a lo largo de un período o períodos de clases, de forma manual, es una labor muy compleja y que tiende a coleccionar información errónea y los resultados no serían los mejores. Dar la posibilidad de que los docentes conozcan el comportamiento de los alumnos en las materias que imparten, y a su vez conocer la asimilación de la

21 21 pedagogía impuesta durante sus clases, es una labor que para el personal administrativo de la institución académica resulta ser muy laborioso. Mostrar la información resumida a través de tablas y a su vez acompañar el reporte con un gráfico el mismo que puede cambiar su forma dependiendo de la información a mostrar y el orden de la misma. La idea es mostrar gráficos de calidad que ayuden básicamente al personal administrativo y académico tomar decisiones para mejorar la calidad del área docente lo que dará como resultado profesionales de calidad dando la posibilidad de tomar decisiones futuras y le dará un mayor prestigio a la carrera y a la universidad Tipos de gráficos Desarrollar la aplicación en IReport para graficar la información sobre las notas de las materias que se imparten en los diferentes cursos. Además de permitir la comparación entre el rendimiento de los alumnos y las materias que han tomado para su estudio y realizar comparativas entre el nivel de captación que tienen los alumnos acorde a la relación maestro materia. Los datos podrán se exportados a los formatos txt, xls y pdf. Los reportes estadísticos serán mostrados desde dos ópticas distintas, en el primero se considerará datos condensados, es decir, información resumida

22 22 disgregando la información dependiendo del criterio de consulta como por ejemplo se permitirá conocer globalmente la situación de la carrera. Se podrá diferenciar información dependiendo de las materias tomadas por los alumnos, los cursos en los cuales se imparten materias comunes, el comportamiento de los alumnos en una misma materia pero en diferentes cursos, comparar información entre cursos y al mismo tiempo revisar su comportamiento en periodos anteriores. Este tipo de reportes tendrá una combinación entre datos condensados y gráficos, aunque se resaltará la información textual a mostrar. En el segundo tipo de reporte se considerará solamente gráficos de dos y tres dimensiones como el pastel, barra de dos dimensiones y barra de tres dimensiones, permitiendo al usuario escoger el tipo de grafico que se desea visualizar y que información quiere considerar. El tipo de información dependerá exclusivamente de los módulos: profesores, alumnos y matriculación Web. Si el usuario solicita, la información se presentara un informe dependiendo de las opciones que escoja, se podrá escoger entre varias opciones el o los criterios de discriminación de la información.

23 Generación de reportes fácilmente El usuario seguirá varios pasos de forma secuencial para generar el tipo de reporte que desea, tomando en consideración cada uno de los puntos que ofrece la consulta Fácil Implementación En primera instancia para la consideración del Sistema Académico es el sistema operativo con que se trabajaría, entre las ventajas de principales de la tecnología Open Source es que no existen costos de licencia en si mismo. El mayor diferenciador de todos modos es el que el usuario puede, además obtener el código fuente. Esto le brinda independencia del proveedor "contribuyente original" en el lenguaje de Código Abierto. De este modo el usuario no depende de su existencia y prioridades. Toda la información, estado, errores-bugs, etc. es abierta también, no existe política de ocultamiento corporativa ni censura. Si algo no funciona, no tendrá inconveniente en averiguarlo rápidamente. Como consecuencia, los proyectos de Código Abierto son muy rápidos para reaccionar, si surgen problemas. Un desafío de todos modos es el que usted necesita decidir la importancia de los inconvenientes que pudiesen surgir y el impacto en su

24 24 propio proyecto. Se utiliza como sistema operativo a Linux que es el sistema más flexible para poder conectarse a cualquier ordenador del mundo. Internet se creó y desarrollo dentro del mundo de Unix, y por lo tanto Linux tiene las mayores capacidades para navegar, ya que Unix y Linux son sistemas prácticamente idénticos. Se podrá montar un servidor en su propia casa sin tener que pagar las enormes cantidades de dinero que piden otros sistemas. No se sacrifica en ningún momento la creatividad, tal y como lo hacen algunas compañías informáticas. Linux es una ventana abierta por la que es posible huir hacia un mundo donde la verdadera informática puede ser disfrutada sin límites ni monopolios. También se considera las posibilidades de servidores de Páginas que es la parte primordial de cualquier sitio de Internet, ya que es el encargado de generar y enviar la información a los usuarios finales. Realizamos los siguientes análisis de servidores:

25 SERVIDORES Servidor de Páginas "Web Server" y Servidor de Aplicaciones "Application Server"? En un sentido muy estricto un "Web Server" no es lo mismo que "Application Server", pero últimamente estos dos términos se prestan a una gran confusión especialmente en la elección de uno de ellos para la realización de Páginas Web. Cuando se crearon los primeros Servidores de páginas ("Web Server") como Apache, éste solo era encargado de enviar los datos al usuario final, pero cualquier otra información que requiriera de algún tipo de personalización era realizada por un interpretador que ejecutaba un "script" (programa), generalmente en Perl.Sin embargo, conforme las demandas de los Servidores de páginas ("Web Server's") incrementaron fue necesario eficientizar este proceso, ya que el llamar un interpretador para que ejecutara otro programa (en el caso Perl) ponía una demanda muy fuerte sobre el "Host" que mantenía el Servidor de Páginas ("Web Server") Hoy en día, se pudiera decir que TODOS los "Servidores de Páginas" ya son "Servidores de Aplicaciones" ya que se les ha desarrollado alguna funcionalidad especial que les permite realizar, valga la redundancia, aplicaciones de servidor. Y para agregar a la confusión en la Industria hoy

26 26 día ya abundan los "Java Application Servers" que son otra cosa muy diferente y malamente ya son designados "Application Servers" o "Servidores de Aplicaciones" a solas. Dependiendo de la funcionalidad se trae consigo complejidad al sistema, ya sea en la forma de requerimientos del sistema (memoria, procesadores), carga administrativa (configuración, tiempo de desarrollo) o alguna otra. Requisición común: En el diagrama anterior se puede observar que un navegador ("Netscape" o "Explorer") solicita información al servidor de páginas, esta solicitud inicial se lleva acabo mediante HTTP, sin embargo, una vez que esta solicitud llega al Servidor ésta puede tomar varias acciones. En el esquema las lineas punteadas ( ) representan un proceso/programa dentro del "Host" (computadora física), bajo esta hipótesis se describirán los "Servidores de Páginas".

27 Apache Apache es uno de los Servidores de páginas más utilizados, posiblemente porque ofrece instalaciones sencillas para sitios pequeños y si se requiere es posible expandirlo hasta el nivel de los mejores productos comerciales. Si se utiliza para un sitio pequeño que solo contenga archivos en HTML, esto es, no requiera de aplicaciones de servidor su funcionalidad es excelente, pero que sucede cuando se requiere una aplicación de Servidor? La aplicación de servidor implica lo siguiente: Cuando el servidor de páginas (Apache) recibe la requisición para "x" página éste reconoce cuando debe enviar un documento estático (HTML) o ejecutar algún tipo de aplicación, en el diagrama se puede observar que la solicitud de "x" página invoca (llama) un programa en Perl y este a su vez solicita información a una base de datos, por lo tanto para llevar acabo esta operación debieron iniciarse 2 procesos nuevos, quizás esto no sea de gran importancia para un sitio de 100 visitas diarias, pero que sucedería con uno de 2 visitas por segundo?

28 28 Si no se tienen los suficientes recursos en cuanto a memoria y procesadores se refiere, seguramente caerá el servidor de páginas o bien se queme el "Host" (computadora física) por la demanda excesiva. Apache tiene tanto tiempo de desarrollo que han sido desarrolladas diferentes soluciones para evitar estas ineficiencias, algunas: Es capaz de utilizar otros interpretadores y lenguajes como "Tcl", "PhP" y "Python". Puede conectarse directamente a una Base de datos. Entre otras, posee diversos módulos que le permiten utilizar una gran gamma de lenguajes y desarrollar funcionalidades avanzadas. Cabe mencionar que muchos sitios de alto tráfico aún permanecen bajo este tipo de Arquitectura, en ocasiones si se tienen los recursos suficientes continua siendo costeable esta metodología a migrar a otro tipo de desarrollo, sin embargo, siempre es conveniente conocer otras alternativas.

29 AOLServer AOLServer al igual que Apache es un producto open-source pero a diferencia de este último, fue diseñado conociendo varias deficiencias que existían en el modelo inicial utilizado por Apache. AOLServer desde sus versiones iniciales fue desarrollado con "Threading" en mente, esto es, compartir la memoria del Proceso general en varios subprocesos o "Threads", esto no solo eficientiza las de páginas sino también reduce la carga sobre el conexiones al servidor mismo. Además de "Threading" AOLserver integra un Interpretador en su estructura interna evitando generar un proceso nuevo por aplicación de mantiene grupos de conexiones latentes ("pools") hacia bases servidor y de datos también para evitar generar procesos nuevos. Otra ventaja de AOLServer es el ofrecimiento de ADP ("Aol Dynamic Pages") que son muy similares a las ASP's (Active Server Pages) de Microsoft o JSP's (Java Server Pages) de Sun, la diferencia estriba que

30 30 ADP's utilizan el lenguaje Tcl y un API especialmente diseñado para accesar los elementos del servidor, pero su funcionamiento es igual al de ADP y JSP: mezclar elementos de HTML con elementos de programación para generar contenido dinámico. Como último punto es utilizado por una de las empresas con mayor tráfico en Internet America Online, el proveedor de Servicios de Internet (ISP) más grande del mundo. Un poco más en Ventajas y Desventajas comparado con Apache IIS (Information Server) IIS es el servidor de páginas desarrollado por Microsoft para Windows NT/2000, a diferencia de los dos servidores de páginas mencionados anteriormente, IIS solo puede operar en plataformas Windows. El punto más favorable de este servidor son ASP's que facilitan el desarrollo de aplicaciones y la "sencillez" de instalación, sin embargo, existen alternativas como ADP's de Aolserver y JSP's para Java. Desafortunadamente debido a la presencia de Microsoft en el Mercado seguirá siendo necesario interactuar con este producto a pesar de todas sus desventajas:

31 31 Plataforma: Solo esta disponible para Windows. Historia de Sistemas Operativos para Red y Porque es mas fácil y Económico configurar Unix que Windows en Red Costo: Porque pagar licencia si existen productos flexibles y opensource mejores. Confiabilidad: Menos confiable que otros productos, tan confiable que ni sus mejores técnicos podían utilizarlo cuando se encontraba bajo uno de los tantos ataques que sufren sitios de Internet: Seguridad: Aún plagado de fallas en versiones de producción: Otros Servidores Similares 1. Zope : Zope es un servidor de páginas open-source que utiliza Python como su "Scripting Language" y es capaz de acceder un gran numero de bases de datos "Servlet Engines" y "Java Application Servers"

32 Servlet Engines Quizás el nombre que más salga a relucir con "Servlet Engines" es Tomcat o Jakarta Apache. Tomcat surgió de Sun Microsystem's cuando desarrollaban un "Servidor de Páginas" que utilizara "Java",y posteriormente cedieron el código fuente a la fundación Apache. A pesar del nombre Apache-Tomcat; Tomcat no requiere de Apache para su funcionamiento (solo requiere de un JDK ("Java Development Kit") y es aquí donde dista un poco de las previas implementaciones: En la figura anterior la línea roja demuestra que el Servlet engine (también llamado "Web Container") es capaz de responder a requisiciones de Internet, en efecto actuando como "Servidor de Páginas", sin embargo, aunque esto sea posible la gran mayoría de las implementaciones de Servlet Engines no funcionan tan eficiente como un "Servidor de Páginas", es por esto (y otras razones que a continuación se mencionan) que se opta por utilizar un "Servidor de Páginas" (Apache, Aol, Netscape..) en conjunción con un "Servlet Engine".

33 33 La linea verde demuestra la utilización de un "Servidor de Páginas" con un "Servlet Engine" (Web-Container), esta implementación suele cuando se requiere utilizar encriptación o se tiene un sitio que documentos puros en HTML, las cuales son dos areas que un utilizarse contiene "Servidor de Páginas" supera en desempeño comparado con un "Servlet Engine". La comunicación entre el "Servidor de Páginas" y el "Servlet Engine" se lleva acabo mediante el protocolo denominado ajp12 y recientemente con su sucesor ajp13. Que hace el Servlet Engine? El "Servlet Engine" ofrece un "Ambiente" donde habitan los JSP y Servlets, es ahí donde se contemplan una gran cantidad de funcionalidades como: threading, manutención de sesiones, conectividad con el "Servidor de Páginas", es por esto al "Servlet Engine" también se le denomina "Web- Container". Dos "Servlet Engines" (Web-Containers) que están en amplio uso y son utilizados con "Servidores de Páginas" son: Tomcat y ServletExec, donde el primero es open-source y el último es un producto cerrado; otro "Servlet Engine" es Resin (Open-Source) el cual permite: utilizar JavaScript como "Scripting Language" dentro de JSP's y acceso a XSL una extensión de XML.

34 34 Como se observa en el diagrama también se requiere de un JDK ("Java Development Kit"), el cual llevará acabo la ejecución de los programas ("Servlets" y "JSP's") en Java; como toda otra implementación existen diversas versiones de JDK's, esto se debe a que cada JDK debe ser diseñado alrededor de un Sistema Operativo (para ser más exactos es el JVM "Java Virtual Machine" el que debe ser diseñado alrededor del Sistema Operativo ), algunos JDK's son: J2SE's (Java 2 Standard Edition) de Sun y JDK's de IBM Java Application Servers "Java Application Servers" hoy en día ya denominados "Application Servers" ofrecen una manera de Integrar y ofrecer las funcionalidades requeridas por la gran mayoría de sistemas empresariales, una de las razones por las cuales el mercado ha sido inundado con estos "Application Servers" es que están diseñados alrededor de J2EE, que es solo un grupo de especificaciones definidas por Sun. Estos "Application Servers" comúnmente llamados Middleware se encuentran compuestos de la siguiente manera:

35 35 Como su denominación lo implica ("Middleware") se encuentran en la parte media de una arquitectura de sistema, su flexibilidad reside en la posibilidad de accesar información en sistemas empresariales (EIS) como SAP, JdEdwards, bases de datos o alguna aplicación escrita en COBOL u otro lenguaje. Dependiendo de la empresa que desarrolle el "Application Server" éste puede contener inclusive hasta un "Servidor de Páginas" o algún otro desarrollo propietario, sin embargo, los dos elementos primordiales (aunque no sean comercializados como tal) son el "Servlet Engine" (Web- Container) y "Enterprise Bean Engine" (Bean-Container).

36 36 Que hace el Servlet Engine y Enterprise Bean Engine? El Servlet Engine (Web-Container) en un "Application Server" realiza las mismas funcionalidades que fueron mencionadas anteriormente.(ofrecer un ambiente para JSP y Servlets). El "Enterprise Bean Engine" (Bean-Container) ofrece un "ambiente" donde residen EJB's ("Enterprise Java Beans"), es mediante "Enterprise Java Beans" que se ejecuta la lógica de negocios sobre la información que reside en los sistemas empresariales ("EIS"). En el "Bean Container" (al igual que en el "Web Container") se contemplan varias funcionalidades: "Pooling" hacia bases de Datos (JDBC),control de transacciones(jta-jts),conectividad con ERP(Connectors),aplicaciones legacy(corba),entre otras cosas. La mayor ventaja de este tipo de arquitectura se debe a la separación de funcionalidades y uso de protocolos de red como RMI/CORBA, esto facilita que puedan existir 4 o 5 "Hosts" en diferentes regiones geográficas, cada uno empleando cualquiera de los componentes antes mencionados. Por último, existen diversos "Application Servers" que son denominados "Fully J2EE Compliant" esto indica que cumplen con todas las especificaciones J2EE indicadas por Sun.

37 DISEÑO DEL SISTEMA Casos de Uso Introducción El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos: Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicación Elementos Actor: Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con

38 38 esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local. Caso de Uso: Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. Relaciones: o Asociación Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. o Dependencia o Instanciación Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

39 39 o Generalización Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). Uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar Elaboración de los casos de uso del proyecto Interfase Web para interactuar remotamente con los módulos del sistema cadémico de la Carrera de Ingeniería en Sistemas Computacionales de la Universidad de Guayaquil.

40 40 La interfase web debe permitir el acceso a Sistemas académico dándole al usuario las opciones dinámicas de: Registrarse como usuario del sistema académico. Visualizar el menú de opciones del sistema académico: a. Biblioteca Virtual b. Prestamos de equipos c. Sysllabus d. Mail e. Profesor f. Matriculación g. Estadisticas h. Forum Un usuario tiene privilegios para acceso a opciones: a. El usuario alumno b. El usuario profesor c. El usuario administrativo El usuario desea cambiar tipo de apariencia de su pagina: a. Usando una plantilla de iconos, fuentes y fondos. b. Visualizar con iconos las opciones del menú en una barra de tareas El usuario desea descargar archivos importantes: a. Deberes o talleres

41 41 b. Reportes de notas c. Otras opciones de los menús El usuario debe poder añadir una foto suya en : a. La ventana visualizada b. En el archivo de registro de estudiantes en la base de datos FLUJO DE VENTANAS Flujo de procesos de ventanas: Estadísticas de evaluación de profesores. Nombre: Evaluación de profesores. Actores: Profesores - Administradores Función: Presentar la calificación de los profesores considerando las evaluaciones realizadas a los alumnos en cada una de las materias que imparten. Descripción: El usuario podrá visualizar la calificación luego de las evaluaciones que se realizan a los alumnos sobre la calidad, capacidad y comportamiento de los docentes en las materias que tienen asignadas. El gráfico mostrará la calificación de 5 categorías, excelente, muy bueno, bueno regular y malo.

42 42 FORMATOS DE EVENTOS Evento: Presentación de evaluación de profesores. 1. Escoger la forma de cómo se desea mostrar la información, todos, por nombre, identificación, o fecha de ingreso. 2. Ejecución de sentencias SQL para mostrar datos en pantalla de acuerdo al requerimiento. 3. Listado de profesores y las materias asignadas a cada uno. 4. Escoger una materia de un profesor, o escoger el profesor para ver la situación de todas sus materias. 5. Ejecución de los Bean de Datos: mostrará el gráfico dependiendo de la opción escogida Flujo de procesos de ventanas: Estadísticas de Materias Nombre: Notas por materia. Actores: Profesores - Administradores Función: Presenta el rendimiento de los alumnos en la materia o materias presentadas. Descripción: El usuario podrá visualizar el rendimiento de los alumnos en una materia específica, lo que permitirá conocer el número de alumnos aprobados, reprobados y aquellos que van a recuperación.

43 43 FORMATOS DE EVENTOS Evento: Presentación de Notas por Materias. 1. Escoger la forma de cómo se desea mostrar la información, todas, o por nombre. 2. Ejecución de sentencias SQL para mostrar datos en pantalla de acuerdo al requerimiento. 3. Listado de las materias. 4. Escoger una materia. 5. Ejecución de los Bean de Datos: mostrará el gráfico dependiendo de la materia escogida Flujo de procesos de ventanas: Estadísticas de Alumnos Nombre: Estadísticas por alumnos. Actores: Profesores - Administradores Función: Presenta el rendimiento de los alumnos en la materia o materias presentadas. Descripción: El usuario podrá visualizar el rendimiento de los alumnos en las materias que cursa durante un período de clases, y su comportamiento en períodos anteriores. FORMATOS DE EVENTOS Evento: Presentación de Estadísticas por alumnos.

44 44 6. Escoger la forma de cómo se desea mostrar la información, todos, por nombre o identificación. 7. Ejecución de sentencias SQL para mostrar datos en pantalla de acuerdo al requerimiento. 8. Listado de alumno(s). 9. Escoger un alumno. 10. Ejecución de los Bean de Datos: mostrará el gráfico dependiendo del alumno escogida DIAGRAMA DE FLUJO DE DATOS (DFD) El diagrama de flujo de datos es un modelo que describe los flujos de datos o tuberías, los procesos que cambian o transforman los datos en un sistema, las entidades externas que son fuente o destino de los datos (y en consecuencia los límites del sistema) y los almacenamientos o depósitos de datos a los cuales tiene acceso el sistema, permitiendo así describir el movimiento de los datos a través del sistema.

45 45 En síntesis, el Diagrama de Flujo de datos describe: Los lugares de origen y destino de los datos(los límites del sistema) Las transformaciones a las que son sometidos los datos(los procesos internos) Los lugares en los que se almacenan los datos dentro del sistema Los canales por donde circulan los datos Características Relevante: ya que posibilita comunicar diferentes modelos para así facilitar el entendimiento entre el usuario y el analista de sistemas Lógico: ya que no identifica soporte físico Descendente: Se construye en forma descendente de lo general a lo particular El DFD posee niveles de desagregación o explosión o apertura de burbujas. El Nivel 0 o Diagrama de Contexto es aque que muestra una sola burbuja y las entidades externas o terminadores con los que interactúa el sistema.

46 SIMBOLOGÍA Entidad Externa Son generalmente clases lógicas de cosas o de personas, las cuales representan una fuente o destino de transacciones, como por ejemplo clientes, empleados, proveedores, etc., con las que el sistema se comunica. También pueden ser una fuente o destino específico, como por ejemplo Departamento Contable. Como el sistema que esta bajo análisis acepta datos de otro sistema o bien se los provee, este otro sistema es una Entidad Externa. Mediante la designación de alguna cosa o de algún sistema como Entidad Externa estamos estableciendo implícitamente que se encuentra fuera de los límites del sistema que estamos considerando por lo cual no nos interesa la transformación o proceso que se realiza dentro de ellos, es decir que están fuera del control del sistema que se está modelando. Son sólo proveedores o requeridores de datos del sistema bajo consideración. Por todo ello, ni el analista ni el diseñador pueden cambiar ni los contenidos ni la forma de trabajo de un terminador.

47 Proceso Indican aquellos lugares dentro del sistema en donde la información (flujos de datos) que ingresan se procesan o transforman. Es decir, son las funciones o procesos que transforman entradas de datos en salidas de información. Su nombre deberá ponerse mediante una frase imperativa, que consistirá idealmente de un verbo activo seguido por una claúsula objeto, cuanto mas simple mejor. Al analista le servirá pensar que la descripción de la función es "una orden a un empleado sin conocimiento del tema". Estas frases imperativas no tienen sujeto; tan pronto como se introduce un sujeto se habrá indicado como deberá realizarse físicamente la función ("El operador ingresará los datos del alumno"). Un proceso puede ser físicamente una oficina repleta de empleados, un procedimiento, o una combinación de actividades manuales y automatizadas.

48 Flujo de datos Representa un transporte de paquetes de datos desde su origen hasta su destino, es decir que representa una estructura de datos en movimiento de una parte del sistema a otro. Un flujo muestra las interfaces entre los elementos del DFD. Puede imaginarse como una tubería por donde se envían paquetes de datos, pero deberá tener una descripción de su contenido la cual deberá elegirse de forma que sea lo más útil posible a los usuarios que revisen el DFD. La flecha indica la dirección del flujo. Puede estar contenido físicamente en una nota, una factura, una llamada telefónica, de programa a programa, etc. Es decir, en cualquier medio por el cual los datos pasan de una entidad o proceso a otra Almacén o archivo Representa un archivo lógico en donde se agregan o de donde se extraen datos. Es una estructura de datos, pero estática.

49 49 Puede ser físicamente un archivo de tarjetas, una microficha, un archivo, o un archivo en cinta o diskette. Deberá elegirse el nombre que sea más descriptivo para el usuario, que identifique los paquetes de datos que contiene. Implica escritura, actualización o borrado de datos. Implica lectura o recuperación de información almacenada Guías para construir un DFD Primero se deberán identificar las entidades externas ya que ello implica definir los límites del sistema. Se deberán elegir nombres con significado tanto para procesos como también para flujos de datos, almacenes y entidades externas. Si es posible a partir del vocabulario del usuario evitando terminologías técnicas. Identificar el papel del proceso del sistema, no quien lo realiza. Numerar los procesos, mediante un esquema de numeración consistente que implique, para los lectores del DFD, una cierta secuencia de ejecución.

50 50 Se deberán, en la medida de lo posible, evitar los DFD excesivamente complejos. Deberán ser comprensibles, digeribles y agradables a la vista sin demasiados elementos. Todos los elementos se relacionan entre sí a través de flujos de datos. Procesos: Se relacionarán con:almacenes, Entidades externas,otros Procesos. Deberán tener almenos una Entrada y una Salida, no son manantiales de datos Almacenes: Se relacionarán solamente con Procesos. Entidades Externas: Se relacionarán solamente con Procesos. En todos los niveles del Diagrama de Flujo de Datos deberá haber igual cantidad de Entradas y de Salidas. Niveles del DFD: Nivel de Partida o Diagrama de Contexto: No existirán almacenes o archivos, se representarán las entidades externas que son fuente y destino de los datos, el sistema será representado como un proceso simple, sefdibujarán sólo los flujos de datos de comunicación exterior-sistema. Nivel 1 y subsiguientes: Deberá haber igual cantidad de archivos. Aunque podrá existir mayor cantidad de almacenamientos en el nivel 2 debido a la explosión de algún proceso. En el último nivel, cada proceso realizará una función específica y concreta.

51 51 Cada proceso en el DFD de alto nivel de un sistema puede ser "explotado" para convertirse en un DFD en si mismo. Cada proceso en el nivel inferior deberá estar relacionado, inversamente, con el proceso del nivel superior. Es decir que, cada proceso padre que se detalla en el DFD, ha de estar balanceado. La regla del balanceo consiste en que cada proceso debe tener exactamente los mismos datos de entrada/salida netos que el DFD hijo. Los flujos de datos pueden descomponerse en la explosión del proceso en un DFD hijo. No se deberá prestar atención a las condiciones de tiempo, excepto a las naturales precedencias lógicas y a los almacenamientos de datos necesarios desde el punto de vista lógico. Se deberá dibujar un sistema que nunca comience ni pare. Para evitar el cruzamiento de las líneas de flujo de datos, la misma entidad (o el mismo almacén) se podrá dibujar mas de una vez en el mismo diagrama; las dos (o mas) casillas por entidad pueden identificarse con dos líneas inclinadas en el ángulo superior izquierdo de las mismas. Elegir nombres con significado para todos los componentes: Para los procesos: Identificar las funciones que el sistema está llevando

52 52 a cabo. Usar un verbo y un objeto. Evitar verbos ambiguos: hacer, manejar, procesar, etc. Numerar los procesos:como forma abreviada de identificar las burbujas, base para la numeración jerárquica. Redibujar el DFD tantas veces como sea necesario para que sea: Técnicamente correcto, Aceptable para el usuario,estar lo suficientemente bien dibujado para mostrarlo a la dirección de la organización Evitar los DFD demasiado complejos, deben ser leídos y comprendidos Todos los flujos y procesos deben estar etiquetados Tener cuidado con los almacenes de sólo lectura o sólo escritura En sistemas típicos, simples 2 o 3 niveles, medianos 3 a 6, grande 5 a 8. Un enfoque que tiene más éxito es identificar los acontecimientos externos a los cuales debe responder el sistema y utilizarlos para crear un primer borrador del DFD. De ahí puede partirse hacia arriba (para crear DFD de mayor nivel de abstracción) y hacia abajo.

53 53

54 54 CAPITULO DESARROLLO Y PRUEBA DEL SISTEMA Desarrollo del Sistema a. Definición de Reportes a generar. Los grupos consideraos para la generación de reportes son: Profesores, alumnos y materias, esta información se encuentra almacenada en la base de datos Sistema _ académico.

55 DESCRIPCIÓN DE LOS REPORTES Reporte de profesores Para generar los Reportes de profesores, la información debe ser alimentada a través de los Módulos profesores y matriculación Web ya que ellos se encargaran de almacenar la información personal y académica de los docentes y las calificaciones obtenidas por las evaluaciones hechas por los alumnos, así como también las calificaciones obtenidas por los alumnos en las diferentes materias que imparten los profesores. Los gráficos que se generen serán de dos tipos, gráficos de barra y gráficos tipo pie. Al momento de consultar la información se mostrara un listado de todos los profesores o el profesor seleccionado con cada una de las materias que el imparte, de esta forma se puede conocer la situación de los alumnos (aprobados, reprobados y recuperación), en cada una de las materias asignadas; y también el usuario conocerá en que categoría se encuentra luego de la evaluación que realiza la administraron de la carrera a los alumnos de todos los semestres.

56 Reporte de alumnos Para generar los Reportes de alumnos, la información debe ser alimentada a través de los Módulos alumnos y matriculación Web ya que ellos se encargaran de almacenar la información personal de los alumnos para que el docente pueda avaluar a los alumnos y así asimilar el rendimiento de las materias que ha tomado durante un periodo determinado, considerando las calificaciones de cada una de las materias que el cursa. La información se mostrara en gráficos de barra. También se podrá optar por ver el rendimiento de alumno en periodos pasados Reporte de materias Para generar los Reportes de materias, la información debe ser alimentada a través de matriculación Web ya que se encarga de la definición de periodos, ciclos y almacenamiento de las calificaciones de los alumnos. La información mostrara el rendimiento de los profesores en una o varias materias y en cualquiera de los periodos registrados; mostrando el rendimiento de los alumnos en dicha materia.

57 PRUEBAS DEL SISTEMA En el trayecto del sistema se pudo apreciar las características de los gráficos que iban cambiando de acuerdo a la información que se iba ingresando en la base de datos. Depende principalmente de los datos que se vayan tomando de los módulos de profesores, materias y matriculación Web. Dando como resultado varios tipos de gráficos ya sea en 2 dimensiones o tres dimensiones, llegando a su forma ideal MODELO DE PRUEBA Se ha basado en el siguiente flujo para pruebas como se detalla a continuación: Configuración del software Correcciones Resultados Prueba Evaluación Errores Depuración Se propor Configuración de prueba Resultados esperados Modelo de fiabilidad Datos de tasa de error Predicción de fiabilidad

58 58 cionan dos clases de entradas al proceso de prueba: una configuración del software que especifica los requisitos del software, diseño y el código fuente; La otra es una configuración de prueba que incluye un plan de procedimiento de prueba. Se realizan las pruebas correspondientes y se evalúan los resultados, se comparan los resultados de la prueba con los esperados. Si encontramos errores se comienza con la depuración. A medida que se van recopilando y evaluando los resultados de la prueba, van surgiendo medidas de la calidad y de la fiabilidad del software; Si se encuentran con regularidad serios errores que requieren de modificaciones en el diseño, la calidad y la fiabilidad quedan en entredicho, siendo necesaria a posteriores pruebas. Si por otro lado, el funcionamiento parece ser correcto y los errores que se encuentran son fáciles de corregir, entonces, la calidad y la fiabilidad son aceptables, o las pruebas son inadecuadas para descubrir errores serios. Finalmente, si la prueba no descubre errores, éstos serán descubiertos por el usuario y corregidos por el profesional durante la fase de mantenimiento.

59 59 La evaluación se lleva a cabo conforme progresa el desarrollo en los módulos del programa, la evaluación se realiza a diferentes niveles y a varios intervalos, aún antes de que el sistema entre en operación, todos los programas deben de examinarse en cuanto a su diseño con datos de prueba y verificar si los módulos se enlazan entre sí, tal y como fue planeado Objetivos de la prueba Verificar que los datos ingresados por los módulos (Profesores, Alumnos y Matriculación Web) relacionados al nuestro sean los correctos. Y a su vez revisar que los resultados mostrados sean los solicitados. El objetivo es diseñar pruebas que saquen a la luz diferentes clases de errores en el sistema, haciéndolo en la menor cantidad de tiempo y esfuerzo. Si la prueba se lleva a cabo con éxito se descubrirán errores en el sistema, otra ventaja es que la prueba demuestra hasta qué punto el sistema funciona de acuerdo con las especificaciones y alcanza los requisitos de rendimiento deseados. Además los datos que se van recogiendo a medida de que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del sistema e indican la calidad del mismo como un todo.