Refactorización del módulo de control de alumnos ayudantes del SIGENU

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad de Matemática – Física – Computación Departamento de Producción de Software. TRABAJO DE DIPLOMA TÍTULO: REFACTORIZACIÓN DEL MÓDULO DE CONTROL DE ALUMNOS AYUDANTES DEL SIGENU.. Autores: Beyda González Camacho Lizabeth Duardo Muñoz. Tutor: Lic. YOSVEL REYES FONFRIA. Santa Clara 2010 "Año 52 de la Revolución".

(2) Universidad Central “Marta Abreu” de Las Villas Facultad de Matemática-Física-Computación Departamento de Producción de Software. TRABAJO DE DIPLOMA Título: Refactorización del Módulo de Control de Alumnos Ayudantes del SIGENU.. Autor: Beyda González Camacho ([email protected]) Lizabeth Duardo Muñoz ([email protected]) Tutor: Lic. Yosvel Reyes Fonfria. Santa Clara 2010 "Año 52 de la Revolución".

(3) Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ciencias de la Computación, autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.. Firma del Autor Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del Autor. Firma del Jefe de Departamento donde se defiende el trabajo. Firma del Responsable de Información Científico-Técnica.

(4) i. PENSAMIENTO. "Daría todo lo que sé, por la mitad de lo que ignoro." René Descartes.

(5) ii. DEDICATORIA Dedicamos este trabajo a nuestros padres, demás familiares, y a nuestras amistades más allegadas..

(6) iii. AGRADECIMIENTOS Agradecemos a nuestros padres, a nuestro tutor y a todas las personas que de una forma u otra contribuyeron a la realización de este trabajo..

(7) iv. RESUMEN El presente trabajo aborda la temática de la refactorización del Módulo de Control de Alumnos Ayudantes del Sistema de Gestión de la Nueva Universidad (SIGENU). Se investigan temas tales como J2EE, desarrollo dirigido por modelos (MDA) y las herramientas disponibles para realizar este tipo de tarea. Se describe la implementación de nuevas funcionalidades en el Módulo de Control de Alumnos Ayudantes, además de completar una revisión técnica donde se detectan las principales deficiencias y se proponen vías de solución para las mismas..

(8) v. ABSTRACT This study focuses on the "Assistants Students Control Module" refactoring for the SIGENU application. It covers topics such as J2EE, Model Driven Architecture (MDA) and the available tools to work on such environments. It describes the implementation of new features in the Assistant Students Control Module, also complete a technical review was performed to detect the main weaknesses and suggests ways for solving them..

(9) vi. ÍNDICE INTRODUCCIÓN .................................................................................................... 1 CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO. DE ALUMNOS. AYUDANTES DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.......... 5 1.1. Sistema de Gestión de la Nueva Universidad (SIGENU).......................... 5. 1.1.1 1.2. Módulo de Control de Alumnos Ayudantes ........................................ 6. Estrategias para el desarrollo. .................................................................. 6. 1.2.1. Patrones de diseño. ........................................................................... 7. 1.2.2. J2EE™ ............................................................................................... 7. 1.2.3. Contenedores en J2EE™ .................................................................. 9. 1.2.4. Aplicaciones clientes. ....................................................................... 10. 1.2.5. Hibernate. ........................................................................................ 11. 1.2.6. Sistema gestor de base de datos. .................................................... 11. 1.2.7. MDA (Model Driven Architecture)..................................................... 12. CAPÍTULO 2: ASPECTOS METODOLÓGICOS REFERENTES AL DISEÑO E IMPLEMENTACIÓN DEL SISTEMA. ..................................................................... 14 2.1. Descripción del sistema. ......................................................................... 14. 2.2. Modelación del Sistema. ......................................................................... 14. 2.2.1 2.2. Descripción de los Casos de Uso. ................................................... 14. Implementación del sistema. .................................................................. 16. 2.2.1. Gestión de los usuarios del sistema................................................. 16. 2.2.2. Funciones de configuración. ............................................................ 19. CAPÍTULO 3: ESTADO FINAL DE LA APLICACIÓN. ........................................... 23 3.1. Manual de instalación. ............................................................................ 23.

(10) 7 3.2. Manual de Usuario. ................................................................................. 23. 3.2.1 3.3. Estado final. ............................................................................................ 26. 3.3.1 3.4. Nuevas opciones del módulo Desktop del sistema. ......................... 24. Generación de reportes. .................................................................. 26. Estado de la conexión con el SIGENU. Versión 2.5.1. ........................... 27. 3.4.1. Seguridad en el ambiente Desktop. ................................................. 27. 3.4.2. Capa intermedia (Aminotaur). .......................................................... 28. CONCLUSIONES ................................................................................................. 29 RECOMENDACIONES ......................................................................................... 30 REFERENCIAS BIBLIOGRÁFICAS ...................................................................... 31 ANEXOS ............................................................................................................... 34.

(11) INTRODUCCIÓN. 1. INTRODUCCIÓN Hoy para que el hombre esté a nivel de su tiempo es imprescindible también dominar la tecnología y a la vez aprender con ella. Vivimos en la sociedad de la información (Vaquero, 1997). El reconocimiento de la trascendencia del dominio de la tecnología digital por todos los cubanos se refleja en el proceso de informatización de la sociedad, que pretende satisfacer las necesidades de información y conocimiento de todas las personas y esferas mediante la utilización ordenada y masiva de las tecnologías de la información. Para ello se elaboró el Programa Rector de la Informatización de la Sociedad en Cuba que responde al proyecto político y social del país y expresa la estrategia de informatización. En este contexto, la Estrategia Maestra de Informatización de las Universidades cubanas está encaminada a transformar cualitativamente los procesos sustantivos de la Educación Superior, mediante el empleo de las Tecnologías de la Informatización y las Comunicaciones, alcanzando niveles superiores de formación y superación del capital humano, de integración y colaboración mediante las redes nacionales e internacionales, y de creación y desarrollo de recursos, servicios y herramientas basadas en el conocimiento. El Ministerio de Educación Superior (MES), para facilitar el trabajo en las Universidades tiene entre sus directrices el desarrollo de la informática en Cuba. Así lo reafirma el Sistema de Gestión de la Nueva Universidad (en lo adelante SIGENU), el cual resultó uno de los 23 proyectos seleccionados para participar en el stand nacional de la Feria Informática 2009.(Corzo, 2009) Este programa, elaborado sobre la base del software libre por especialistas de la Ciudad Universitaria José Antonio Echeverría (CUJAE), nació con el objetivo de lograr un solo producto de automatización de los procesos docentes para todos los centros universitarios..

(12) INTRODUCCIÓN. 2. Desde 2004, se implementó en la CUJAE, la Universidad Agraria de La Habana y en la Universidad de Cienfuegos y actualmente se utiliza en todos los centros adscritos al MES. El SIGENU permite registrar los datos de los estudiantes desde el momento de la matrícula hasta que se gradúan o causan baja definitiva, incluyendo bajas temporales, licencia, repitencia, reportes evaluativos, y el cambio del lugar de residencia, entre otros. Este sistema cuenta con dos tipos de aplicaciones: uno de gestión que facilita la captura de la información para el trabajo diario en las secretarías docentes de las universidades y otro que brinda soportes para la toma de decisiones. Este mecanismo permite al usuario acceder de manera ágil y eficiente a la información cuando la necesite, mediante consultas y gráficos dinámicos, con una descripción detallada de la historia del estudiante durante la carrera, cuyos informes permanecen en una Base de Datos. Mediante este sistema todas las Universidades cubanas pueden rendir estadísticas al MES como centro rector, para ello se implementó un mecanismo de intercambio de información a partir de ficheros que pueden ser descargados en el Ministerio y ser procesados para obtener los resultados deseados. Una de las principales definiciones del proyecto SIGENU fue la de utilizar software libre. Esta es una necesidad que emerge del tránsito necesario del país hacia el uso del software libre, de compromisos internacionales que tiene Cuba en este sentido, además de brindar posibilidades de extensión de tales productos de software a otros países. El Módulo de Control de Alumnos Ayudantes del SIGENU, Versión 2.0, al implementarse en la práctica mostró las siguientes carencias: •. No existe una interfaz por la cual introducir un Jefe de Departamento al Sistema.. •. No existen funciones de configuración para el Módulo.. •. El diseño con escasa estética del cliente Web..

