Sistema informático para la unidad de hardware y software (página 2)

Un sistema puede ser factible desde el punto de vista técnico y operacional, pero sino es factible económicamente para la organización no puede ser implantado. Para ello, se debe hacer una estimación del costo total del proyecto y compararlo con los beneficios esperados de tal manera que se pueda demostrar que la inversión será retribuida en un futuro.

Tabla 3.5: Costo de JHard

Factibilidad Legal

Para la realización del proyecto no se incurre en ninguna infracción de tipo legal, ya que el software utilizado se encuentra en su totalidad bajo licencias GPL o derivadas. Estas nos permiten el libre uso, modificación y distribución del software bajo esta licencia tanto para la fase de desarrollo como para la implementación de este proyecto.A continuación se listan las herramientas de software requeridas para desarrollar e implementar este proyecto, junto con su respectiva licencia de uso:

• Apache Tomcat: Apache Public License

• Netbeans y sus plugins: Netbeans Public License

• Mysql Server, Administrator, Query Analyzer y Workbench: General Public License (GPL) para la Comunity Edition

• Java Development Kit y Runtime Machine: Common Development and Distribution License (CDDL) en conjunto con la General Public License (GPL)

• DHTMLX Scheduler Open Source –GPL License

CAPÍTULO IV: Diseño y Desarrollo del sistema

Modelado y Diseño de la Base de Datos

La base de datos de JHard cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Se trata del actual paradigma en los modelos de base de datos.

El gestor que alberga la base de datos de JHard es MySQL 5.1

¿Por qué MySQL?

• Goza de completa compatibilidad con Java (SUN es el fabricante de ambos)

• Posee completa integración con Netbeans MySQL,

• Total compatibilidad con JPA y persistencia,

• Soporta procesos almacenados, triggers,

• Licencia GPL

Las necesidades encontradas en la investigación de campo que atañen a todas las personas involucradas son variadas. Todas igual de importantes. Esto influye en todo el diseño de la aplicación, desde el diseño de su base de datos, el diseño de las reglas de negocio, así como el diseño de su interfaz y de las opciones a ofrecer al usuario final. Se decidió dividir o modularizar el sistema en las áreas funcionales que lo conformarán. Los módulos propuestos según las necesidades encontradas son:

• 1. JInvent: Manejo de Inventario del Laboratorio de Hardware (No consumibles)

• 2. JRequest: Solicitud de servicio al laboratorio

• 3. JWiki/JProCur: Modulo colaborativo de conocimiento, con soluciones a problemas comunes, etc.

• 4. ManLab: Modulo de para la gestión de inscripción de laboratorios prácticos en el Laboratorio de Hardware.

• 5. JCanon: Modulo para la gestión de reserva de cañones y/o laptops.

• 6. JHardmin: Interfaz administrativa con la que se podrá administrar los perfiles, roles y autorizaciones de los usuarios.

El diagrama Entidad-Relación (ER) se ordenó a fin que cada módulo tuviera un grupo de tablas o entidades afines para las labores que realizan. Sin embargo, cada módulo no es un sistema aislado, por lo tanto hay relaciones entre ellos. El diagrama ER de JHard es el siguiente:

Figura 4.1: Diagrama Entidad-Relación de JHard

El ER representa las relaciones entre las tablas de la base de datos. Cada tabla o entidad tiene sus propios atributos o campos. Del lado de la aplicación, la persistencia mapea las tablas de la base de datos y crea las entidades, las cuales son objetos instanciables dentro de nuestro sistema. Ahora se mostrará el ER segmentado por módulos, y las relaciones con otras entities:

JRequest

Figura 4.2: Diagrama ER de JRequest

JRequest está fuertemente relacionado con los siguientes módulos:

• Un Estadoequipo puede tener muchas Existencia de JInvent. La relación es Estadoequipo/Existencia a través del Index fkidestadoequipo_existencia.

• Una Existencia de JInvent puede tener muchos Estadoequipo. La relación es Existencia/Bitacoraestados a través del Index fkidequipoexistente_bitacoraestados.

• Una Existencia de JInvent puede tener muchos Mantenimiento. La relación es Existencia/Mantenimiento a través del Index fkidequipoexistente_mantenimiento.

• Una Existencia de JInvent puede tener muchas Solicitud. La relación es Existencia/Solicitud a través del Index fkidequipoexistente_solicitud.

• Un Usuario de JHardmin puede tener muchas Solicitud. La relación es Usuario/Solicitud a través del Index fkidusuario_solicitud.

JWiki y JProCur

