departamento de producción de software
TRANSCRIPT
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"
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"
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
i
PENSAMIENTO
"Daría todo lo que sé, por la mitad de lo que ignoro."
René Descartes
ii
DEDICATORIA
Dedicamos este trabajo a nuestros padres, demás familiares, y a nuestras
amistades más allegadas.
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.
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.
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.
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 Módulo de Control de Alumnos Ayudantes ........................................ 6
1.2 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 Descripción de los Casos de Uso. ................................................... 14
2.2 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
7
3.2 Manual de Usuario. ................................................................................. 23
3.2.1 Nuevas opciones del módulo Desktop del sistema. ......................... 24
3.3 Estado final. ............................................................................................ 26
3.3.1 Generación de reportes. .................................................................. 26
3.4 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
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.
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.
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.
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.
CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES
DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.
5
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
CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES
DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.
6
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.
CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES
DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.
7
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.
CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES
DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.
8
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)
CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES
DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.
9
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.
CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES
DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.
1
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.
CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES
DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.
1
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.
CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES
DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.
1
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
CAPÍTULO 1: CONSIDERACIONES ACERCA DEL MÓDULO DE ALUMNOS AYUDANTES
DEL SISTEMA DE GESTIÓN DE LA NUEVA UNIVERSIDAD.
1
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.
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).
CAPÍTULO 2:
15
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.
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.
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.
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 ();
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.
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:
<!-- Dominio de seguridad para la aplicación de alumnos ayudantes --> <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
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
Alumnos Ayudantes.
Jefes de Departamento.
• Actor que interviene en el ambiente Desktop.
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.
ANEXOS
37
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).
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).
ANEXOS
39
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.
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.
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.
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)
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.
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.
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.
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.
ANEXOS
47
Figura 18. Definición de los datos de un Alumno Ayudante y de la operación a
realizar por la Secretaria con este estudiante.
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
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.).
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.
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).
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):
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á
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:
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.
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:
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.
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.
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.
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
ANEXOS
61
El modo de operar para llevar a cabo una de estas acciones de forma satisfactoria
es el siguiente. Para poder ejecutar una operación, es necesario haber
seleccionado anteriormente una de ellas, como se muestra en la siguiente figura:
Figura 21. Selección de operación.
Una vez seleccionada la operación que se desea ejecutar, se debe dar clic en el
botón Buscar. Esta acción, es la encargada de mostrar en la tabla los estudiantes
que están disponibles en ese momento para que la secretaria opere con ellos. La
aplicación pasará entonces al estado siguiente:
Figura 22. Estudiantes que serán adicionados por la secretaria si esta lo
determina así.
Después que estamos en este punto, la secretaria debe determinar qué hará con
cada estudiante. En caso de dar clic sobre el botón Cancelar Operación, se limpia
la tabla, si por el contrario no desea hacer la operación que seleccionó con un
estudiante determinado, lo marca y oprime Eliminar Estudiante, esto lo eliminará
de la lista de la tabla, si la Secretaria determina que sí realizará una operación con
ANEXOS
62
un estudiante, debe entonces dar clic en Ejecutar Operación y se pueden
presentar los casos que explicamos a continuación.
Nota: Es responsabilidad total de la Secretaria, determinar (en caso que la
operación sea Adicionar, Modificar o Ratificar) si el estudiante debe o no
incrementar su etapa de ayudantía. Para esto, siempre que se ejecuta una de
estas operaciones, se muestra una ventana de diálogo que brinda la posibilidad de
aumentársela o no, según estime la Secretaria.
⇒ Si el estudiante va a ser añadido al movimiento de Alumnos Ayudantes por
primera vez, entonces se muestra el siguiente diálogo:
Figura 23. Insertar estudiante por primera vez
Si se selecciona Yes, se inserta en la primera etapa de ayudantía, en caso
contrario no se hace nada.
⇒ Una nueva variante es que el estudiante no se incorpore a este movimiento
por primera vez (causó baja por “x” motivo y era Alumno Ayudante). En este
caso se presenta el siguiente diálogo:
Figura 24. Insertar estudiante que en algún momento fue Alumno
Ayudante.
ANEXOS
63
⇒ En caso que lo que se quiera sea Modificar o Ratificar, la filosofía que se
sigue es la misma, solo que cuando se va a efectuar una de estas acciones
el estudiante ya tiene que existir como Alumno Ayudante, por lo que nunca
se presentará el caso en que se muestre el primero de los diálogos
anteriores (Figura 23).
⇒ Si al tratar de efectuar una de las operaciones, por alguna causa se
manipula de forma incorrecta la aplicación o no existen estudiantes para
llevar a cabo la acción que se desea se muestran los diálogos que siguen:
Figura 25. Mensaje de error
Figura 26. Mensaje de advertencia
Obtener reportes de los Alumnos Ayudantes
Cuando el objetivo de la Secretaria sea obtener información de los Alumnos
Ayudantes de su facultad, antes que todo debe seleccionar el tipo de reporte que
desea. Aquí pueden presentarse dos variantes, si su finalidad es reportar por
Facultad o por Destacados, la apariencia de la ventana es la que se muestra en la
siguiente figura, pues siempre este reporte se hará a nivel de facultad, por lo tanto
no es necesario preguntar nada más.
ANEXOS
64
Figura 27. Reporte por destacados.
Si por el contrario, el reporte que se pretende es de otro tipo, entonces la vista se
presenta como se muestra a continuación:
Figura 28. Reporte por actividad que realiza.
Debe entonces seleccionar una opción de las posibles para ese tipo de reporte,
por ejemplo, para el caso anterior sería:
Figura 29. Actividades posibles para efectuar un reporte de este tipo.
Para ambas variantes, después que se realicen estos pasos, se debe dar clic en el
botón Reportar y en dependencia del tipo de reporte que se quiera obtener, se
mostrará la información en formato .pdf como se puede ver en la próxima figura:
ANEXOS
65
Figura 30. Reporte por Actividad: Docencia.