(13) INTRODUCCIÓN. 3. A partir de la situación anterior se plantea como problema científico: el Módulo de Control de toda la actividad relacionada con los Alumnos Ayudantes presenta carencias al no ser capaz de responder a las nuevas necesidades surgidas después de la implementación de la versión 1.0 y 2.0, que sea compatible con las definiciones y módulos ya establecidos por el SIGENU y que en particular esté elaborado sobre software libre. A partir de lo cual se plantea como objetivo general: refactorizar el Módulo de Control de Alumnos Ayudantes. Versión 2.0, implementando las funciones carentes y dejando constancia escrita de la revisión técnica realizada. Como objetivos específicos se establecen: 1. Cambiar la configuración para el Módulo de Control de Alumnos Ayudantes del SIGENU. 2. Desarrollar una interfaz que permita la gestión de los usuarios del sistema. 3. Actualizar el manual de usuario del Módulo de Control de Alumnos Ayudantes. 4. Cambiar el diseño de interfaz de la aplicación Web. 5. Realizar una revisión técnica del sistema para diagnosticar los problemas existentes referentes a la interacción entre módulos y posible extensión de las funcionalidades del Módulo de Control de Alumnos Ayudantes. 6. Documentar las deficiencias encontradas a partir de la revisión técnica (punto anterior). Se plantea como hipótesis de investigación: 1. La refactorización del Módulo de Control de Alumnos Ayudantes mejorará las actividades relacionadas con todos los actores que intervienen en el proceso. 2. El desarrollo de una interfaz que permita la gestión de los usuarios del sistema facilitará el trabajo de los actores del sistema..

(14) INTRODUCCIÓN. 4. 3. El cambio de la configuración del Módulo de Control de Alumnos Ayudantes del Sistema SIGENU facilitará la portabilidad. 4. El cambio del diseño de interfaz de la aplicación Web proporcionará al usuario una interfaz más amigable. Forma en que se comprobarán las hipótesis del trabajo. Una vez terminada la refactorización del Módulo de Control de Alumnos Ayudantes del SIGENU, se comprobará su funcionamiento y rendimiento instalándolo en el Departamento de Producción de Software (DPS) de la Universidad Central “Marta Abreu” de las Villas. El Módulo de Control de Alumnos Ayudantes traerá como beneficio esencial la eliminación del trabajo manual de las Secretarias de los Centros de Educación Superior (CES) y de los Centros Universitarios Municipales (CUM), además brindará un papel protagónico a los Jefes de Departamento, quienes realmente son los que tienen el control del trabajo de los Alumnos Ayudantes. Se tendrá en cuenta también la elaboración de una respuesta rápida ante cualquier solicitud por parte del MES y una mayor cantidad de funcionalidades que actualmente no existen. De esta manera se debe incrementar la eficiencia y calidad en el proceso de gestión de Alumnos Ayudantes. La Tesis se estructura en tres capítulos: el primero se dedica a las consideraciones acerca del Módulo de Alumnos Ayudantes del SIGENU. El Capítulo 2 presenta los aspectos metodológicos referentes al diseño e implementación del sistema. En el Capítulo 3 se expone el estado final de la aplicación..

(15) CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES. 5. DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.. CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO. DE. ALUMNOS AYUDANTES DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD. El presente capítulo se dedica a exponer algunas consideraciones teóricas acerca del SIGENU y del Módulo de Control de Alumnos Ayudantes. Además, la estrategia seguida para el desarrollo del Sistema. 1.1 Sistema de Gestión de la Nueva Universidad (SIGENU). Por la necesidad de elevar la eficiencia y calidad de todos los procesos docentes de las universidades, la dirección de Informatización del Ministerio de Educación Superior (MES), organizó el Taller “Automatización de la Gestión Universitaria” donde participaron numerosos especialistas de diferentes universidades, con el objetivo concreto de aunar esfuerzos para lograr el desarrollo de un sistema automatizado capaz de controlar a nivel nacional la gestión académica de los estudiantes que ingresan a los distintos cursos de nivel superior. Así surge el proyecto Sistema de Gestión de la Nueva Universidad (SIGENU). (ESCOBAR, 2008). En correspondencia con su carácter nacional y la gran diversidad de sistemas de educación superior con que cuenta la universidad cubana, este sistema ha sido concebido de manera tal que sea capaz de brindar gran seguridad e integridad de la información, y a la vez, ser tan flexible que permita ser adaptado a todos los centros de educación superior del país con sus diversas particularidades y distintas maneras de realizar determinados procedimientos. La UCLV participó también en el diseño de la Base de Datos del nuevo sistema SIGENU y ha sido vinculada en el desarrollo de aplicaciones para el mismo, por lo que se planteó la tarea de implementar un sistema que automatizara todos estos procesos, separados en diferentes módulos, entre los que se encuentra el de Control de Alumnos Ayudantes. Con anterioridad ya este ha sido un punto de.

(16) CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES. 6. DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.. investigación en el que se han obtenido resultados sólidos, lográndose la versión 1.0 y 2.0 del Módulo de Control de Alumnos Ayudantes.. 1.1.1. Módulo de Control de Alumnos Ayudantes. Este Módulo es el encargado de manejar todas las operaciones relacionadas con los Alumnos Ayudantes. Consta de dos ambientes Web y Desktop, donde los actores que intervienen son, Alumnos Ayudantes y Jefes de Departamento para el Web y la Secretaria para el Desktop. La filosofía de trabajo es que cualquier usuario sin que tenga que pertenecer al Movimiento de Alumnos Ayudantes pueda visualizar la información, el historial o el horario docente de un Alumno Ayudante. El Jefe de Departamento puede gestionar las operaciones relacionadas con la Adición, Modificación, Ratificación y Eliminación de los estudiantes así como Introducir y Modificar el horario docente de los Alumnos Ayudantes, siendo la Secretaria la encargada de procesar las propuestas realizadas por el Jefe de Departamento. De esta forma se garantiza que sea sólo la Secretaria la que escriba en la entidad. Adicionalmente puede Generar Reportes y aumentar el Nivel de los Alumnos Ayudantes 1.2 Estrategias para el desarrollo. Una estrategia de desarrollo define el camino a seguir para llevar a cabo una investigación y la forma de enfrentar el problema en la práctica. Una vía que promete acelerar el desarrollo de aplicaciones, simplificar la integración entre distintas tecnologías y reducir el costo de la migración de las aplicaciones a nuevas plataformas, lo es sin dudas, Model Driven Architecture (MDA). La utilización de esta estrategia condiciona el uso de varias herramientas como: AndroMDA, Maven, MagicDraw, JBoss..

(17) CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES. 7. DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.. 1.2.1. Patrones de diseño.. Un patrón J2EE™ es un estándar que representa una solución experta que proponen un conjunto de desarrolladores de la plataforma, cuyo objetivo principal es proponer estrategias para diseñar un sistema más escalable, mantenible, interoperable y reusable. Seguidamente se enumeran los principales patrones que se utilizaron en el desarrollo del sistema. - MVC (Model View Controller). - Patrón singleton. - Fachada de sesión. - Value Objects. 1.2.2. J2EE™. La plataforma Java 2 Enterprise Edition define un estándar. para el diseño,. desarrollo, ensamblaje y despliegue de aplicaciones empresariales. Al ser un estándar, no un producto, es necesario trabajar con algún servidor que implemente completamente la especificación J2EE™ como Sun ONE o JBoss™. (Armstrong et al., 2005) La selección de esta plataforma está respaldada además de por las bondades del lenguaje Java, por permitir al desarrollador crear una aplicación portable entre plataformas, escalable y a la vez que integrable con tecnologías anteriores. El servidor de aplicaciones puede manejar transacciones, la seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados. Todo esto significa que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel..