Figura 4.3: Diagrama ER de JWiki/JProCur

La relación que mantiene es únicamente con JHardmin y es de la siguiente manera:

• Un Usuario de JHardmin puede tener muchas Entrada. La relación es Usuario/Entrada a través del Index fkidusuario_entrada.

JInvent

Figura 4.4: Diagrama ER de JInvent

Además de las relaciones antes mencionadas entre JRequest y JInvent, éste último posee las siguientes relaciones con el resto de módulos:

• Un Existencia puede tener muchas Asistencia de ManLab. La relación es Existencia/Asistencia a través del Index fkidequipoexistente_asistencia.

• Una Ubicación puede tener muchos Horario de ManLab. La relación es Ubicación/Horario a través del Index fkidubicacion_horario.

• Una Existencia puede tener muchas Reserva de JCanon. La relación es Existencia/Reserva a través del Index fkidequipoexistente_reserva.

ManLab

Figura 4.5: Diagrama ER de ManLab

El módulo de ManLab posee muchas relaciones con el módulo JHardmin. Son las siguientes:

• Un Usuario de JHardmin puede tener un Docente. La relación es Usuario/Docente a través del Index fkidusuario_docente.

• Un Usuario de JHardmin puede tener un Estudiante. La relación es Usuario/Estudiante a través del Index fkidusuario_estudiante.

• Un Usuario de JHardmin puede tener un Instructor. La relación es Usuario/Instructor a través del Index fkidusuario_instructor.

JCanon

Figura 4.6: Diagrama ER de JCanon

JCanon tiene las siguientes relaciones con módulos de JHard:

• Una Reserva puede tener muchos Usuario de JHardmin. La relación es Reserva/Usuario a través del Index fkidusuario_reserva.

• Una Reserva puede tener muchos Docente de ManLab. La relación es Reserva/Docente a través del Index fkiddocente_reserva.

JHardmin

Figura 4.7: Diagrama ER de JHardmin

JHardmin, por su carácter administrativo, se relaciona con cada una de los módulos restantes, ya que es el encargado, entre otras cosas, de manejar las sesiones de cada usuario registrado a nivel de aplicación.

Diseño y Desarrollo de la Capa de Acceso a Datos

