CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
1.9 Soluciones Asíncronas JMS
1.9.1 Arquitectura de JMS
Una aplicación JMS consta de los siguientes elementos:
• Clientes JMS Aplicaciones que envían o reciben mensajes a través de JMS
• Mensajes Los mensajes que se intercambian
• Objetos administrados Los objetos JMS a los que se dirigen las comunicaciones
Clientes JMS
Son clientes de JMS tanto el que suministra mensajes como el que los recibe.
Mensajes
Es el corazón del sistema de mensajes. Están formados por tres elementos: cabecera (header), propiedades (properties) y cuerpo (body).
• Cabecera: Es la cabecera del mensaje, contiene una serie de campos que le sirven a los clientes y proveedores a identificar a los mensajes.
CAPÍTULO 1. MARCO TEÓRICO
• Propiedades: Son propiedades personalizadas para un mensaje en particular.
• Cuerpo:Es el mensaje en sí.
Objetos administrados
Los objetos administrados son el punto al que se comunican los clientes JMS para enviar o recibir mensajes, se denominan objetos administrados por que los crea el administrador. Hay dos tipos de objetos administrados en JMS:
• ConnectionFactory: Se usa para crear una conexión al proveedor del sistema de mensajes.
• Destination: Son los destinos de los mensajes que se envían y el recipiente de los mensajes que se reciben.
1.10 Enterprise JavaBeans
EJB (Enterprise JavaBeans) es un modelo de programación que nos permite construir aplicaciones Java mediante objetos ligeros. El objetivo de los EJB es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lógica de negocio en sí y deja el resto de responsabilidades al contenedor de aplicaciones donde se ejecutará la aplicación. Existen tres tipos de EJBs: EJB de Entidad (Entity EJBs), EJB de Sesión (Session EJBs) y EJB dirigidos por mensajes (Message-Driven Beans, MDB).
En este caso lo interesante son los EJB dirigidos por mensajes (MDB).
1.10.1 MDB - Beans Dirigidos por Mensajes
Message-Driven Beans (MDB - Beans Dirigidos por Mensajes) son componentes de tipo listener que actúan de forma asíncrona. Su misión es la de consumir mensajes (por ejemplo: eventos que se producen en la aplicación), los cuales pueden gestionar directamente o enviar (derivar) a otro componente. Los MDB actúan sobre un proveedor de mensajería, en este caso, Java Messaging System (JMS es además soportado de forma implícita por la especificación EJB). Los Message-Driven Beans no mantienen estado entre invocaciones.
CAPÍTULO 1. MARCO TEÓRICO
Conclusiones Parciales
El módulo que se nos ha encomendado realizar es una parte de un sistema de información que tiende a controlar la información del Postgrado en un Centro de Educación Superior. Para su análisis, diseño e implementación se tienen en cuenta los conceptos abordados en este capítulo, en especial lo referente a Sistemas de Información y Bases de Datos Objeto-Relacional.
El SGBD PostgreSQL fue el seleccionado para realizar la implantación del módulo que nos ocupa, ya que a pesar de sus desventajas, es un buen gestor (figura 1.1). Además es una orientación del MES que se trabaje con el mismo, porque tiene la propiedad de ser un software libre y el Sistema de Postgrado debe ser compatible con el proyecto SIGENU, cuyas bases de Datos se encuentran también en PostgreSQL.
Para la creación de los informes se ha utilizado el iReport, porque además de ser un software libre posee características fundamentales para el desarrollo de los informes requeridos, y es muy fácil de usar.
En cuanto al sistema de mensajes, conviene utilizarlo ya que permite manejar de una forma segura los informes que se requieren y así el usuario no tendría que esperar a que el sistema termine los informes, sino que puede seguir trabajando en otras opciones.
CAPÍTULO 2. ANÁLISIS Y DISEÑO
DEL SISTEMA
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
Para el análisis y diseño del sistema, se utilizó el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) es un lenguaje gráfico estándar para escribir planos de software. UML prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan.
2.1 Diagrama de Casos de Uso
En UML, un Diagrama de casos de uso es una especie de diagrama de comportamiento que muestra la relación entre los actores y los casos de uso del sistema. Un diagrama de casos de uso consta de los siguientes elementos: Actor, Casos de Uso y Relaciones.
Actor
Un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.
Casos de Uso
Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
Relaciones
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
2.1.1 Casos de Uso del Módulo de Reportes
Para el Módulo de Reportes del Sistema de Postgrado, los Casos de Uso se basan en Gestionar diferentes tipos de informes. Cada Caso de Uso incluye un conjunto de informes, como se observa a continuación:
Informes sobre Profesores de PG
• Certificación de Impartición de Curso de Postgrado
• Certificación de Tutoría de Tesis de Postgrado
• Certificación de Asesoría de Entrenamiento de Postgrado
Informes Finales de Superación Profesional de Postgrado (SPPG)
• Acta de Evaluación de Curso de Postgrado
• Acta de Evaluación de Entrenamiento de Postgrado
• Informe Final de Curso de Postgrado
• Informe Final de Diplomado de Postgrado
• Informe Final de Entrenamiento de Postgrado
• Lista de Matrícula de Curso de Postgrado
• Lista de Matrícula de Diplomado de Postgrado
• Lista de Matrícula de Entrenamiento de Postgrado
• Modelo Oficial Matrícula PGSP
• Planificación de Curso de Postgrado
• Planificación de Entrenamiento de Postgrado
Certificados de SPPG
• Certificación de Curso de Postgrado
• Certificación de Diplomado de Postgrado
• Certificación de Entrenamiento de Postgrado
Informes sobre Postgrados Académicos (PGA)
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
• Constancia de Aprobación de Autorización de Defensa de Tesis
• Fichas de Maestrías y Especialidades
• Modelo Oficial Matrícula PGA
• Informe Final de Curso de Postgrado de PGA
Certificados sobre PGA
• Certificación de Culminación de Estudios de Especialidad
• Certificación de Culminación de Estudios de Maestría
Informes Estadísticos Oficiales
• Modelo 1164-01 a nivel de Facultad
• Modelo 1164-01 a nivel de Universidad
Informes sobre Aspirantes y Doctores
• Aval de Predefensa
• Aprobación de Ingreso del Aspirante
• (Modelo3) Exámenes de candidato realizados y tiempo de desarrollo del Doctorado
2.1.2 Actores del Módulo de Reportes
Los Actores que interactúan con el sistema son:
• Secretaria Docente
• Secretaria de PG
• Vice Decano PG
• Dirección PG Universitaria
2.1.3 Diagrama de Casos de Uso del Módulo de Reportes
A continuación se muestra el Diagrama de Casos de Uso del Módulo de Reportes del Sistema de Postgrado.
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
Figura 2.1 Diagrama de Casos de Uso.
2.2 Diagramas de Actividades
En UML un diagrama de actividades muestra la serie de actividades que deben ser realizadas en un caso de uso, así como las distintas rutas que pueden irse desencadenando en el caso de uso. Los diagramas de actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad. Estos también pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en la ejecución de algunas actividades.
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
Un diagrama de actividad es utilizado en conjunción de un diagrama de caso de uso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y cómo reacciona en determinados eventos.
Los elementos fundamentales que constituyen un Diagrama de Actividades son:
Inicio
El inicio de un diagrama de actividad es representado por un círculo de color negro sólido.
Actividad
Una actividad representa la acción que será realizada por el sistema.
Transición
Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra.
Ramificación (Branch)
Una ramificación ocurre cuando existe la posibilidad que ocurra más de una transición (resultado) al terminar determinada actividad.
Bifurcación (Fork)
Un fork representa una necesidad de ramificar una transición en más de una posibilidad. Aunque similar a una ramificación (Branch) la diferencia radica en que un fork representa más de una ramificación obligada, esto es, la actividad debe proceder por ambos o más caminos, mientras que una ramificación (Branch) representa una transición u otra para la actividad (como una condicional).
Unión (Join)
Un join ocurre al fusionar dos o más transiciones provenientes de un fork, y es empleado para dichas transiciones en una sola, tal y como ocurría antes de un fork .
Fin
El fin de un diagrama de actividad es representado por un círculo, con otro círculo concéntrico de color negro sólido.
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
2.2.1 Diagramas de Actividades del Módulo de Reportes
Cuando un usuario necesita un informe, lo primero que debe hacer es identificarse con el Sistema. Un vez que tenga permiso el sistema presenta el menú, y el usuario debe seleccionar el informe que necesite y entrar los parámetros que necesita el sistema. En ese momento el Sistema crea la solicitud del informe y la envía al planificador del sistema, el que pone en cola dicha solicitud y notifica al usuario que la solicitud se está procesando. Esta solicitud queda en espera hasta que el planificador del sistema esté listo y pueda recibir la solicitud. Una vez que sea recibida, el JasperReport prepara el informe, se hace la consulta al Sistema Gestor, cuando la consulta está lista el JasperReport crea el informe, seguidamente el planificador guarda el informe y envía una notificación al usuario que el informe está terminado (Ver Figura 2.2).
Figura 2.2 Diagramas de Actividades para Gestionar Informes
2.3 Diagramas de Componentes
Un diagrama de componentes representa cómo un sistema de software es dividido en
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
diagramas de componentes describen los elementos físicos del sistema (incluyen
archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes.) y sus relaciones muestran las opciones de realización incluyendo código fuente, binario y ejecutable. Son utilizados para modelar la vista estática y dinámica de un sistema.
2.3.1 Diagrama de Componentes del Sistema de Postgrado
El Sistema de Postgrado está compuesto por diferentes componentes. Postgrado WEB es la aplicación en sí, quien llama a Clases de Base de Postgrado, es como el controlador, donde se encuentran todas las clases en Java, una vez que se hace una petición al sistema se envía la solicitud a la Cola de Mensajes, cuando se atiende la solicitud se llama a Postgrado JasperReport para generar el informe y al terminar se envía la notificación al Servidor de Correo. Ver figura 2.3.
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
2.4 Diagramas de Despliegue
En UML el Diagrama de Despliegue se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de diagrama son nodos, componentes o artefactos y asociaciones.
Nodo
Un Nodo es un elemento de hardware o software, donde se ejecutan los componentes, representan el despliegue físico de estos componentes. Un nodo puede contener otros elementos, como componentes o artefactos.
Artefacto
Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso ( modelos de Casos de Uso, modelos de Diseño, etc.), archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto.
Asociación
En el contexto del diagrama de despliegue, una asociación representa una ruta de comunicación entre los nodos.
2.4.1 Diagrama de Despliegue del Sistema de Postgrado
En este caso las salidas del sistema serán generadas en el Servidor de Informes donde va a estar ejecutándose el JasperReport. Ver Figura 2.4
CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
Figura 2.4 Diagrama de Despligue del Sistema de Postgrado
Conclusiones Parciales
En el capítulo que recién termina, se han diseñado los principales diagramas para el análisis del Módulo de Salidas del Sistema de Postgrado. Utilizando el lenguaje UML, que cumple con el propósito del primer objetivo específico, quedando detallado los casos de usos y las actividades del presente módulo, además de las necesidades de hardware y software que se requieren para instalar el sistema, y de este modo cumplir con los requerimientos del MES y de la Dirección de Postgrado.
CAPÍTULO 3. Aspectos de la
Implementación y el uso del Módulo de
Informes del SPG.
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
CAPÍTULO 3. Aspectos de la Implementación y el uso del
Módulo de Informes del SPG.
3.1 Aspectos de la Implementación
Para diseñar cada informe se utilizó la herramienta iReport. Luego de ejecutar el software, para crear un informe es necesario seguir los siguientes pasos:
1. Crear un reporte en blanco.
2. Poner un nombre y la dirección donde se va a guardar. 3. Terminar.
Figura 3.1 Informe Nuevo
Una vez que iReport muestra la plantilla del nuevo informe (Figura 3.1) se procede a diseñar el informe según se requiere, auxiliándonos de la paleta que brinda la herramienta, como se muestra en la figura 3.2.
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
Figura 3.2 Paleta de iReport
Una vez que se tiene el diseño terminado, podemos editar la consulta mediante el editor de consultas que brinda iReport (Figura 3.3).
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
Después de realizada la consulta podemos observar previamente los resultados, lo mismo internamente en el software que en los distintos formatos que facilita iReport como se menciona en el Capítulo 1.
3.1.1 Gestión del Certificado de Evaluación de Curso de Postgrado
El Módulo de Salidas del SPG, está formado por diferentes Certificados e Informes, que muestran datos relevantes necesarios para la implementación del mismo. A continuación se presentan breves aspectos sobre la implementación del Certificado de Evaluación de Curso de Postgrado, donde una vez que se introducen los elementos estáticos del informe, se colocan los campos de la consulta en el lugar que le corresponde, para que después de cargar esos datos de la base de datos, queden en el lugar indicado.
Figura 3.4 Diseño del Certificado de Evaluación de Curso de Postgrado.
Una vez que el informe esté diseñado, se crea la consulta que requiere el informe, en este caso:
SELECT
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes curso."fechafin" AS curso_fechafin, evaluacion."nombre" AS evaluacion_nombre, evaluacion."nota" AS evaluacion_nota, persona."nombre" AS persona_nombre, persona."apellido1" AS persona_apellido1, persona."apellido2" AS persona_apellido2, programa_curso."nombre" AS programa_curso_nombre, programa_curso."horastotal" AS programa_curso_horastotal, programa_curso."credito" AS programa_curso_credito FROM
"public"."curso" curso INNER JOIN "public"."estudiante_curso" estudiante_curso ON curso."id" = estudiante_curso."cursoid"
INNER JOIN "public"."evaluacion" evaluacion ON estudiante_curso."nota" = evaluacion."id"
LEFT OUTER JOIN "public"."estudiante" estudiante ON estudiante_curso."estudianteid" = estudiante."id"
INNER JOIN "public"."persona" persona ON estudiante."personaid" = persona."id"
INNER JOIN "public"."programa_curso" programa_curso ON curso."programaid" = programa_curso."id"
La misma se muestra mediante el editor de consultas de iReport, lo mismo gráfico que textual, figuras 3.5 y 3.6 respectivamente.
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
Figura 3.6 Editor de Texto de Consultas de iReport.
Después de realizada la consulta se pueden observar los datos previos que emite la consulta, así como ver todos los campos que se seleccionaron en la consulta, ordenar los datos en orden ascendente o descendente, crear nuevos parámetros, entre otras opciones, como se muestra en la figura 3.7.
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
3.2 Uso del Módulo de Salidas
El Sistema de Postgrado versión 5.4 posee una Interfaz de Usuario de muy fácil uso y amigable. Comprende una página de inicio con el menú correspondiente, a partir del cual se encuentran todas las opciones de dicho sistema (Figura 3.8).
Figura 3.8 Inicio del Sistema de Postgrado.
Una vez que el usuario se haya identificado con el sistema puede acceder a seleccionar los informes mediante el menú. La figura 3.9 muestra como en la pestaña Personas, se encuentran los Datos de Personas, de Estudiantes y de Profesores. Dentro de los datos de Estudiantes, los informes correspondientes al mismo.
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
Figura 3.9 Menú Datos del Estudiante.
Una vez que el usuario haya seleccionado el informe que desea el sistema mostrará un mensaje como el que se muestra en la figura 3.10, lo que significa que la solicitud se envió a la cola de mensajes, hasta esperar que el suscriptor de la cola pueda atender dicha solicitud, es aquí donde juega el papel más importante las soluciones asíncronas, utilizando los MDB para tratar las solicitudes.
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
Figura 3.10 Solicitud en proceso.
Cuando la solicitud es atendida, JasperReport prepara el informe, se hacen las consultas correspondientes al Gestor de Bases de Datos PostgreSQL y se crea completamente el informe. Seguidamente el informe se guarda en dos formatos: PDF y HTML. El planificador del sistema envía un correo al usuario que hizo la solicitud de que el informe está terminado y con un hipervínculo al documento guardado como se muestra en la figura 3.11.
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
Figura 3.11 Notificación de Informe Terminado
Una vez que llega el correo se puede acceder a los informe lo mismo en formato PDF que HTML como se muestra en las figuras 3.12 y 3.13 respectivamente.
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
Figura 3.13 Certificación de Evaluación de Curso de Postgrado en formato HTML
3.3 Otros Aspectos Generales de Implementación
3.3.1 Creando el Informe
Para crear el informe es necesario crear un objeto de JasperReport y un JasperPrint para imprimir, luego se hace la conexión con la base de datos, se realiza la consulta y si es necesario se pasan parámetros. Se compila el informe, se llenan los campos y se guardan en los formatos que se indiquen. Como se muestra en el código.
CAPÍTULO 3. Implementación y el Uso del Módulo de Informes
…..
public static void main(String[] args) { JasperReport jreport;
JasperPrint jprint; Connection conn = null; try { Class.forName("org.postgresql.Driver"); String postgresURL = "jdbc:postgresql://127.0.0.1:5432/postgrado/";