(18) CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES. 8. DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.. Componentes en J2EE™ Un componente J2EE™ es una unidad de software auto-contenida y funcional que se ensambla en la aplicación, logrando la comunicación necesaria con otros componentes del sistema. La especificación J2EE™ define los siguientes componentes: 1. Aplicaciones clientes y applets que se ejecutan en el cliente. 2. Los Java Servlets y Java Server Pages™ (JSP) son componentes Web que se ejecutan en el servidor. 3. Los Enterprise JavaBeans™ (EJB™) son componentes del negocio que se ejecutan en el servidor. (Armstrong et al., 2005) Enterprise JavaBeans™ Un Enterprise JavaBean es un componente que encapsula la lógica del negocio de la aplicación. Los enterprise beans se despliegan en el servidor de aplicaciones, donde el contenedor de EJB™ se encarga de manejarlos.(Gilbert, 2002) Existen varios tipos de componentes EJB™: •. Session Beans. •. Entity Beans. •. Message-Driven Beans. Session Beans Los Session Beans son los componentes que se encargan de tareas o funciones para un cliente específico. Los session beans implementan la lógica del negocio. Dentro del servidor de aplicaciones, un session bean representa un cliente, por su misma naturaleza no es persistente, es decir, cuando el cliente cierra la sesión, el bean se destruye. (ARMSTRONG, 2005).

(19) CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES. 9. DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.. Entity Beans Un Entity Bean representa un objeto dentro del mecanismo de persistencia. Brinda una representación orientada a objetos de la base de datos. A diferencia de los session beans, los entity beans una vez que son creados, persisten hasta que se destruyen por invocaciones del cliente.(ARMSTRONG, 2005) Hay dos tipos de persistencia en los entity beans: •. Persistencia manejada por el bean (BMP).. •. Persistencia manejada por el contenedor (CMP).. Java Server Pages™ (JSP) JSP es la tecnología usada para generar páginas Web de forma dinámica en el servidor desarrollado por Sun Microsystems®, está basado en scripts que utilizan una variante del lenguaje Java. (ARMSTRONG, 2005) Permite a los programadores mezclar HTML estático con HTML dinámico. Esta tecnología permite al código Java y a algunas acciones predefinidas ser mezcladas con el contenido estático de la Web. En las JSP, se escribe el texto que va a ser devuelto en la salida (normalmente código HTML), incluyendo código Java dentro de él para poder modificar o generar contenido dinámicamente. 1.2.3. Contenedores en J2EE™. Un contenedor es una interfaz entre un componente y la funcionalidad de bajo nivel de la plataforma que soporta ese componente. El servidor de J2EE™ provee varios tipos de contenedores: • Contenedor de EJB™. • Contenedor WEB. • Contenedor de aplicaciones cliente. • Contenedor de Applets..

(20) CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES. 1. DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.. Antes de que un enterprise bean o un componente Web pueda ser ejecutado es necesario que se ensamble en un módulo J2EE™ y se despliegue en el servidor. El proceso de ensamblaje implica especificar las configuraciones del servidor para cada componente de la aplicación J2EE™ como pueden ser la seguridad, el manejo de transacciones, los nombres jndi (Java name and directory interface)(Lee, 2002) que serán usados por el servidor para la localización de los distintos componentes, entre otros.. Fig 1. Servidor y Contenedor J2EE™. El servidor utilizado es JBoss™. Es un servidor de aplicaciones J2EE™ de código abierto implementado en Java puro, lo cual permite que sea utilizado en cualquier sistema operativo que lo soporte. Implementa completamente la especificación J2EE™. 1.2.4. Aplicaciones clientes.. Las aplicaciones clientes se ejecutan en la máquina cliente y proporcionan el camino a los usuarios para manipular las tareas. Típicamente están compuestas por una interfaz gráfica de usuario (GUI por sus siglas en inglés). Acceden directamente a los Enterprise Java Bean™ (EJB™) que se encuentran desplegados en la capa de negocio del servidor, o puede suceder que la aplicación cliente inicie una conexión http para comunicarse con un servlet que se encuentra ejecutándose en la capa de presentación del lado del servidor..

(21) CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES. 1. DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.. Arquitectura de plug-ins1 necesaria para el ambiente Desktop. La arquitectura de plug-ins permite extender las funcionalidades de la aplicación sin necesidad de tener acceso al código fuente de la misma, tampoco es necesario recompilarla para redistribuirla a los usuarios, basta con distribuir el nuevo plug-in. Resulta ser muy atractiva para los desarrolladores porque permite centrarse en proveer una funcionalidad modular al usuario final. Este enfoque es muy beneficioso a la hora de manejar el problema de que las reglas de negocio puedan cambiar frecuentemente o bien pudieran surgir reglas nuevas. De esta forma se puede personalizar fácilmente una aplicación mezclando y acoplando plug-ins según se necesite o creando uno nuevo para alguna opción inexistente. (Birsan 2005) 1.2.5. Hibernate.. Es una tecnología de mapeo objeto-relacional. Facilita el mapeo de atributos entre una Base de Datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) que permiten establecer estas relaciones. (Griffin, 2009) 1.2.6. Sistema gestor de base de datos.. Actualmente son muchas las aplicaciones que requieren acceder a datos y se necesita de un medio para lograrlo. Cuando el volumen de la información es muy grande este medio de acceso debe ser altamente eficaz. Es aquí donde aparecen los Sistemas Gestores de Bases de Datos los cuales proporcionan una interfaz entre las aplicaciones y el sistema operativo, permitiendo que el acceso a los datos se realice de una forma más eficiente, más fácil de interpretar y sobre todo más segura.. 1. Conjunto de funcionalidades que puede ser incorporado a una aplicación sin necesidad de. recompilar la misma. La aplicación debe proveer interfaces para el acople del plug-in..

(22) CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES. 1. DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.. El sistema gestor de base de datos utilizado es PostgreSQL, este es relacional y de código abierto. (GROUP, 2004) .Además es libre, cumpliendo las nuevas estrategias del país acerca del software libre. Por el hecho de ser de los mejores gestores de bases de datos además de las ventajas antes expuestas, fue elegido para el desarrollo del SIGENU y en particular para esta aplicación. 1.2.7. MDA (Model Driven Architecture).. El SIGENU, fue diseñado usando la metodología MDA (Model Driven Architecture) que se centra en definir la funcionalidad del sistema en primer lugar por sus especificaciones expresadas en modelos independientes de la plataforma. Uno de los principales objetivos de MDA es separar el diseño de la arquitectura y de las tecnologías de construcción, facilitando que el diseño y la arquitectura puedan ser alterados independientemente. El diseño alberga los requerimientos funcionales (los casos de uso) mientras que la arquitectura proporciona la infraestructura a través de la cual se hacen efectivos requerimientos no funcionales como la escalabilidad, fiabilidad o rendimiento. De esta manera se propicia la reutilización del conocimiento experto en el campo de la gestión universitaria más allá de cualquier infraestructura tecnológica. La herramienta AndroMDA. Buscando acelerar el desarrollo de los sistemas J2EE mediante la metodología MDA, se hizo uso del proyecto AndroMDA. Es un framework de generación de código que sigue el paradigma MDA, utiliza UML para la representación de la lógica del negocio e incluye facilidades para el desarrollo de aplicaciones. Toma generalmente modelos de una herramienta case y genera aplicaciones desplegables y otros componentes. AndroMDA es de código abierto, permitiendo al usuario hacer modificaciones. (Bohlen et al., 2005) Maven. Es una herramienta de software para la gestión y construcción de proyectos Java. Es similar en funcionalidad a Apache Ant pero tiene un modelo de configuración.

(23) CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES. 1. DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.. de construcción más simple, basado en un formato XML. Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Viene con objetivos predefinidos para realizar ciertas tareas claramente definidas, como la compilación del código y su empaquetado. MagicDraw. MagicDraw es una. herramienta CASE para el modelado visual en UML, que. soporta el trabajo en equipo. Esta herramienta de desarrollo dinámica y versátil, facilita el análisis y el diseño de los sistemas y bases de datos orientados a objetos (OO). Provee el mejor mecanismo de ingeniería de código de la industria, así como la modelación del esquema de las bases de datos, la generación de DDL y las facilidades de ingeniería inversa.(Support, 2005) En general, en el Capítulo se abordaron elementos y conceptos de gran importancia en la gestión de la información relacionada con los Alumnos Ayudantes. Se describen las herramientas utilizadas para la implementación del Sistema..