La capa de Acceso a datos de JHard es manejada con la Java Persistence API, más conocida por sus siglas como JPA. JPA es la API[11]de persistencia desarrollada para la plataforma Java EE[12]e incluida en el estándar EJB3[13]Esta API busca unificar la manera en que funcionan las utilidades que proveen un mapeo objeto-relacional. El objetivo que persigue el diseño de esta API es no perder las ventajas de la orientación a objetos al interactuar con una base de datos, como sí pasaba con EJB2, y permitir usar objetos regulares (conocidos como POJO"s). Proporciona un estándar para gestionar datos relacionales en aplicaciones Java SE[14]o Java EE, de forma que además se simplifique el desarrollo de la persistencia de datos. Aunque ha sido definida como parte de la especificación EJB 3.0 (Java EE 5), que supone una simplificación sobre versiones anteriores, ya no requiere de un contenedor EJB ni un servidor de aplicaciones Java EE.

Es una API de persistencia de POJO"s (Plain Old Java Object). Es decir, objetos simples que no heredan ni implementan otras clases (como los EJBs). En su definición, ha combinado ideas y conceptos de los principales frameworks de persistencia, como Hibernate[15]Toplink y JDO[16]y de las versiones anteriores de EJB. Todos estos cuentan actualmente con una implementación JPA.

El mapeo objeto-relacional (es decir, la relación entre entidades Java y tablas de la base de datos, queries con nombre, etc) se realiza mediante anotaciones en las propias clases de entidad. No se requieren ficheros descriptores XML. También pueden definirse transacciones como anotaciones JPA. Existió una alta motivación para crear la API persistencia de Java. Muchos programadores enterprise de Java han estado utilizando los objetos persistentes ligeros proporcionados por frameworks open-source u objetos de acceso a datos instanciados a partir de entity beans, ya que los Entities de Enterprise Beans eran considerados demasiado pesados y complicados, y podrían ser utilizados solamente en los servidores de aplicaciones de Java EE. Muchas de las características de los frameworks de persistencia Third-Party fueron incorporadas en la API de persistencia de Java, y los proyectos como Hibernate y la versión open-source TopLink Essentials del fabricante Oracle son ahora implementaciones de la API de persistencia de Java. La implementación de JPA que JHard utiliza es TopLink Essentials[17]de Oracle. Ésta ofrece una solución probada de Java para todas las necesidades de persistencia basadas en alto rendimiento y capacidad de conversión a escala y flexibilidad en arquitectura y diseño. Está probado que Oracle con TopLink trae mayor agilidad, una mejor toma de decisión, y coste y riesgo reducidos a diversos ámbitos de IT en las empresas actuales. Una de las características que hacen de TopLink una implementación de JPA robusta es el mapping[18]que realiza de las tablas de la base de datos a por medio de un enlace Objeto XML, el cual convierte la entidad en un objeto instanciable a través de una estructura XML, muy utilizada en estos días en el mundo del desarrollo en IT. ¿Por qué apostar por JPA?

• Genera automáticamente la capa de Acceso a Datos[19]de la aplicación y se encarga de mantenerla.

• Genera automáticamente las clases (entities) que representan objetos del la aplicación, que a su vez son las mismas tablas dentro de la base de datos.

• Es mucho más fácil realizar varios CRUD[20]para objetos definidos en la aplicación

• Nos centramos únicamente en la capa del Negocio y la Interfaz de usuario o GUI.

¿Por qué TopLink?

• El prestigio de Oracle respalda a dicha implementación

• El mapeo Objeto-XML de las entidades lo hace más efectivo y ágil en comparación de otras implementaciones que utilizan DOM, SAX, o StAX, que son implementaciones de mapeos de objetos hacia XML.

• Licencia GPL para desarrolladores

¿Qué son las Entities?

Se ha hablado mucho de la implementación de las entities (entidades en español) como parte fundamental de la API de persistencia.

Una entidad de persistencia es una clase Java ligera que representa típicamente una tabla en una base de datos relacional. Los casos de la entidad corresponden a las filas individuales en la tabla. Las entidades tienen típicamente relaciones con otras entidades, y estas relaciones se expresan con objetos/relaciones de metadatos. El objeto/relación de metadatos se puede especificar directamente en el archivo de la clase de la entidad usando anotaciones, o en un archivo separado del descriptor de XML distribuido con el uso. JPA, además de innovar el acceso a datos de una aplicación, innova en otros sentidos. Uno de ellos es que posee su propio lenguaje para construir consultas estructuradas, conocido como Java Persistence Query Language (Lenguaje de Consultas de la Persistencia de Java) conocido ampliamente en el mundo de la persistencia por sus siglas en inglés, JPQL. Se utiliza para hacer consultas contra las entidades almacenadas en una base de datos relacional. Las consultas se asemejan a la sintaxis SQL tradicional, pero trabajan en las entidades que han sido mapeadas directamente de la base de datos relacional. A pesar que se asemeja al SQL convencional, posee ciertas diferencias en cuanto a algunas palabras reservadas y operaciones que permite. Las consultas nombradas o Named Queries se declaran dentro de la entidad propietaria de éstas.

Diagrama de Clases

El diagrama de clases es proporcionado por el JPA y la persistencia de entidades de la base de datos convertidas a clases Java. Tómese a consideración que el detalle de cada uno de los atributos y métodos de cada clase irá minuciosamente explicada en el Diccionario de Datos del Capítulo VI de este documento. El diagrama es el siguiente:

Figura 4.8: Diagrama de Clases de JHard

Tabla Resumen de Clases JHard

Tabla 4.1: Tabla de Clases de JHard

Diseño de la  Capa de Negocios

JavaServer Faces (JSF por sus siglas en inglés) es una tecnología para aplicaciones Java basadas en web que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE. JSF usa JavaServer Pages (JSP) como la tecnología que permite hacer el despliegue de las páginas, pero también se puede acomodar a otras tecnologías como  XUL[21]

JSF incluye:

• Un conjunto de APIs para representar componentes de una interfaz de usuario y administrar su estado, manejar eventos, validar entrada, definir un esquema de navegación de las páginas y dar soporte para internacionalización y accesibilidad.

• Un conjunto por defecto de componentes para la interfaz de usuario.

• Dos librerías de etiquetas personalizadas para JavaServer Pages que permiten expresar una interfaz JavaServer Faces dentro de una página JSP.

• Un modelo de eventos en el lado del servidor.

• Administración de estados.

• Beans administrados.

Basándonos en la estructura de JSF, la capa de negocios está escrita en Managed Beans, de sesión (session) o de petición (request).

JHard está basado en el modelo Vista-Controlador (MVC)[22] que nos permite separar la lógica de control (qué cosas hay que hacer pero no cómo), la lógica del modelo (cuál es la información a mostrar y manipular) y la lógica de presentación (cómo interactuar con el usuario).

Utilizando este tipo de patrón es posible conseguir más calidad, un mantenimiento más fácil, etc. La arquitectura del patrón MVC, adaptado al contexto de una aplicación J2EE se muestra en la siguiente figura:

Figura 4.9: Arquitectura MVC

Además, este modelo de arquitectura presenta otras importantes ventajas:

• Hay una clara separación entre los componentes de un programa; lo cual nos permite implementarlos por separado.

• Hay una API muy bien definida; cualquiera que use la API, podrá reemplazar el modelo, la vista o el controlador, sin demasiada dificultad.

• La conexión entre el modelo y sus vistas (ya que puede haber varias) es dinámica: se produce en tiempo de ejecución, no en tiempo de compilación.

Java Server Faces (JSF por sus siglas en inglés) se encarga de conectar la vista y el modelo. Una etiqueta JSP (propia de la vista) puede ligarse a un atributo de un bean propio del modelo. De esta manera, JSF establece el vínculo de enlace entre vista y modelo

Al margen de todo esto, una de las cosas más importantes que permite el uso de este patrón consiste en normalizar y estandarizar el desarrollo de Software, ya que dejamos una vista diseñada y la capa de negocios queda escrita en JavaBeans.

Un apartado importante en el diseño JHard como aplicación web es la separación de la presentación y la lógica de negocio. JSF usa beans para lograr esta separación. Las páginas

JSF se refieren a las propiedades del bean, y la lógica del programa está contenida en el código de implementación del bean. Los beans son fundamentales para programar JSF. Además, cada una de las acciones ejecutadas por los eventos de las páginas están manejadas por métodos del bean.

Los JavaBeans son un modelo de componentes creado por Sun Microsystems para la construcción de aplicaciones en Java.

Se usan para encapsular varios objetos en un único objeto (conocido también en el ámbito del desarrollo como "la vaina"), para hacer uso de un sólo objeto en lugar de varios más simples.

La especificación oficial de JavaBeans de Sun Microsystems los define como "componentes de software reutilizables que se puedan manipular visualmente en una herramienta de construcción"[23].

Sun da otras convenciones con respecto a los JavaBeans, entre las cuales están:

• Debe tener un constructor sin argumentos.

• Sus propiedades deben ser accesibles mediante métodos get y set que siguen una convención de nomenclatura estándar.

• Debe ser serializable.

A primera vista, un bean parece ser similar a cualquier otro objeto. Sin embargo, los beans se manejan de una forma más concreta. Cualquier objeto se crea y se manipula dentro de un programa Java llamando a los constructores e invocando a los métodos. Sin embargo, los beans pueden ser configurados y manipulados sin programar, a través de entornos de trabajo (frameworks) o entornos de desarrollo integrados (IDE-Integrated Development Environment), que los utilizan mediante técnicas de introspección.

En el contexto de JavaServer Faces, los beans no se utilizan para nada relacionado con la interfaz de usuario: los beans se utilizan cuando se necesita conectar las clases Java con páginas web o archivos de configuración.

Cada uno de los módulos de JHard posee su propio Bean con operaciones de CRUD y otras básicas de negocio para el funcionamiento óptimo de cada módulo. Los beans (denominados por los desarrolladores de JHard como BeanBase) son los siguientes:

Tabla 4.2: Tabla de beans de negocios de JHard

Cada uno de los BeanBase de los módulos, heredan de BeanBase.java, que es el que brinda los métodos necesarios para obtener el EntityManager de la persistencia.

Entre las atribuciones que tienen los métodos de estas clases están:

• Registrar nuevas instancias de objetos de cada módulo en la persistencia e ingresarlas a la base de datos.

• Actualizar instancias de objetos de cada módulo en la persistencia y actualizarlas a la base de datos.

• Obtener instancias o arreglos de instancias de objetos de cada módulo de la persistencia para poder manipularlas en el contexto de la aplicación.

• Eliminar instancias de objetos de cada módulo en la persistencia y borrarlas de la base de datos.

• Obtener objetos a partir de registros de la base de datos mediante claves primarias.

• Algunas reglas de negocio básicas.

Desarrollo de módulo de inventarios (JInvent)

JInvent es el módulo de JHard encargado de administrar el inventario de la Unidad de Hardware y software de la UES-FMO en todo lo que son bienes no consumibles, es decir que dicho módulo solamente está capacitado para administrar activos fijos.

La Unidad de Hardware y Software, entre muchas otras, tiene dos grandes funciones: atender las peticiones de soporte técnico de toda la Facultad y administrar el Laboratorio de Cómputo del Departamento de Ingeniería y Arquitectura.

Gracias a ésta última función es que la Unidad tiene a su cargo mucho activo fijo, compuesto en su gran mayoría por hardware, herramientas y mobiliario. Por mencionar algunos:

• Computadoras completas para prácticas

• Impresoras

• Muebles

• UPS

• Scanners

• Discos Duros

• Memorias RAM

• Laptops

• Etc.

Es por ello que dicho módulo está entre los 3 más importantes de JHard (junto con JRequest y ManLab) por las atribuciones de la Unidad dentro de la Universidad.

Hablando estrictamente del negocio[24]de esta sección, básicamente se trata de un CRUD de equipos, piezas, accesorios, hardware, software y demás elementos que forman parte del inventario físico real de la Unidad.

Como se pudo apreciar en el diagrama ER para JInvent (ver figura 4.4) el modelo que se siguió para abstraer al equipo que se tiene en inventario y el número de existencias es el siguiente:

• Cada registro o tupla en la tabla equipo representa un tipo de equipo hardware que posean en la Unidad, ya sean computadoras desktop, laptops, cañones, scanners, impresoras, etc.

• Cada equipo tiene un nombre de modelo propio

• Cada equipo está asociado a una marca dentro de dicha tabla

• Cada equipo tiene una clasificación.

• Cada registro en la tabla clasificación representa un tipo de hardware que puede albergar la Unidad. La clasificación se compone de una serie de tuplas, todas relacionadas jerárquicamente dependiendo todas de una clasificación padre. Las relaciones entre clasificaciones fijas (que no se podrán eliminar):

• General

• Hardware

• Equipos

• Desktops

• Laptops

• Accesorios

• Impresoras

• Proyectores

• Piezas

• Herramientas de mantenimiento

• Dispositivos de red

• Software

• Sistemas operativos

• Utilerías

• Herramientas didácticas (Netbeans, Autocad, etc.)

• Se podrán agregar nuevas categorías en cualquiera de los niveles anteriormente descritos, pero las mencionadas no se podrán eliminar.

• Cada equipo puede tener n existencias. Cada registro de la tabla existencia es cada uno de los equipos físicos representados en la tabla Equipo. Un equipo puede tener muchas existencias. Por ejemplo, si la Universidad adquirió para el Departamento de Ingeniería 20 computadoras Dell Vostro 220 Mini Tower, habrá un registro en la tabla equipo que haga mención a dicha computadora, y 20 registros en la tabla existencia, con relación con la tupla en la tabla equipo que sea para las Dell Vostro 220 Mini Tower. Todas las tuplas de existencia llevarán su respectivo código que las diferencie.

• Una existencia también puede tener asociadas piezas y accesorios. Relaciones con las respectivas tablas en la base de datos

• Una existencia también tiene relación con las instalaciones de software que se le realizan.

• Una existencia posee además una ubicación física dentro del campus, lo cual implica una relación a un registro de la tabla Ubicaciones.

Por lo tanto, el Managed Bean para JInvent tiene las siguientes reglas de negocio:

• Agregar, eliminar y actualizar equipos

• Agregar, eliminar y actualizar piezas

• Agregar, eliminar y actualizar accesorios

• Agregar, eliminar y actualizar existencias

• Agregar, eliminar y actualizar clasificaciones que sean agregadas por el usuario, no las definidas por JHard

• Agregar, eliminar y actualizar software e instalaciones del mismo

• Mostrar listas de equipos, existencias, piezas, accesorios y software

• Obtener el estado de una existencia específica

• Obtener las ubicaciones de toda la Facultad

• Reportar una existencia como fallida

Desarrollo de módulo de Peticiones de servicios (JRequest)

JRequest desempeña una labor fundamental dentro de las funciones de JHard: además que es el módulo que será más utilizado por los usuarios administrativos y docentes, cumple una de las funciones más importantes de la Unidad de Hardware y Software: recibir y paliar todas las solicitudes de soporte técnico para el equipo informático de la Facultad Multidisciplinaria de Occidente.

Las reglas de negocio de JRequest:

• Un usuario registrado previamente en el sistema puede emitir una solicitud para soporte técnico ya sea para hardware o software.

• Una solicitud se realiza hacia un Equipo simple. Un equipo simple es una computadora de la Facultad Multidisciplinaria de Occidente que no forma parte del inventario real de la Unidad de Hardware y Software, pero que requiere de mantenimiento, ya sea preventivo o correctivo.

• Un equipo simple puede tener muchas solicitudes.

• Las solicitudes se encolan, y solo el administrador de la Unidad puede observarlas. Él, con su criterio, decide cuáles son las que se atenderán primero y les asigna técnicos para que las solventen. Una solicitud desencadena un mantenimiento. Un mantenimiento va amarrado a un equipo simple y una solicitud. Un equipo simple puede tener muchos mantenimientos.

• Cuando los técnicos que laboran de turno en la Unidad resuelven el problema, entonces el administrador cambia el estado del mantenimiento a "Finalizado". Cuando hace esto escribe lo que se le realizó a la computadora para solventar el impasse. Con esto se genera una Bitácora de estados. Un equipo simple tiene muchas bitácoras.

• Las bitácoras son totalmente modificables. No pueden ser eliminadas por razones de seguridad y para guardar siempre el registro de cada máquina.

• A cada equipo simple, se le puede actualizar el estado del equipo. Un equipo posee una clave para un estado. Las reglas de negocio estipulan que existen cuatro posibles estados para un equipo:

• Excelentes condiciones

• En reparación

• Dañado

• Irreparable

• Se realizan actividades de mantenimientos (crear y actualizar únicamente) a equipos simples, solicitudes, y técnicos.

Desarrollo de módulo de Equipo multimedia (JCanon)

La Unidad de Hardware y Software tiene a su cargo diverso equipo multimedia utilizado, en la mayor parte del tiempo, en las clases expositivas del Departamento de Ingeniería.

Los resultados de las encuestas arrojaron que el procedimiento para la reserva de equipo multimedia (laptops y proyectores) es poco eficiente y deberían de ser automatizados y más amigables. La respuesta de JHard ante esta problemática es JCanon: el módulo para el manejo y administración de la reserva de equipo multimedia del Departamento de Ingeniería y Arquitectura y que implementa una interfaz novedosa para la visualización de la jornalización del préstamo del equipo.

JCanon es el módulo con el menor número de tablas, por lo tanto las labores de mantenimiento son menores a las del resto de módulos, sin embargo es muy rico en reglas de negocio.

• Únicamente un usuario registrado podrá realizar una reserva de equipo.

• Únicamente el administrador de JHard podrá ingresar a la página administrativa de reservas de equipo y a otras opciones, como agregar equipo multimedia, posponer reservas y ver reportes.

• Cualquiera que sea el rol del usuario está habilitado para pedir una reserva.

• Se hacen reservas de laptops y proyectores por separado, aunque en el mismo formulario se puedan reservar ambos para un mismo evento (una clase expositiva o una presentación por ejemplo).

• La disponibilidad de equipo para una determinada fecha y hora está ligado estrictamente al total de equipo en calidad de reservable que no está reservado a en la hora y el día deseados. Esto se realiza con una consulta JPQL así:

@NamedQueries({

//Contar equipo con calidad de reservables

@NamedQuery (name = "Existencia.contarEquipos", query = "SELECT COUNT(e) FROM Existencia e LEFT JOIN e.idhardware eq WHERE eq.idclasificacion.idclasificacion=:idclasificacion"),

//Comprobar las reservas que comienzan a la misma hora

@NamedQuery (name = "Reserva.findMismaHora", query = "SELECT COUNT(r) FROM Reserva r WHERE r.fechahorainicioprestamo = :fechahorainicioprestamo"),

})

• Para el administrador de JHard:

• Se puede agregar equipo multimedia (cañones y proyectores)

• Ver Reportes

• Posponer reservas

• Cambiar el estado de la reserva: las reservas pueden tener 2 posibles estados:

• Pendiente: Aun no ha llegado la fecha y hora para que se retire el equipo

• En Uso: El período de reserva se está llevando a cabo.

• Despachada: El período de reserva ha culminado y el equipo ha sido entregado satisfactoriamente.

• Eliminar reservas.

Desarrollo de módulo de seguridad (JHardmin)

El módulo de JHardmin es de carácter administrativo y de seguridad. Es el encargado de manejar las sesiones de los usuarios loggeados al sistema, así como de realizar tareas administrativas a los usuarios de JHard.

• Maneja el login de los usuarios que intentan acceder a JHard. Lo realiza con el siguiente método del LoginManager:

/*

* Agrega el usuario a la lista de usuarios logueados, si este existe en la base de datos y si no estaba logueado antes

*/

public synchronized int Login(String userName, String userPwd, String url){

if(!this.isLogged(userName)){

System.out.println("Encriptando…");

if(this.existsInBD(userName, userPwd)){

Usuario usr = new BeanBaseJHardmin().getUsuario(userName,encrypt(userPwd));

this.loggedUsers.put(usr.getIdusuario(), new LoggedUser(usr.getIdusuario(),

userName, usr.getIdrol(), url));

return usr.getIdusuario();

}

}

else{

return this.getUser(userName).getUid();

}

return -1;

}

• Encripta claves mediante MD5

• Utiliza Managed Beans de sesión para el manejo de usuarios loggeados a JHard en cada máquina. Se declara de esta manera en el faces-config.xml:

JHardminInstance

edu.ues.jhard.beans.BeanBaseJHardmin

session

• Por cada usuario que logra loggearse se crea una instancia de LoggedUser.

• Solo el administrador de JHard puede acceder a las páginas jsp de JHardmin

• El administrador tiene designado:

• Agregar nuevos usuarios

• Actualizar usuarios

• Eliminar usuarios

• Cambiar la contraseña de acceso de los usuarios existentes

• Asignar roles a los usuarios existentes.

• Crear códigos de autorización para que usuarios anónimos puedan registrarse en el sistema con el rol Estudiante

Desarrollo del módulo de Administración de grupos de laboratorio (ManLab)

ManLab es un poderoso módulo que administrará los grupos de prácticas para las carreras del Departamento de Ingeniería y Arquitectura de la UES-FMO.

Básicamente está diseñado en 5 grandes áreas, distribuidos en una serie de páginas JSP, cada una validada de acuerdo a jerarquía de roles y usuarios:

• Control de Asistencia

• ManLab permite controlar la asistencia a todas las clases prácticas que se lleven a cabo dentro del Laboratorio de Hardware.

• El instructor o un administrador está autorizado para iniciar o habilitar un curso.

• El mismo instructor o administrador debe finalizar el curso

• Cuando el curso se habilita, los estudiantes inscritos al mismo y que han asistido a dicha clase, marcan su asistencia.

• Se generan reportes de asistencia por clases.

• Se generan reportes de asistencia por el total de laboratorios impartidos por un instructor

• Gestión de Clases

• La autorización de las clases para un respectivo grupo de laboratorio las realiza esta sección.

• Es estricto con los horarios para activar y desactivar grupos, sin embargo la rigurosidad de este módulo así lo exige.

• Control de Horarios

• La creación de la manta de horarios por ciclo se hace en este módulo.

• Se pueden agregar cursos a distintos horarios.

• Hay completa libertad en la asignación de los horarios a los cursos, así como del número de horarios asignados para un curso.

• Este módulo es puramente administrativo, por lo tanto el encargado de la Unidad de Hardware y Software tiene completa libertad sobre el mismo.

• Se muestra también en un popUp aparte la manta de horarios para el ciclo actual. Muestra también la semana actual en la que se desarrolla el ciclo.

• Las labores de mantenimientos de horarios también se realizan en este módulo. El administrador tiene completa libertad sobre la misma

• Inscripciones

• Este módulo permite acceder a los estudiantes hacia los distintos cursos a impartirse en determinado ciclo.

• El administrador habilita cursos para que los estudiantes autorizados puedan ingresar a ellos.

• El límite de personas en curso lo coloca el administrador

• Mientras no llega al máximo asignado, los estudiantes se siguen inscribiendo.

• El administrador da mantenimiento a dicha área.

• Mantenimientos

• Ciertos ítems necesitan mantenimientos, es decir, labores de agregado, eliminado y actualizado.

• Objetos como materia, curso, inscripciones, etc. necesitan dichos mantenimientos, y esta área se encarga de realizarlos

• Área completamente administrativa.

Desarrollo del módulo de Manejo de Contenidos (JWiki y JProCur)

Estos módulos son una manera innovadora de dar a conocer información necesaria desde el ámbito administrativo/organizativo de la Facultad, así como en conocimientos meramente informáticos.

• Están realizados 100% en Java e ICEfaces.

• Interfaces amigables para el usuario

• Sistema de búsquedas de artículos y entradas sensible a las necesidades del usuario

• Las entradas son para JProCur, que es un CMS puro, y los artículos son para JWiki, que es una Wiki de conocimientos informáticos.

• Administradores y editores de contenido pueden entrar a las partes administrativas de estos módulos.

• Cada usuario con privilegios de escritura tiene entradas y/o artículos asociados, según sea el módulo al que llegue.

• La interfaz para crear nuevas entradas y/o artículos es sumamente amigable al usuario, soporta texto enriquecido y guarda grandes cantidades de texto dentro de la base de datos.

• La navegabilidad entre estos módulos es sencilla.

• La integración entre JRequest y JWiki es completa, ya que desde el módulo de peticiones de servicio se pueden consultar los artículos publicados en JWiki sin ningún problema.

• Cualquier usuario invitado puede accesar a los artículos de JWiki y las entradas de JProCur.

Diseño de la Interfaz de Usuario general

La interfaz visual de JHard está diseñada en un 95% con el framework ICEfaces, sustituto "natural" del proyecto Woodstock de Sun.

ICEfaces Es un framework de código abierto para construir aplicaciones web con AJAX tipo RIA (Rich Internet Application).

Permite al programador incluir una serie de Ajax-tags en sus JSP o xhtml de tal manera que el código Ajax es generado por el propio framework automáticamente.

Figura 4.9: Logo de ICEfaces

ICEFaces aisla completamente al desarrollador de AJAX. No hacen falta etiquetas especiales: se ponen los controles en la pantalla e ICEFaces se encarga de enviar sólo la información necesaria entre cliente y servidor.

Es decir, ya no se envían los formularios a la antigua usanza, en un POST de HTTP, sino que sólo se envían los cambios que ha hecho el usuario del cliente al servidor, y los cambios en la pantalla del servidor al cliente.

Además, con la inclusión de la librería Scriptaculous en ICEFaces, se dispone de arrastrar+soltar y de efectos (fundidos, parpadeos, apariciones) para los controles.

Características.

ICEfaces es considerado un framework que integra funcionalidad AJAX y permite a los desarrolladores Java EE crear aplicaciones RIA (Rich Internet Applications) de una manera sencilla.

Las aplicaciones desarrolladas en ICEfaces no necesitan plugins de navegador o applets para ser vistas.

Estas aplicaciones están basadas en JavaServer Faces (JSF), así que permite el desarrollo de aplicaciones Java EE con la posibilidad de utilizar de forma fácil desarrollos basados en JavaScript.

En torno a AJAX han surgido varios frameworks (Prototype, DWR, GWT) que, si bien aportaban facilidad de uso, no acababan de convencer a la comunidad de programadores. Algunos porque sólo eran clientes Javascript, otros porque, si bien integraban la parte de servidor con la de cliente, no eran realmente frameworks, sino librerías de comunicación. Además, no estaba claro cómo juntarlos con la arquitectura JEE.

Con la llegada de JSF, se empezó a vislumbrar posibilidades de integración. Si JSF permitía al desarrollador aislarse de la arquitectura web y ver sus aplicaciones como algo parecido a una aplicación de escritorio, debería entonces ser sencillo utilizar AJAX para hacer estos controles más funcionales. Y así fue, empezaron a aparecer AJAX4JSF, ICEFaces, Tobago, etc.

Sin embargo, de estas propuestas, ICEFaces fue una de las más acogidas ya que aisla completamente al desarrollador de AJAX. No hacen falta etiquetas especiales: se ponen los controles en la pantalla e ICEFaces se encarga de enviar entre cliente y servidor sólo la información necesaria.

Se presenta una figura con la arquitectura de una aplicación en JSF integrada con ICEFaces:

Figura 4.10: Arquitectura general de ICEfaces

Los principales elementos de la arquitectura ICEfaces incluyen:

• Persistent Faces Servlet: Las URLs con extensión ".iface" son mapeadas por el servlet 'Persistent Faces Servlet'. Cuando se realiza una petición de la página inicial en la aplicación, este servlet se hace responsable de la ejecución del ciclo de vida JSF para petición asociada.

• Blocking Servlet: Se encarga de la gestión de todas las peticiones de bloqueo y no-bloqueo después de las primeras páginas.

• D2D ViewHandler: Se encarga de establecer el Direct-to-DOM, incluyendo la inicialización de la 'DOM Respuesta Writer'. El ViewHandler también invoca al Parser para analizar el árbol de componentes JSF en la página inicial.

• Parseador D2D: Responsable del montaje de un componente de documentos JSP. El Parser ejecuta la etiqueta de JSP de procesamiento del ciclo de vida con el fin de crear el árbol, pero lo hace sólo una vez para cada página. La compilación del estándar JSP y el proceso de análisis no es compatible con ICEfaces.

• DOM Response Writer: Se encarga de la escritura en el DOM. También inicia la serialización DOM para la primera prestación, y desbloquea el DOM Updater para actualizaciones incrementales.