(24) CAPÍTULO 2:. 14. CAPÍTULO 2: ASPECTOS METODOLÓGICOS REFERENTES AL DISEÑO E IMPLEMENTACIÓN DEL SISTEMA. 2.1 Descripción del sistema. La versión 2.0 del Módulo de Control de Alumnos Ayudantes, consta de dos ambientes (Web y Desktop), se hizo la modelación de estos de forma independiente, para facilitar sus posteriores modificaciones. Así entonces, si en el futuro las nuevas resoluciones introducen otros conceptos no contemplados en el Sistema, se facilita en gran medida el trabajo para controlar estos nuevos acápites. 2.2 Modelación del Sistema. Para realizar los cambios en el sistema, fue necesario cambiar la modelación del mismo, es decir, añadir un nuevo caso de uso al actor Secretaria, en consecuencia con esto un nuevo diagrama de actividad e incorporar la funcionalidad de este caso de uso en el diagrama de estado.. 2.2.1. Descripción de los Casos de Uso.. Diagrama de casos de uso para la Secretaria.. Figura 2. Caso de uso para la Secretaria (Adicionar Jefe de Departamento)..

(25) CAPÍTULO 2:. Nombre del caso de uso. Adicionar Jefe de Departamento. Actor. Secretaria. Precondiciones. La Secretaria entra al sistema y selecciona Registrar Jefe de Departamento.. Propósito. Añadir un Jefe de Departamento al Sistema.. Resumen: La Secretaria entra al sistema con el propósito de añadir un Jefe de Departamento al sistema. Para ello solo tiene que escoger la opción de Registrar Jefe de Departamento, llenar los datos y seleccionar aceptar. Poscondiciones. Es añadido un nuevo Jefe de Departamento al sistema.. Fig 3. Diagrama de actividad: Adicionar Jefe de Departamento.. 15.

(26) CAPÍTULO 2:. 16. Con la adición de este caso de uso al sistema fue necesario cambiar el diagrama de estado del ambiente Desktop, porque antes existía una sola opción en el menú de Alumnos Ayudantes (Ver figura 3 en Anexo 1), y ahora se le añade una nueva para adicionar un Jefe de Departamento. El nuevo diagrama de estado para la aplicación Desktop se muestra en la figura siguiente.. Fig 4. Diagrama de estado para Adicionar Jefe de Departamento. 2.3 Implementación del sistema. Para la implementación de los cambios al sistema se hizo necesario añadir una nueva operación, para ello se hicieron cambios en una clase de servicios. Además se hicieron cambios en archivos involucrados en la configuración del Módulo.. 2.3.1. Gestión de los usuarios del sistema.. En la versión anterior del módulo se había concebido que desde la ambiente Web se realizara la adición del Jefe de Departamento. Esto no tenía sentido alguno, ya que tendría que existir un actor con más privilegios que el Jefe de Departamento para gestionar la adición de estos al sistema. Por lo tanto, como la Secretaria es la responsable de gestionar la mayor parte de las operaciones que se realizan sobre las entidades de la Base de Datos, se decidió que fuera esta la encargada de adicionar al Jefe de Departamento..

(27) CAPÍTULO 2:. 17. El caso de uso de la Secretaria relacionado con adicionar Jefe de Departamento se modeló aparte de los que ya existían en la versión anterior (Ver figuras 8 y 9 en Anexo 1), porque estos están relacionados con operaciones a realizar con los Alumnos Ayudantes y este nuevo se relaciona con los Jefes de Departamento. También en el menú del ambiente Desktop relacionado con los Alumnos Ayudantes, se creó una nueva opción, puesto que esta es totalmente independiente de la que existe de la versión anterior. La opción de adicionar un Jefe de Departamento es importante, ya que con anterioridad había que introducir directamente, “a mano”, en la Base de Datos el Departamento y el Jefe de Departamento asociado a él. Detalles de la implementación. Para agregar un Jefe de Departamento al sistema hay que tener en cuenta la relación que existe en el esquema Entidad/Relación de la Base de Datos entre la tabla Jefe de Departamento y la de Departamento.. Fig 5. Relación entre las entidades Departament y Boss Department. Esta relación, como se aprecia, es de asociación donde Department es la entidad fuerte y Boss Department la débil, por tanto un Jefe de Departamento no puede ser eliminado a no ser que se elimine el Departamento y para agregar un nuevo Jefe de Departamento al sistema hay que hacerlo desde la inserción de un Departamento..

(28) CAPÍTULO 2:. 18. Para estos primeramente fue necesario, utilizando la herramienta MagicDraw, añadir a la clase Operation Service una nueva operación, insertDepartment, tal como se muestra en la figura 6.. Figura 6. Clase Operation Service. Esta clase es la encargada de manejar todas las operaciones que se realicen en la aplicación. Luego que se guardaron los cambios en el fichero .xmi (extensión del fichero que exporta MagicDraw y que utiliza AndroMDA para trabajar), se recompiló el código fuente de la aplicación utilizando la herramienta Maven (que contiene un plugin para AndroMDA). Con esto se logró que se añadiera al Sistema esta nueva operación, aunque luego el programador es el encargado de implementar la funcionalidad del método en la clase OperationServieceImpl, creada por AndroMDA. Ahora se pasará a explicar el funcionamiento del método programado. •. Primero se crea una instancia de Departamento en memoria. Department dept = Department.Factory.newInstance ();. •. Seguidamente se asigna el nombre del departamento. dept.setName (depart.getDepartment ());. •. A continuación se crea una instancia de Jefe de Departamento en memoria (para introducir la entidad débil) BossDepartment bossdept = BossDepartment.Factory.newInstance ();.

(29) CAPÍTULO 2:. •. 19. Se hace una llamada al método que inicializa al Jefe de Departamento con los datos que tiene el value object de departamento dado. getBossDepartmentDao ().bossDepartmentVOToEntity ( depart.getBossDepartmentVO (), bossdept, true);. •. Seguidamente se crea el Jefe de Departamento en la Base de Datos. getBossDepartmentDao.create (bossdept);. •. Ahora se le asigna al Departamento su Jefe de Departamento. dept.setBossDepartment (bossdept);. •. Finalmente se crea el departamento en la Base de Datos. getDepartmentDao ().create (dept);. 2.3.2. Funciones de configuración.. En cualquier servidor que implemente completamente la especificación J2EE, para que una aplicación pueda desplegarse, se necesita de archivos de configuración, donde se le especifique la ubicación (IP) del servidor de Base de Datos, el nombre de la Base de Datos, el nombre de usuario, la contraseña con la que se va a conectar, entre otras opciones de configuración. En este sentido existían dos archivos de configuración, uno para el proyecto Minotaur2 y otro para HelpStudents3, lo que se quería concebir era que todos tomaran un solo archivo de configuración, para que cualquier cambio que hubiera que hacer, fuera más sencillo de implementar. Vale aclarar que los dos archivos contienen lo mismo, lo que uno tiene como nombre de JNDI MinotaurDS y el otro HelpStudentsDS. También se puede añadir que con la versión 2.5.1 del SIGENU, el archivo de configuración queda fácilmente accesible para cualquier cambio, luego, tiene lógica migrar nuestra configuración para MinotaurDS. 2. Es el code name del proyecto SIGENU.. 3. Es el code name del proyecto de Alumnos Ayudantes..

(30) CAPÍTULO 2:. 20. El código que se adiciona al fichero login-config.xml que se encuentra dentro del JBoss siguiendo el camino ${JBOSS_HOME}\server\default\conf\, es el siguiente:  <application-policy name = "helpstudentsystem"> <authentication> <login-module code ="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag = "required"> <module-option name = "unauthenticatedIdentity"> Guest </module-option> <module-option name = "dsJndiName"> java:/MinotaurDS </module-option> <module-option name = "principalsQuery"> SELECT PASSWORD FROM BOSS_DEPARTMENT WHERE IDUSER=? </module-option> <module-option name = "rolesQuery"> SELECT IDROLE,'Roles' FROM BOSS_DEPARTMENT WHERE IDUSER=? </module-option> </login-module> </authentication> </application-policy>. Por otro lado, estas aplicaciones trabajan con ejbs y estos también necesitan de archivos de configuración, tienen más, pero al final lo que hacen es, o definir de manera local los datos de la configuración o utilizar un fichero que apunte a un datasource que contenga los datos de la conexión. La aplicación Web utilizaba la primera variante, lo que ocasionaba que cada vez que cambiaran los datos hubiera que cambiar “a mano” el fichero correspondiente. Lo más trabajoso que tiene esto no es hacer los cambios en el archivo, sino que estos archivos se encuentran en: helpstudents-app-2.0- SNAPSHOT.ear\helpstudents-core-2.0-SNAPSHOT.jar.

(31) CAPÍTULO 2:. 21. Fig 7. Archivos de configuración para los ejb. Lo cual implica que no cualquier usuario es capaz de hacer esto. Lo que se hizo fue pasar a la segunda variante, para esto se introdujo un nuevo archivo, applicationContext-datasource.xml, que contiene lo siguiente:. Fig 8. Contenido del archivo applicationContext-datasource.xml. Se cambio el archivo beanRefFactory.xml, que es al que llaman todos los ejbs de la aplicación, y él se encarga de llamar a los demás archivos..

(32) CAPÍTULO 2:. 22. Fig 9. Contenido del archivo beanRefFactory.xml. Con estos cambios se logra: que no se necesite más que el archivo de configuración del proyecto Minotaur, y que la aplicación en general, tanto Web como Desktop sean fáciles de configurar. En este capítulo se documenta la refactorización del sistema, se muestran los diagramas asociados a la nueva funcionalidad incorporada, así como la vía de solución empleada..

(33) CAPÍTULO 3:. 23. CAPÍTULO 3: ESTADO FINAL DE LA APLICACIÓN. 3.1 Manual de instalación. Los pasos para la instalación del ambiente Desktop son: 1.Copiar. el. archivo. helpstudentsclient-app-1.0-SNAPSHOT.ear. en. ${JBOSS_HOME}\server\default\deploy\sigenu. 2.Copiar en la biblioteca del Skeleton (Skeleton\lib) los ficheros: helpstudentsclient-common-1.0-SNAPSHOT.jar helpstudentsclient-core-1.0-SNAPSHOT.jar 3. Copiar. dentro. de. Skeleton\plugins,. la. carpeta. con. nombre. cu.mes.helpstudents. 4. Añadir al archivo pluginList.xml, que se encuentra en Skeleton\plugins lo siguiente: <plugin> <dir>cu.mes.helpstudents</dir> </plugin>. Nota:. Los. archivos. necesarios. para. la. instalación. se. encuentran. en. helpstudents\desktop. Para el ambiente Web: 1. Copiar. en. ${JBOSS_HOME}\server\default\deploy\sigenu. el. archivo. helpstudents-app-2.0-SNAPSHOT.ear. 2. Copiar. en. el. fichero. ${JBOSS_HOME}\server\default\deploy\conf\login-. config.xml las líneas especificadas en archivo _login-config.txt. Nota:. Los. archivos. necesarios. para. la. instalación. se. encuentran. en. helpstudents\web. 3.2 Manual de Usuario. El Módulo de Control de Alumnos Ayudantes es el único que implementa un ambiente Web, cuenta además con un módulo Desktop que abarca un conjunto de.

(34) CAPÍTULO 3:. 24. funcionalidades relacionadas con los Alumnos Ayudantes. Entre las principales funcionalidades que se brindan, se encuentran una serie de reportes que se muestran a la Secretaria, para una mejor información y actualización de los datos. 3.2.1. Nuevas opciones del módulo Desktop del sistema.. Con el ambiente Desktop del Sistema solo interactúa el actor Secretaria, por tanto, todos los detalles que se dan a continuación referentes a las opciones que brinda este módulo son importantes para este único actor. Secretaria. La Secretaria tendrá una nueva opción, por lo cual a las funciones principales que realizaba: i. Realizar una operación sobre los estudiantes. ii. Obtener reportes de los Alumnos Ayudantes. Se le adiciona la de: iii. Registrar un Jefe de Departamento. Registrar Jefe de Departamento. Para Registrar un Jefe de Departamento ir a la opción correspondiente en la barra de herramientas, el menú Alumnos Ayudantes >> Registrar Jefe de Departamento.. Figura 10. Opción registrar Jefe de Departamento. Menú Alumnos Ayudantes..

(35) CAPÍTULO 3:. 25. A continuación aparecerá la ventana siguiente (ver figura 11), en la cual se realizará el proceso de Registrar un Jefe de Departamento.. Figura 11. Ventana para Registrar un Jefe de Departamento. En la misma todos los campos son obligatorios. En caso de que quede algún campo sin llenar aparecerá un cartel indicando que se deben llenar los campos vacíos.. Figura 12. Mensaje de advertencia: campos vacíos..

(36) CAPÍTULO 3:. 26. En el campo identificación, debe introducirse el número del carnet de identidad. En caso de que se introduzca un número menor o mayor que 11 caracteres aparecerá una advertencia de que el campo debe contener 11 caracteres.. Figura 13. Mensaje de advertencia: identificación. Los campos de contraseña y confirmar deben coincidir, si esto no sucede aparecerá un mensaje informando que las contraseñas deben ser iguales.. Figura 14. Mensaje de advertencia: contraseña y confirmar. Una vez terminada de introducir la información se oprime el botón Registrar para finalizar el proceso de Registrar un Jefe de Departamento. 3.3 Estado final. 3.3.1. Generación de reportes.. En el momento de comenzar la implementación de la generación de reportes surgieron los siguientes problemas..

(37) CAPÍTULO 3:. •. 27. Debido a que AndroMDA es la que genera las páginas Web, es difícil un cambio en el diseño de estas. Esto propicia que las páginas no tengan los métodos necesarios para incluir la generación de reportes.. •. La escasa organización en cuanto a las clases de servicios imposibilita la correcta adición de una nueva clase de servicios para los reportes, con todas las demás clases que esta trae consigo.. •. No se logra la conexión con Jasper Reports e iReports desde el código, pues por el esquema de clases y archivos .jsp que crea AndroMDA no es posible realizar los reportes en la misma página jsp, puesto que las páginas creadas por AndroMDA son estáticas.. Por lo que se propone: •. Cambiar la herramienta con la que se crean las páginas Web, para hacer más fácil el diseño de la página y además, para facilitar la generación de reportes desde ella.. •. Si se sigue trabajando con AndroMDA, ordenar las clases de servicios de manera tal que sea sencillo añadir tanto una nueva operación, como una clase de servicios.. •. La idea es hacerlo similar al proyecto Desktop, con una clase para controlar las operaciones y otra para controlar los reportes.. 3.4 Estado de la conexión con el SIGENU. Versión 2.5.1. 3.4.1. Seguridad en el ambiente Desktop.. El esquema de seguridad para este ambiente en la versión 2.5.1 cambió. Por tanto ahora no es posible incluir el plugin de Alumnos Ayudantes y que este funcione de la manera que lo hacía antes, pues anteriormente cuando la Secretaria se autentificaba se chequeaba de qué facultad era, y de acuerdo con esto se cargaban los datos de los estudiantes de su facultad. En el caso del Módulo de Control de Alumnos Ayudantes, la Secretaria accedía a la entidad temporal (Ver figura 18 en Anexo 1) y realizaba las operaciones con los estudiantes que allí se.

(38) CAPÍTULO 3:. 28. encontraran. En la nueva versión cambiaron el esquema de seguridad. Ahora la Secretaria se autentifica y también se le autorizan las operaciones que puede realizar. Es decir, que para la inserción del plugin de Alumnos Ayudantes es necesario migrar para esta nueva seguridad y además que se incluyan los métodos del Módulo en el esquema de autorización que tiene la nueva versión. 3.4.2. Capa intermedia (Aminotaur).. Debido a la necesidad de independizar esta aplicación (Alumnos Ayudantes) de las ya implementadas, y con el propósito de proporcionar una mayor facilidad a la hora de sus posteriores mantenimientos e implantaciones, se creó un nuevo proyecto (aminotaur → interpretar como acceso a Minotaur) que funcionara como capa intermedia, y fuera capaz de comunicar la capa de negocio de Alumnos Ayudantes con el módulo de Minotaur. El problema que se presenta con esto, es que con la nueva versión se le cambió el nombre a toda la paquetería del proyecto Minotaur y además, se cambió la distribución de clases por paquetes, por lo que ahora las funcionalidades que dependen de esta capa intermedia (que son la mayoría), no funcionan. La solución que se plantea por los desarrolladores del SIGENU es la implantación de un Web Service, que hasta el momento se encuentra en fase de prueba en la CUJAE, y que hasta el momento tampoco cubre todas las necesidades del Módulo. En este capítulo se mostró el manual de usuario para las mejoras hechas al Sistema. Se abordó la revisión técnica realizada al Módulo y los resultados que arrojó esta..

(39) CONCLUSIONES Y RECOMENDACIONES. 29. CONCLUSIONES • Las transformaciones realizadas al Módulo permiten su portabilidad en el sentido de que el usuario que lo instale no tenga que preocuparse por su configuración. • La creación y desarrollo de una interfaz para la adición por parte de la Secretaria de un Jefe de Departamento al Sistema, le confiere mayor viabilidad y seguridad. • Se implementó un nuevo diseño de interfaz para la aplicación Web que propicia un ambiente más asequible al usuario. • Se realizó una revisión técnica, la cual reveló los principales problemas existentes para el mantenimiento del Módulo de Control de Alumnos Ayudantes..

(40) CONCLUSIONES Y RECOMENDACIONES. 30. RECOMENDACIONES 1.Realizar los cambios pertinentes en la aplicación Web para la generación de reportes por parte del Jefe de Departamento. 2. Continuar el trabajo con los desarrolladores del Módulo de seguridad del SIGENU. Versión 2.5.1. para lograr la inserción del plugin de Alumnos Ayudantes al ambiente Desktop. 3. Trabajar en conjunto con los especialistas que desarrollan el SIGENU en la CUJAE para estandarizar las interfaces de los Web Services que permiten la interoperabilidad entre los Módulos. 4. Implementar la interfaz de comunicación con los Web Services existentes implementados. por. los. desarrolladores. del. SIGENU. para. la. interoperabilidad con los demás Módulos del SIGENU. 5. Proponer el cambio de las herramientas actuales para homogeneizar el desarrollo con los especialistas de la CUJAE..

(41) REFERENCIAS BIBLIOGRÁFICAS. 31. REFERENCIAS BIBLIOGRÁFICAS ARMSTRONG, E., BALL, J. & BODOFF, S. (2005) The J2EE™ 1.4 Tutorial, California, U.S.A., Sun Microsystems, Inc. BOHLEN, M., BRANDON, C. & ZOONS, W. (2005). AndroMDA Model Driven Architecture Framework. ESCOBAR, E. Y. D. R. (2008) Módulo de Control de Alumnos Ayudantes del SIGENU.. Versión. 2.0.. Facultad. Matemática-Física-Computación.. Universidad Central “Marta Abreu” de las Villas GROUP, T. P. G. D. (2004) PostgreSQL 8.0.0beta5 Documentation. ARMSTRONG, E., BALL, J. & BODOFF, S. (2005) The J2EE™ 1.4 Tutorial. California, U.S.A, Sun Microsystems ®, Inc. CORZO, E. L. (2009) La Nueva Universidad en Informática 2009 293 ed. GILBERT, A. (2002) Enterprise Java Beans (EJBs). Sun Microsystems, Inc. GRIFFIN, E. B. J. (2009) Hibernate Search in Action. Greenwich Manning Publications Co. LEE, R. (2002) The JNDI Tutorial. SUPPORT, M. D. A. (2005) MagicDraw User's Manual version 10.5. No Magic, Inc..

(42) BIBLIOGRAFÍA. 32. BIBLIOGRAFÍA BERGSTEN, H. (2002). JavaServer Pages™. 2nd. ed. Sebastopol. O'Reilly & Associates. CHOPRA, V et al. (2004). Professional Apache Tomcat 5. Wiley Publishing, Inc. CRAWFORD, J. H. W. (1998). Java(TM) Servlet Programming. Sebastopol. O'Reilly & Associates, Inc. DANCIU, T. (2005). JasperReports. DOUGLAS, K. D. S. (2005). PostgreSQL: The comprehensive guide to building, programming, and administering PostgreSQL databases. Second ed., Sams Publishing. ECKEL, B. (2003). Thinking in Java. 3rd ed., Pearson Education, Inc. ENGLANDER, R. (1997). Developing Java Beans. O'Reilly & Associates, Inc. EWALD GESCHWINDE, H.-J. S. (2001). PostgreSQL Developer's Handbook. Sams Publishing. GARCÍA, L. (1995). Sistema automatizado de Control de Estudiantes en Red. GOODWILL, J. (2002). Apache Jakarta Tomcat. GROUP, J. (2006). The JBoss 4 Application Server Guide. JBoss, Inc. GROUP, S. S. (2001). J2EE in Practice. Sun Microsystems, Inc. GROUP, T. P. G. D. (1996-2008). PostgreSQL 8.3.4 Documentation. GROUP, T. P. G. D. (2004). PostgreSQL 8.0.0beta5 Documentation. HALIM, S. (N.D.). JSP Page Design With Tiles. HEFFELFINGER, D. R. (2006). JasperReports for Java Developers. Packt Publishing Ltd. HENNEBRUEDER, S. (2006). First EJB 3 Ant Tutorial. HERRERA, C. K. (2005). Introducción a iReport. Madrid, España. HIGHTOWER, R. (2004) Jakarta Struts Live. Colorado, SourceBeat, LLC. MARINESCU, F. (2002). EJB(TM) Desing Patterns. John Wiley & Sons, Inc. MONTENEGRO, E. M. (2003). Aplicación profesional con Struts. ROMAN, E. et al. (2005). Mastering Enterprise JavaBeans™. Third ed., Wiley Publishing,Inc..

(43) BIBLIOGRAFÍA. 33. SCHÖNIG, E. G. H.-J. (2001). PostgreSQL Developer's Handbook. Sams Publishing. SCOTT DAVIS, T. M. (2005). JBoss at Work: A Practical Guide. O'Reilly. SUN MICROSYSTEMS, I. (2001). Java(TM) Look and Feel Design Guidelines: Advanced Topics. 1st Edition. ed. California, Addison Wesley . TOFFOLI, G. (2005). A design tool iReport for JasperReports. DEEPAK ALUR, J. C. D. M. (N.D.). Core J2EE™ Patterns: Best Practices and Design Strategies. (2003). Enterprise JavaBeansTM Specification. California, Sun Microsystems, Inc. (2006). AndroMDA Model Driven Architecture Framework..

(44) ANEXOS. 34. ANEXOS. Anexo I Diagramas del sistema. Diagrama de paquetes del sistema:. Figura 1. Diagrama que muestra de forma general con quién se relaciona cada actor..

(45) ANEXOS. 35. Diagrama de estado para el ambiente Web del sistema.. Figura 2. Diagrama que muestra el funcionamiento del ambiente Web.. Diagrama de estado para el ambiente Desktop del sistema.. Figura 3. Diagrama que muestra el funcionamiento del ambiente Desktop. Debido a que las páginas del ambiente Web del sistema son generadas a partir de los diagramas de actividad asociados a los casos de uso, fue necesario definir un caso de uso “Inicio” que es el punto de entrada de la aplicación, de manera que sea la página de bienvenida del sistema. Esta página tiene un carácter genérico en el módulo, pues puede ser accedida por los usuarios desde cualquier parte y.

(46) ANEXOS. 36. sin necesidad de autenticación, o sea, no se necesitan privilegios especiales para acceder a la información que brinda. A continuación pasamos a definir los casos de uso para cada uno de los actores. •. Actores que intervienen en el ambiente Web. 9 Alumnos Ayudantes. 9 Jefes de Departamento.. •. Actor que interviene en el ambiente Desktop. 9 Secretaria.. Diagrama de casos de uso para los Alumnos Ayudantes.. Figura 4. Casos de uso para los Alumnos Ayudantes. Diagramas de casos de uso para los Jefes de Departamentos. En el caso del Jefe de Departamento, de forma general, existen tres grupos de casos de uso, Visualizar información, Realizar Operación y Generar Reporte..

(47) ANEXOS. Figura 5. Casos de uso para los Jefes de Departamentos (Relacionados con la información de los Alumnos Ayudantes).. Figura 6. Casos de uso para los Jefes de Departamentos (Relacionados con las operaciones que puede efectuar sobre los Alumnos Ayudantes).. 37.

(48) ANEXOS. 38. Figura 7. Casos de uso para los Jefes de Departamentos (Relacionados con la Generación de reportes de los Alumnos Ayudantes). Diagramas de casos de uso para las Secretarias.. Figura 8. Casos de uso para las Secretarias (Relacionados con las operaciones que pueden hacer sobre los Alumnos Ayudantes)..

(49) ANEXOS. Figura 9. Casos de uso para las Secretarias (Relacionados con los reportes que pueden hacer de los Alumnos Ayudantes). Espacios de nombres para el ambiente Web.. Figura 10. Espacio de nombres para el ambiente Web.. 39.

(50) ANEXOS. 40. Detalles de los espacios de nombres para el ambiente Web: cu.mes.helpstudents Raíz del espacio de nombres para la aplicación en el ambiente Web. cu.mes.helpstudents.common En este paquete se encuentra todo lo que es común para las demás operaciones (value object, enumerativos, entre otros.) en el ambiente Web. cu.mes.helpstudents.drivermanage Paquete donde se encuentran todas las clases y diagramas para las operaciones de agregar, eliminar, modificar y ratificar los alumnos ayudantes. (Estas operaciones se efectúan sobre la entidad temporal) cu.mes.helpstudents.evaluation Clases y diagramas relacionados con la gestión de las evaluaciones de los alumnos ayudantes. cu.mes.helpstudents.information Clases y diagramas relacionados con toda la información relacionada con los Alumnos Ayudantes. cu.mes.helpstudents.reports Clases y diagramas relacionados con los reportes que pueden hacer los Jefes de Departamento. cu.mes.helpstudents.schedule Paquete donde se encuentran todas las clases y diagramas para que un Jefe de Departamento introduzca el horario docente a un Alumno Ayudante. cu.mes.helpstudents.schedulehschange Paquete donde se encuentran todas las clases y diagramas para que un Jefe de Departamento modifique el horario docente de un Alumno Ayudante..

(51) ANEXOS. 41. cu.mes.helpstudents.start Paquete que contiene el caso de uso de la página de bienvenida y el diagrama de actividad relacionado con él. cu.mes.helpstudents.startdepartment Paquete que contiene el caso de uso de la página de bienvenida al Jefe de Departamento y el diagrama de actividad relacionado con él. cu.mes.helpstudents.viewhsclasses Paquete donde se encuentran todas las clases y diagramas para que un Alumno Ayudante pueda obtener la información de su horario docente. cu.mes.helpstudents.viewhshistory Paquete donde se encuentran todas. las clases y diagramas para que un. estudiante pueda obtener su historial como Alumno Ayudante. diagrams Raíz del espacio de nombres para los diagramas. diagrams.Use Cases Paquete donde se especifican los actores que intervienes en el ambiente Web del sistema y los casos de uso de cada uno de ellos. diagrams.VO-Entities Paquete donde se encuentran los diagramas de clases que relacionan los value objects con las entibies. entities Paquete donde se encuentran los diagramas de clases con las relaciones entre nuestras entidades..

(52) ANEXOS. 42. Espacios de nombres para el ambiente Desktop.. Figura 11. Espacio de nombres para el ambiente Desktop. Detalles de los espacios de nombres para el ambiente Desktop: cu.mes.helpstudents Raíz del espacio de nombres para la aplicación en el ambiente Desktop. cu.mes.helpstudents.common En este paquete se encuentra todo lo que es común para las demás operaciones en el ambiente Desktop. cu.mes.helpstudents.common.enumeration En este paquete se encuentran todas las clases que tienen estereotipo enumerative. cu.mes.helpstudents.common.services En este paquete se encuentran todas las clases que tienen estereotipo service. cu.mes.helpstudents.common.vo En este paquete se encuentran todas las clases que tienen estereotipo value object. entities Aquí se encuentran todas las clases y diagramas que están relacionados con las entidades de nuestro sistema. (Como es lógico tienen que concordar con las clases y diagramas del ambiente Web).

(53) ANEXOS. 43. relations-diagrams Paquete donde se encuentran todos los diagramas de clases y casos de uso. relations-diagrams.entities-services Paquete donde se especifican todas las relaciones entre las entidades y los servicios. relations-diagrams.use cases Paquete donde se especifica el actor (Secretaria) que interviene en el ambiente Desktop del sistema y sus casos de uso. relations-diagrams.vo-entities Paquete donde se especifican todas las relaciones entre las entidades y los value objects. Datos de los alumnos ayudantes: La principal entidad y el centro de este sistema es HelpStudent en la cual se definen y controlan una serie de datos de los alumnos ayudantes..

(54) ANEXOS. 44. Figura 12. Definición de un Alumno Ayudante. Historial de los alumnos ayudantes: Entidad en la cual se almacena toda la historia del Alumno Ayudante durante su labor. Mantiene una relación directa con la entidad helpstudent de donde se obtienen los datos a la hora de ser guardada la historia.. Figura 13. Definición de la historia de un Alumno Ayudante..

(55) ANEXOS. 45. Datos de los departamentos: Entidad donde se controlan los datos del departamento.. Figura 14. Definición de un departamento. Datos de los jefes de departamento: Entidad donde se controlan los datos de los jefes de departamento.. Figura 15. Definición de un Jefe de Departamento. Horario docente de los Alumnos Ayudantes: Entidad que controla y almacena el horario docente de todos los alumnos ayudantes..

(56) ANEXOS. 46. Figura 16. Definición de un horario docente. Actividad: Especifica el tipo de actividad realizada por el alumno ayudante.. Figura 17. Codificadores de la Actividad. Entidad temporal por la que pasan los Alumnos Ayudantes: Entidad en la que insertan los jefes de departamento a los alumnos ayudantes especificando cuál es la operación que se quiere hacer sobre un ellos. Luego la Secretaria realiza sobre HelpStudent la operación especificada..

(57) ANEXOS. Figura 18. Definición de los datos de un Alumno Ayudante y de la operación a realizar por la Secretaria con este estudiante.. 47.

(58) ANEXOS. 48. Anexo II Manual de Usuario. Alumno Ayudante El Alumno Ayudante solo puede realizar tres operaciones: visualizar información, visualizar historial y visualizar horario docente, las cuales tienen el objetivo de brindar información acerca de la labor que realizan como alumnos ayudantes. Con la característica que pueden ser datos propios, o de otro estudiante que también pertenezca a este movimiento. En toda aplicación siempre se busca un modus operandi genérico, de forma tal que cuando un usuario trabaje con el sistema y realice cualquier operación, intuitivamente este sea capaz de manipular otra acción sin necesidad de haberla realizado con anterioridad. Teniendo en cuenta esta filosofía de trabajo, todos los casos de uso en que se necesitan hacer búsquedas, (todos excepto para generar reportes y gestionar adición) el sistema actúa de igual forma, por tanto solo se explicará esto una vez. A continuación se muestra cómo proceder: Nota: Los campos que se marcan con asterisco son obligatorios.. Figura 1. Búsqueda de estudiantes Para buscar un estudiante sin dificultades, primero que todo este debe ser Alumno Ayudante, de lo contrario nunca se encontrará. Ahora, como muestra la figura anterior, la facultad de estudio y la carrera que cursa el estudiante buscado son obligatorias para efectuar la operación. En caso de no saber sus otros datos, no necesariamente hay que llenarlos. Si no se llenan, el buscador devuelve todos los Alumnos Ayudantes que pertenecen a esa facultad y estudian esa carrera, para que el usuario seleccione de una tabla el que le interesa. En caso de que se llene.

(59) ANEXOS. 49. alguno, se retornan todos los estudiantes que estudian en esa facultad, cursan esa carrera y por ejemplo, se llamen Juan, en caso que ese haya sido el nombre que se introdujo. El resultado de una búsqueda x que cumpla los requisitos de la figura 1 se muestra en la siguiente figura:. Figura 2. Ejemplo de retorno de una búsqueda Visualizar Información Para obtener los datos de algún estudiante que sea Alumno Ayudante, se debe seleccionar la opción Visualizar Información, y después de realizar la búsqueda, sobre la fila en que se encuentra el estudiante deseado, dar clic en el botón que aparece a la parte derecha de la tabla o sobre el link del carnet de identidad. Aparecerá entonces toda la información de ese alumno en su labor de ayudantía durante ese curso (Figura 3.)..

(60) ANEXOS. 50. Figura 3. Datos de un Alumno Ayudante Visualizar Historial Para tener acceso a los historiales de un Alumno Ayudante, se debe dar clic en la opción Visualizar Historial. En esta operación, cuando se selecciona un estudiante, (una fila de la tabla) lo que se muestra es otra tabla que guarda la relación de todos los historiales de ese alumno en su labor de ayudantía. De ahí entonces se escoge cuál es el que interesa ver (Figura 4.).. Figura 4. Historiales de un Alumno Ayudante. Cuando se selecciona uno de estos lo que se muestra es algo como lo que aparece en la Figura 3 con la información de un Alumno Ayudante en un determinado curso de ayudantía..

(61) ANEXOS. 51. Visualizar Horario Docente Para ver cuándo un Alumno Ayudante tiene que impartir un turno de clases, se debe seleccionar la opción Visualizar Horario Docente. En esta acción, cuando se selecciona un estudiante después de realizar la búsqueda, se muestran algunos datos de este y debajo su horario docente como Alumno Ayudante (Figura 5).. Figura 5. Horario de un Alumno Ayudante. Aquí se muestra el día, la sesión y el turno que debe impartir el estudiante seleccionado, además de la asignatura que imparte y la facultad donde está prestando los servicios de docencia.. Jefe de Departamento El Jefe de Departamento es el usuario de mayores privilegios en el ambiente Web, por tanto es quien más operatividad tiene en él y será de hecho, el punto de entrada del sistema, pues los demás usuarios no tendrán funcionalidad hasta que este actor no haya, como mínimo, informado de sus Alumnos Ayudantes a la Secretaria (insertado en la tabla temporal)..

(62) ANEXOS. 52. A continuación describiremos sus posibles acciones y la forma de trabajar con cada una de ellas. Se debe tener en cuenta que el Jefe de Departamento puede tener acceso a las operaciones que se detallaron en los puntos anteriores, teniendo en cuenta esto, se centra la atención solamente en sus casos de uso.. Gestionar Evaluación Cuando el Jefe de Departamento va a evaluar a un Alumno Ayudante (se debe hacer solo al terminar cada semestre) debe seleccionar la opción Gestionar evaluación. Después de realizar la búsqueda (Figura 1) y seleccionar el estudiante deseado, se muestra una página con el siguiente formato:. Figura 6 Evaluar un estudiante. Aquí el jefe de departamento debe seleccionar la evaluación que quiere asignarle al alumno, y si considera que su labor de ayudantía fue relevante durante ese semestre, entonces debe marcar también el campo de destacado. Al dar clic en Evaluar, se guardan estos datos y queda evaluado el estudiante.. Introducir Horario Docente Antes que todo se elige Introducir Horario Docente, se efectúa la búsqueda que se explicó con anterioridad y se selecciona el estudiante al que se le quiere introducir su horario. La forma de introducir la información de los turnos de clases que debe impartir este Alumno Ayudante es como sigue (Figura 7):.

(63) ANEXOS. 53. Figura 7. Introducir horario a un estudiante que sea Alumno Ayudante. Aquí se muestra el nombre, el tutor y el departamento al que pertenece el estudiante y debajo los campos para seleccionar el día de la clase, (calendario que aparece desplegado) la sesión en que tiene que impartirla y el turno que le corresponde. Se oprime Insertar y la información queda recogida en la Base de Datos.. Modificar Horario Docente Esta opción es muy parecida a la detallada en el epígrafe anterior. Su función es permitirle al Jefe de Departamento modificar datos en el horario de un estudiante que hayan cambiado por algún motivo. Para realizar esta acción se elige Modificar Horario Docente y se llega a una página similar a la de la Figura 7 pero con los datos editados y listos para ser modificados.. Gestionar Eliminación Cuando el Jefe de Departamento decide que un estudiante no va a continuar su labor como Alumno Ayudante, debe seleccionar la opción de Gestionar Eliminación, nuevamente se hace la búsqueda y se escoge el alumno que pasará.

(64) ANEXOS. 54. a este estado. La página siguiente mostrará entonces los datos de ese estudiante y dará la posibilidad de eliminarlo (Figura 7).. Figura 8. Eliminar a un estudiante de su labor como Alumno Ayudante. Gestionar Ratificación En caso de que un estudiante vaya a continuar como Alumno Ayudante y se mantengan todos sus datos (tutor que lo atiende, asignatura que imparte, facultad de trabajo, entre otros) el Jefe de Departamento debe seleccionar la opción de Gestionar Ratificación. De forma general, este proceso funciona de igual manera que el que se explicó en el epígrafe anterior, o sea, se muestran los datos de ese estudiante y se brinda la oportunidad para que se ratifique. Desde el punto de vista visual, solo cambia el nombre del botón, que ahora es Ratificar. Para entender esto ver Figura 8.. Gestionar Modificación Si por algún motivo durante el curso cambian los datos de un estudiante, el Jefe de Departamento tiene la posibilidad de actualizarlos seleccionando la opción Gestionar Modificación. Hecha la búsqueda y teniendo el alumno a modificar la secuencia de trabajo es como sigue:.

(65) ANEXOS. 55. Figura 9. Datos editados del estudiante seleccionado En esta primera página se muestran algunos de los datos del Alumno Ayudante seleccionado, de manera que pueden ser cambiados en caso de estar erróneos. Después de tener esta información se da clic en Continuar y se pasa a la siguiente página:. Figura 10. Restantes datos editados del estudiante seleccionado Al igual que en la Figura 9, en esta nueva página se muestran los restantes datos para que sean modificados si es necesario. Después de hacer los cambios pertinentes se da clic en Modificar, y las actualizaciones son hechas en la Base de Datos..

(66) ANEXOS. 56. Gestionar Adición Como se dejó claro anteriormente, de todas las acciones que necesitan establecer una búsqueda, el único caso de uso que la realiza de forma distinta es este que estamos analizando. Es bueno recordar que esta es la única operación encargada de leer de la entidad Student del módulo de Minotaur, por lo que en aras de ganar en eficiencia, no solo se filtran los datos por facultad y carrera, sino que además se le exige al usuario que especifique el grupo en que estudia el alumno para reducir aún más el espacio de búsqueda, de lo contrario se tornaría demasiado engorrosa y lenta la búsqueda. Debido a esto, cuando se selecciona Gestionar Adición se presenta la página que se muestra a continuación:. Figura 11. Búsqueda para insertar un nuevo Alumno Ayudante La lógica de esta búsqueda es básicamente igual que la que se explicó anteriormente y es obligatorio introducir el grupo para que esta surta efecto. Cuando se da clic en Buscar, aparece una tabla con los estudiantes que cumplen los requisitos especificados para que el usuario seleccione el que desee. Luego se pasa a la fase de introducir los datos como se muestra en las siguientes figuras:.

(67) ANEXOS. 57. Figura 12. Primeros datos que debe introducir el Jefe de Departamento. Figura 13. Datos restantes. Cuando ya se tienen todos los datos se debe oprimir el botón Insertar y si la operación se realiza satisfactoriamente se muestra un mensaje de confirmación (Figura 14).. Figura 14. Mensaje de confirmación..

(68) ANEXOS. 58. Secretaria De forma general, la secretaria podrá realizar dos funciones principales desde este módulo: •. Realizar una operación sobre los estudiantes.. •. Obtener reportes de los Alumnos ayudantes.. Antes de entrar en los detalles de cada opción, se muestra la siguiente figura para dar una panorámica del entorno con el que se relacionará la secretaria.. Figura 16. Ventana principal de la aplicación Desktop del Sistema..

(69) ANEXOS. 59. Centrándose en la figura anterior, se puede llegar a la conclusión que la aplicación está dividida en cuatro partes fundamentales. Sección donde se selecciona la operación a realizar.. Figura 17. Operaciones posibles Sección donde se selecciona el tipo de reporte que se desea obtener.. Figura 18. Posibles tipos de reportes Estas dos secciones se encuentran en la parte izquierda de la aplicación y son el punto de entrada para que el sistema pueda trabajar sin ningún tipo de dificultad. Es bueno aclarar, que una no depende de la otra y esto es válido en ambos sentidos, es decir, si se desea realizar una operación no es necesario seleccionar un tipo de reporte, y de igual manera, si se desea obtener un reporte, no es necesario ni seleccionar ni ejecutar una operación..

(70) ANEXOS. 60. Tabla donde se muestra los datos de acuerdo a la operación seleccionada.. Figura 19. Datos de los estudiantes Botones de ejecución.. Figura 20. Botones encargados de manipular los datos de la tabla. Una vez mostradas las secciones en que se divide la aplicación, se pasa a explicar detalladamente cómo se trabaja con las mismas.. Operaciones a realizar con los estudiantes. Las cuatro posibles operaciones que puede llevar a cabo la Secretaria sobre los estudiantes (de su facultad) son: 1. Adicionar 2. Eliminar 3. Modificar 4. Ratificar.