Integración de un captador de datos biométricos en una intranet corporativa para el control y gestión de horarios

Pablo Quintana Quintana Las Palmas de Gran Canaria, 2014 PROYECTO FIN DE CARRERA Integración de un captador de datos biométricos en una intranet corporativa para el control y gestión de horarios Proyecto fin de carrera de la Escuela de Ingeniería Informática - ULPGC___________________ Proyecto fin de carrera de la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria presentado por el alumno: Pablo Juan Quintana Quintana Título del Proyecto: Integración de un captador de datos biométricos en una intranet corporativa para el control y gestión de horarios Tutor: Rodríguez Rodríguez Abraham Cotutor: Vera Gómez Juan Alberto Proyecto fin de carrera de la Escuela de Ingeniería Informática - ULPGC___________________ A mis abuelos Antonio y Pura. ÍNDICE________________________________________________________________________ ÍNDICE 1. Introducción .............................................................................................................................. 9 2. Gestión de proyecto ................................................................................................................ 10 2.1 Selección del modelo de desarrollo del software ............................................................. 10 2.2 Planificación e hitos ........................................................................................................... 12 2.3 Gestión de riesgos ............................................................................................................. 15 2.4 Gestión de la configuración ............................................................................................... 16 3. Estudios previos ...................................................................................................................... 18 3.1 Estudio de la intranet corporativa..................................................................................... 18 3.1.1 Introducción ............................................................................................................... 18 3.1.2 Estudio de modelo de negocio ................................................................................... 18 3.1.2.1 Tecnología del modelo de negocio ..................................................................... 18 3.1.2.2 Diseño del modelo de negocio ............................................................................ 22 3.1.2.3 Configuración del Servidor de aplicaciones y la base de datos........................... 24 3.1.2.4 Compilación y despliegue. ................................................................................... 25 3.1.2.5 Detalles de implementación, estructura de datos complejos y valores estáticos en persistencia ................................................................................................................ 26 3.1.3 Estudios de la interfaz ................................................................................................ 28 3.1.3.1 Tecnologías de la interfaz .................................................................................... 28 3.1.3.2 Diseño .................................................................................................................. 29 3.1.2.4 Compilación y despliegue. ................................................................................... 31 3.2 Sensores biométricos (Estado del arte) ............................................................................ 31 3.2.1 Introducción ............................................................................................................... 31 2.2.2 Funcionamiento y rendimiento .................................................................................. 32 3.2.3 Procesos de Autentificación e Identificación Biométrica ........................................... 33 3.2.4 Modalidades biométricas ........................................................................................... 34 4. Análisis de requisitos ............................................................................................................... 36 4.1 Requisitos de usuario ........................................................................................................ 36 4.2 Requisitos del software ..................................................................................................... 39 4.3 Requisitos del hardware .................................................................................................... 42 4.4 Estudio de viabilidad de integración ................................................................................. 42 4.4.1 Viabilidad de integración en el modelo de negocio ................................................... 43 4.4.3 Viabilidad de integración en la interfaz gráfica .......................................................... 44 ÍNDICE_____________________________________________________________ 5. Proceso de selección del terminal biométrico ........................................................................ 45 5.1 Selección de una modalidad biométrica ........................................................................... 45 5.2 Selección y análisis del terminal modelo Kreta 3 de Kimaldi ............................................ 47 6. Diseño ...................................................................................................................................... 50 6.1 Diseño del nuevo módulo en la lógica de negocio ............................................................ 50 6.2 Diseño del nuevo componente de interfaz ....................................................................... 66 6.3 Diseño del conector .......................................................................................................... 77 7. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3 .................... 82 7.1 Descripción general y funciones principales ..................................................................... 82 7.2 Comunicación IP ................................................................................................................ 83 7.4 Modelo de programación .................................................................................................. 88 7.4.1 Configuración ............................................................................................................. 88 7.4.2 Base de Datos ............................................................................................................. 91 7.4.2 Descripción de las instrucciones ................................................................................ 95 7.5 Pruebas y ejemplos de uso .............................................................................................. 102 7.6 Dificultades encontradas ................................................................................................. 107 8. Implementación .................................................................................................................... 109 8.1 Implementación del cliente (GUI) ................................................................................... 109 8.2 Implementación del servidor .......................................................................................... 111 8.2.1 Implementación de la lógica de negocio .................................................................. 111 8.2.2 Implementación del conector .................................................................................. 113 8.2.3 Implementación de los planificadores ..................................................................... 114 9. Pruebas .................................................................................................................................. 115 9.1 Pruebas GUI ..................................................................................................................... 115 9.2 Pruebas modelo de negocio ............................................................................................ 118 9.2.1 Especificación ........................................................................................................... 118 9.2.2 Diseño ....................................................................................................................... 124 9.2.3 Implementación ....................................................................................................... 130 9.2.4 Configuración y ejecución ........................................................................................ 132 9.2.5 Resultados ................................................................................................................ 139 10. Desarrollos futuros .............................................................................................................. 142 11. Resultados y conclusiones ................................................................................................... 146 12. Herramientas de edición, compilación y control de la configuración ................................. 148 13. Acrónimos ........................................................................................................................... 149 14. Bibliografía .......................................................................................................................... 150 ÍNDICE________________________________________________________________________ Apéndice I. Manual de usuario ................................................................................................. 151 Apéndice II. JavaDoc .................................................................................................................. 173 Apéndice III. Especificaciones Terminal Biométrico Kreta3 ...................................................... 188 Apéndice IV. Contenido CD-Rom .............................................................................................. 189 Gestión de proyecto_____________________________________________________________ 15 2.3 Gestión de riesgos Los objetivos de la gestión de riesgos son identificar, controlar o eliminar las fuentes de riesgo antes de que empiecen a afectar al cumplimiento de los objetivos del proyecto. Se han identificado los siguientes riesgos para el desarrollo del proyecto para los cuales se ha ideado uno o varias medidas de contingencia. Retraso en la adquisición del terminal. La compra del terminal biométrico, tal y como indica la planificación, debe efectuarse una vez concluida T4 y debe ser un hecho al comienzo de la T6. El riego más plausible es que los trámites de compra retrasen el poder disponer del terminal más del tiempo máximo que implica esta dependencia, retrasando el resto de las etapas y la consecución del proyecto. En este riesgo también se incluye la posibilidad de retraso debido a que una primera compra no cumpla las expectativas deseadas. Para minimizar este riesgo se seleccionará un proveedor nacional y de garantías. En el caso que aun así se retrasara se podría ir abordando de forma adelantada la T7 implementando las capas menos relacionadas con la interfaz del terminal, GUI, modelo de datos. Pudiendo llegar a solicitar el manual de instrucciones del terminal para completar detalles del desarrollo dependientes del terminal biométrico adquirido, como los parámetros de configuración del mismo que mantendrá el modelo de datos. Este riesgo, al verse influido por factores externos, no se elimina, pero con las medidas adoptadas si se reduce tanto la posibilidad que ocurra, como en su impacto en el proyecto en forma de retrasos temporales. Impactos por modificaciones o fallos en la Intranet Como ya se ha expuesto el desarrollo es dependiente de un software ya existente, que está sujeto a continuos cambios y posibles fallos que pueden impactar negativamente retrasando el desarrollo del proyecto. Para minimizar esta dependencia se partirá de una versión estable de la intranet que no se modificará con nueva funcionalidad al margen de la del proyecto, a lo Gestión de proyecto_____________________________________________________________ 16 largo de toda la vida del proyecto, excepto para incluir la solución a posibles fallos encontrados. Una vez concluido el desarrollo se planeará la entrega de la nueva funcionalidad en la versión en curso de la intranet. El equipo de desarrollo de la intranet tendrá en cuenta que existe un desarrollo paralelo evitando cambios que lo impacten y perjudiquen la entrega. Y el equipo de desarrollo del módulo de control y gestión de horarios se ceñirá a la planificación para no perjudicar el desarrollo de la intranet debido a esta dependencia. En este caso el riesgo queda neutralizado por las medidas adoptadas. 2.4 Gestión de la configuración Se denomina Gestión de la Configuración al conjunto de procesos destinados a asegurar la calidad de todo producto obtenido durante cualquiera de las etapas del desarrollo, a través del estricto control de los cambios realizados sobre los mismos y de la disponibilidad constante de una versión estable de cada elemento para toda persona involucrada en el citado desarrollo. Como se ha adelantado en la gestión de riesgos el desarrollo de la nueva funcionalidad en la etapa de implementación se realizará en una rama de desarrollo del Sistema de control de versiones (CVS). Esta rama será exclusiva para este proyecto, partiendo de una versión de la rama principal de desarrollo, con contenido estable y probado de la intranet. Tan solo la solución de fallos que impacten a la rama de desarrollo del módulo serán traídos desde la rama principal. Finalmente se realizará un merge de entrega desde la rama de desarrollo a la rama principal. El diagrama de la Figura 2 ilustra los procedimientos para el control de cambios a nivel de proyecto general que constituye el desarrollo de la intranet. Gestión de proyecto_____________________________________________________________ 17 Figura 2. Diagrama de control de cambios. Estudios previos_____________________________________________________________ 18 3. Estudios previos 3.1 Estudio de la intranet corporativa 3.1.1 Introducción La intranet corporativa de Edosoft Factory (ICEF) es una herramienta cliente servidor a media que permite la gestión integral de la empresa: empleados, proyectos, proveedores, clientes… En el estudio de la herramienta se describen las tecnologías y lenguajes empleados en las diferentes partes que componen la aplicación (Servidor: Modelo de negocio y Cliente: Interfaz gráfica de usuario). Además se aísla y expone el diseño, mediantes sus correspondientes diagramas, de todo los elementos relevantes para el desarrollo del proyecto. Se atienden a detalles de bajo nivel tales como la estructura de datos complejos almacenados en la base de datos que sean necesarios manejar para una correcta integración de la nueva funcionalidad, así como los detalles de implementación más significativos. Destacar por último que en este capítulo también se trata el estado actual de la Interfaz Gráfica de Usuario desde el punto de vista de su aspecto, con el fin de determinar a posteriori donde se ubicarán los nuevos elementos visuales para las diferentes vistas en función de roles (Administrador, Usuario, etc.) 3.1.2 Estudio de modelo de negocio El modelo de negocio comprende el núcleo de la aplicación, el backend de la misma. Está formado por el modelo de datos que mantiene la información a ser mantenida y manejada. Y la lógica de negocio mediante la cual se realiza las diferentes operaciones sobre los datos. 3.1.2.1 Tecnología del modelo de negocio El modelo de negocio de la herramienta está implementado en la plataforma de programación J2EE en su versión 1.4. Esta plataforma permite desarrollar y ejecutar software de aplicaciones en el lenguaje de programación Java. Permite utilizar arquitecturas de N capas distribuidas y se apoya ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. Java EE tiene varias especificaciones de API, tales como JDBC, RMI, e-mail, JMS, Servicios Web, XML, etc Estudios previos_____________________________________________________________ 19 y define cómo coordinarlos. Java EE también configura algunas especificaciones únicas para Java EE para componentes. Estas incluyen Enterprise JavaBeans, servlets, portlets (siguiendo la especificación de Portlets Java), JavaServer Pages y varias tecnologías de servicios web. Se lista a continuación las APIs de J2EE empleadas en la intranet, con una breve descripción de cada una de ellas:  Enterprise JavaBeans: También conocidos por sus siglas EJB son una de las API que forman parte del estándar de construcción de aplicaciones empresariales J2EE. Los EJB proporcionan un modelo de componentes distribuido estándar del lado del servidor. 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í. El hecho de estar basado en componentes permite que éstos sean flexibles y sobre todo reutilizables. Existen tres tipos de EJBs: EJB de Entidad (Entity EJBs): su objetivo es encapsular los objetos del lado del servidor que almacena los datos. EJB de Sesión (Session EJBs): gestionan el flujo de la información en el servidor. Generalmente sirven a los clientes como una fachada de los servicios proporcionados por otros componentes disponibles en el servidor. Puede haber dos tipos: - Con estado (stateful): En un bean de sesión con estado, las variables de instancia del bean almacenan datos específicos obtenidos durante la conexión con el cliente. Cada bean de sesión con estado, por tanto, almacena el estado conversacional de un cliente que interactúa con el bean. Este estado conversacional se modifica conforme el cliente va realizando llamadas a los métodos de negocio del bean. El estado conversacional no se guarda cuando el cliente termina la sesión. - Sin estado (stateless). Los beans de sesión sin estado son objetos distribuidos que carecen de estado asociado permitiendo por tanto que se acceda concurrentemente. No se garantiza que los contenidos de las variables de instancia se conserven entre llamadas al método. Estudios previos_____________________________________________________________ 20 - EJB dirigidos por mensajes (Message-driven EJBs): son los únicos beans con funcionamiento asíncrono. Usando el Java Messaging System (JMS), se suscriben a un tema (topic) o a una cola (queue) y se activan al recibir un mensaje dirigido a dicho tema o cola. No requieren de su instanciación por parte del cliente.  JavaMail: implementa el protocolo SMTP, así como los distintos tipos de conexión con servidores de correo -TLS, SSL, autentificación con usuario y password, etc.  JAXP es el acrónimo de Java Api for XML Processing. API Java (definido por Sun Microsystems) sirve para la manipulación y el tratamiento de archivos XML. Los beans de entidad se emplean para el manejo de la capa de datos. Estos beans abstraen y ocultan la base de datos subyacente, en este caso es una MySql versión 6.0. Cada bean de entidad corresponde a una entidad del modelo de datos: Empleado, Roll, Proyecto, etc. Un único bean de sesión sin estado es empleado como fachada de la parte servidora de la aplicación. Este contiene todas las operaciones necesarias sobre el modelo de negocio, manejando para ello los beans de entidad, que son invocados por la parte cliente, la Interfaz gráfica de usuario. Se emplea un bean sin estado ya que el cliente web es una página web cuyo único contenido es una película Adobe Flash y se emplea para la comunicación el framework Granite Data Services (GraniteDS). Con el empleo de esta solución de integración no aplica el mantenimiento de la sesión por parte del servidor. JavaMail es empleado para el envío automatizado de emails a los empleados para notificaciones de diferente índole: aprobación de SVPs (Solicitud de vacaciones y permisos) y PAs (Partes de actividad) JAXP se emplea para el tratamiento de datos en formato XML empleados para el almacenamiento de información estructurada y para la comunicación cliente servidor. Servidor de aplicaciones La capa correspondiente al par servidor de la intranet se ejecuta, como es lógico, en el contexto de un servidor de aplicaciones. Estudios previos_____________________________________________________________ 21 Servidor de aplicaciones es un servidor en una red de computadores que ejecuta ciertas aplicaciones. Usualmente se trata de un dispositivo de software que proporciona servicios de aplicación a las computadoras cliente. Un servidor de aplicaciones generalmente gestiona la mayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a los datos de la aplicación. Los principales beneficios de la aplicación de la tecnología de servidores de aplicación son la centralización y la disminución de la complejidad en el desarrollo de aplicaciones. [7] En este caso el servidor de aplicaciones es el JBoss en su versión 4.2.2.GA. Base de datos Los datos almacenados mediante el empleo de EJB de entidad en el contexto del Servidor de aplicaciones son persistidos, mediante el uso de la librería Hibernate, en un servidor de base de datos. La base de datos, tablas, atributos, etc. quedan definidos a partir de la propia estructura que conforman estas entidades y sus anotaciones de Hibernate. El “data source”, desplegado en el directorio deploy del Servidor de aplicaciones, y referenciado mediante JNDI por el archivo de configuración ubicado en el directorio META-INF de la aplicación, contiene el resto de datos para la adecuada configuración de Hibernate, para una correcta interacción con la base de datos. Esta es la forma habitual de configurar y estructurar los proyectos que emplean J2EE y la librería en cuestión. En este caso el Servidor de Base de datos empleada es MySQL Server 5.1 y la librerías de Hibernate empleadas son las incluidas por defecto en el Servidor JBoss que se utiliza. Seguridad La autenticación de usuarios en la intranet se realiza mediante JAAS (Java Authentication and Authorization Service). JAAS es una interfaz que permite a las aplicaciones Java acceder a servicios de control de autenticación y acceso. Apareció como paquete opcional en la versión 1.3 y lleva siendo parte del estándar desde la versión 1.4. La autorización de accesos a diferentes elementos y procesos en función de los roles asociado a los usuarios no está implementada mediante JAAS. Estudios previos_____________________________________________________________ 22 3.1.2.2 Diseño del modelo de negocio Este subcapítulo está compuesto por la información relativa al diseño de la Intranet, partiendo del estado en el momento de comienzo del desarrollo del proyecto. La mayoría de esta información, compuesta por diagramas y la explicación de los mismo, o era inexistente o no estaba actualizada, por lo que ha requerido un importante trabajo de reingeniería. Se muestra en la Figura 3 el subconjunto del modelo de datos de la intranet, que serán necesario conocer para el desarrollo del nuevo módulo, mediante el correspondiente diagrama de Clases. En este se especifican tanto las clases del modelo que tendrán alguna relación con las nuevas clases a añadir o aquellas que son necesario manejar para la ejecución de la nueva funcionalidad. Se incluyen vacías las clases que no son relevantes en el estudio que nos ocupa, a partir de las cuales se extiende el modelo de datos total original. Y la clase Empleado solo contiene los atributos más representativos y las relaciones relevantes. En este se puede observar como existen dos subconjuntos de clases que parten de la clase Usuario, que mantiene todos los usuarios de la intranet con su login y password para el acceso. Por un lado las clases (Rol, Rol_has_Accion, Acciones y Modulos) que, como ya se explicará más adelante son necesarias conocer y modificar su contenido para la gestión correcta de la inclusión del nuevo módulo en la GUI. Y por otra parte las clases: Empleado, ParteVacacionesPermisos, ParteVacacacionesPermisosEstado y Calendario, con otras que las relacionan, que son necesario conocer para la realización de los nuevos procesos de la lógica de negocio. Sobre todo los encaminados a determina el carácter de los días (hábil, no hábil, festivo, vacaciones. etc) para cada empleado. Estudios previos_____________________________________________________________ 23 Figura 3. Diagrama de clases del modelo de datos de la Intranet corporativa. Estudios previos_____________________________________________________________ 24 3.1.2.3 Configuración del Servidor de aplicaciones y la base de datos. El Servidor de aplicaciones JBoss 4.2.2.GA mantiene su configuración por defecto, la única modificación es la inclusión de algunas librerías de Java en el directorio jboss-4.2.2.GA-icef\server\default\lib para la realización de diferentes funciones:  jasypt-1.3.jar: Para la encriptación y desencriptación de datos en la base de datos.  backport-util-concurrent.jar, cfgatewayadapter.jar, commons-codec-1.3.jar, commons-httpclient-3.0.1.jar, commons-logging.jar, concurrent.jar, flex-ejbfactory.jar, flex-messaging-common.jar, flex-messaging-core.jar, flexmessaging-opt.jar, flex-messaging-proxy.jar, flex-messaging-remoting.jar, xalan.jar: Para la comunicación con el par cliente desarrollado en Flex, mediante el empleo de GraniteDS, y descargadas como parte de esta solución desde la página oficial. Para la configuración de acceso a la base de datos se ha configurado 2 ficheros. El primero de ellos es /META-INF/Persistemce.xml donde se especifica, entre otras cosas, mediante un identificador JNDI el “data source” desplegado: Por otro lado el jboss-4.2.2.GA-icef\server\default\deploy\ mysqlds.xml donde se almacenan datos para la conexión a la base de datos. Entre estos datos destacan, ubicación del servidor de base de datos, que incluye el nombre del servidor, <?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0"> <persistence-unit name="IntranetEF" transaction-type="JTA"> <jta-data-source>java:/MySqlDS</jta-data-source> <properties> <property name="hibernate.hbm2ddl.auto" value="update"/> </properties> </persistence-unit> </persistence> Estudios previos_____________________________________________________________ 31 normalmente implica una comunicación con un servidor remoto, a través del Business Delegate. La interfaz IResponder, que también está implementada por la clase de comandos, incluye los métodos onResult y onFault para manejar las respuestas devueltas por el servicio remoto invocado. 3.1.2.4 Compilación y despliegue. La compilación y despliegue de la interfaz gráfica se realiza con el propio entorno de desarrollo, incluyendo como parámetros de compilación: -services" C:\proyectos\as\jboss-4.2.2.GAicef\server\default\ deploy\intranetEF.ear\intranet.war\WEB-INF\flex\services-config.xml" -context-root "." -locale en_US El directorio WEB-INF\flex contiene los archivos necesarios para la correcta comunicación con el servidor empleando GraniteDS. Y como salida de la misma: jboss-4.2.2.GA-icef\server\default\deploy\intranetEF.ear\intranet.war Estas configuraciones forman parte de las propiedades del proyecto Flex que constituye la Gui y se muestran ya configuradas tras la importar el proyecto con Flex Builder. El directorio flex con su contenido se puede obtener de la web oficial de GraniteDS. Los directorios intranet.war\WEB-INF deberán ser creados, tras el primer despliegue de la parte del servidor en el servidor de aplicaciones. 3.2 Sensores biométricos (Estado del arte) 3.2.1 Introducción La biometría consiste en la identificación de un individuo a través del análisis de sus características físicas o rasgos conductuales. El término se deriva de las palabras griegas "bios" de vida y "métron" de medida. [1] Los captadores biométricos son sistemas diseñados para conceder acceso a usuarios basándose en características únicas e inalterables de cada individuo que difícilmente pueden ser duplicadas, perdidas, olvidadas o robadas, pretendiendo Estudios previos_____________________________________________________________ 32 reconocer quien es el individuo, opuestamente a los sistemas de acceso más comunes basados en objetos (llaves, tarjetas RFID…) o códigos que pueden ser perdidos, olvidados, robados o descifrados. [2][3][4] Son precisamente estas características físicas o conductivas de cada individuo lo que ha impulsado el desarrollo de distintos tipos de sistemas para su identificación; desde el punto de vista conductivo es posible analizar la caligrafía o la voz de un individuo, siendo esta última donde más esfuerzos se han aplicado desde una perspectiva tecnológica. Pero sin duda alguna el desarrollo de los sistemas biométricos, centra sus esfuerzos en la identificación de las características físicas como son, por ejemplo, la Huella Dactilar, la Retina, el Iris, la Geometría de la Mano o la Cara.[3][5] 2.2.2 Funcionamiento y rendimiento El funcionamiento habitual en un Sistema Biométrico, consta de un proceso previo de registro, donde se adquieren uno o varios de los parámetros biométricos morfológicos o fisiológicos del usuario, se procesan mediante algún algoritmo numérico para finalmente ser almacenados en una base de datos con la información única para cada individuo. Posteriormente en el proceso de autentificación o identificación de un usuario, el sistema obtiene y procesa las características biométricas, las compara con las almacenadas en la base de datos y si concuerda, valida la operación. Alguno de los parámetros definidos para medir el rendimiento de un sistema biométrico son; [3][4][6] Tasa de Falso Positivo (False Acceptance Rate o FAR); es la probabilidad de que un usuario no registrado sea aceptado en cualquier caso. Mide la frecuencia con que un usuario no registrado es admitido por equívoco, actualmente el margen esta entre el 0.0001% y el 0.1%. [5] Y asume intentos pasivos del usuario. A partir del FAR se puede obtener una medida de la seguridad del sistema de verificación biométrica, según la ecuación, seguridad = (1 – FAR). Tasa de Falso Reconocimiento (False Match Rate o FMR). Es la tasa con que los usuarios no registrados son confundidos durante un proceso de comparación de características. Estudios previos_____________________________________________________________ 33 Tasa de Falso Rechazo (False Rejection Rate o FRR); es la probabilidad de que un usuario este registrado pero sea rechazado, Mide la frecuencia con que un usuario registrado es rehusado. Comercialmente su valor varía entre el 0.00066% y el 1%.[5] Conociendo FRR, se puede precisar la conveniencia de un sistema biométrico, de acuerdo con la ecuación, conveniencia = (1 – FRR). Conforme aumenta FRR menos conveniente resulta el sistema por el alto número acceso denegado de forma errónea. Tasa de Falso Negativo (False NonMatch Rate o FNMR). Es la tasa con que los usuarios registrados no son identificados durante un proceso de comparación de características. Es común confundir los conceptos FAR con FMR y FRR con FNMR, sin embargo la principal diferencia consiste en la no contabilización de los rechazos producidos debidos a la baja calidad de la imagen o imposibilidad de adquirirla cuando se trata de FMR respecto a FAR o de FNMR hacia FRR. Tasa de Fallo de Registro (Failure-to-enroll Rate, FTR o FER); incapacidad del sistema biométrico de generar un registro fiable de un usuario. Tasa de Error Igual (Equal Error Rate, EER); es la intersección entre FAR y FRR siendo una de las medidas más usada para determinar el umbral de calidad del sistema biométrico, cuando los errores de aceptación y rechazo son iguales, el umbral se establece en el 50%. Cuanto más bajo es EER el sistema es más fiable. Estos umbrales deben ser ajustados de acuerdo con la garantía requerida. 3.2.3 Procesos de Autentificación e Identificación Biométrica En el control de accesos mediante biometría existe una fase de verificación, durante la cual, el dato biométrico o plantilla, ya adquirido por el sistema, es cotejado con el que está siendo sometido a análisis, intentando confirmar la identidad declarada de un individuo, al confrontar la muestra suministrada con una o más plantillas registradas con anterioridad siguiendo uno de los dos procesos fundamentales, el de Autentificación o el de Identificación. [3][4] El Proceso de Autentificación (o Verificación), también conocido como UnoPara-Uno (1:1), se basa en la comparación de los rasgos biométricos con los de un patrón ya guardado. El objetivo es confirmar la identidad del individuo. Estudios previos_____________________________________________________________ 34 Los sistemas automáticos para verificación se denominan AFAS. El proceso de Identificación o Uno-Para-Muchos (1:N), compara los rasgos biométricos con los de un conjunto de plantillas residentes en la base de datos. Pretende identificar al individuo. Cuando se conoce que el individuo a identificar está dentro de la base de datos, se dice que la identificación es “de grupo cerrado”. En identificación "de grupo abierto”, también llamada “lista de vigilancia”, no existe garantía de que el individuo sea parte de la base de datos. El sistema debe determinar si el individuo es parte de la base de datos y en caso afirmativo proporcionar su identidad (AFIS). Debido al número de comparaciones y procesamiento que debe llevarse a cabo en el proceso de Identificación, resulta más rápido el proceso de Autentificación, especialmente conforme va aumentando N en la Identificación. 3.2.4 Modalidades biométricas No es el propósito de esta memoria hacer un recorrido exhaustivo por todas las modalidades biométricas existentes. El alcance de este apartado se limitará a recoger en una tabla comparativa (Tabla 2), [5] las características más importantes a valorar para los sistemas biométricos más comunes, que permitirá la selección de una modalidad en función de las necesidades del proyecto. Estudios previos_____________________________________________________________ 35 Ojo(Iris) Ojo(Retina) Huellas Dactilares Geometría de la mano Escritura y Firma Vista Cara Fiabilidad Muy Alta Muy Alta Alta Alta Media Alta Alta Facilidad de Uso Media Baja Alta Alta Alta Alta Alta Prevención de Ataques Muy Alta Muy Alta Alta Alta Media Media Media Aceptación Media Baja Alta Alta Muy Alta Alta Muy Alta Estabilidad Alta Alta Alta Media Baja Media Media Costo Muy Alto Alto Bajo Bajo Alto Medio Medio Incidencias Enfermedades Oculares, Luz Enfermedades Oculares, Gafas Ausencia de miembros Edad, Ausencia Miembros Edad, analfabetismo, cambios Ruido, Afeccio nes Edad, pelo Tamaño Plantilla (byte) 512 96 250-1000 20 11000-3000 1000020000 84-1300 Tabla 2 Análisis de requisitos____________________________________________________________ 36 4. Análisis de requisitos 4.1 Requisitos de usuario Se describe a continuación los requisitos de usuario obtenidos de entrevistas con diferentes usuarios de la intranet y Jefes de Departamentos. El módulo de control de horarios será parte de la intranet corporativa y será accesible desde la página principal de esta para los roles Usuario, Jefe de UOI y Administrador. Usuarios con privilegios (roles Jefe de UOI y Administrador) podrán cursar el alta, la baja y modificación de los empleados registrados en la intranet en el módulo de control y gestión de horarios. Para dar de alta a un empelado será necesario asignarle una jornada laboral que también podrá ser creada por usuarios con privilegios. En la creación de una jornada laboral se permitirá definir hasta dos horarios diferentes a lo largo de un año, normal e intensivo, que podrán ser asignados de manera única a los diferentes meses que componen el año. Para cada uno de los horarios de define una hora límite máximo de inicio y una hora límite mínimo de finalización de la jornada para cada día de la semana, y un número mínimo de horas semanales. El alta de un empleado permitirá la asignación de un pin de manera opcional, que se solicitara en los procesos de identificación de entrada a la oficina. El alta de un empleado permitirá la asignación de un responsable directo para la notificación de incidencias por incumplimiento de horario. El alta de un empleado permitirá la asignación de una excepción de incidencias. Al empleado en cuestión no se le asignaran incidencias provocadas por el incumplimiento de horario. El alta de un empleado permitirá la asignación de una excepción de notificación. Al empleado en cuestión se le asignaran incidencias provocadas por el incumplimiento de horario, pero no se notificaran a su responsable directo. La captura inicial de huellas para el alta de usuarios en el módulo se realizará en el mismo terminal que los marcajes diarios. Un marcaje es la identificación en el terminal Análisis de requisitos____________________________________________________________ 37 mediante huella dactilar, de un determinado usuario, realizada a una determinada hora. La información del marcaje será almacenada en el sistema para su control y gestión. Los usuarios podrán realizar sus marcajes diarios en las diferentes estancias que componente las oficinas de Edosoft, aunque en primera instancia se asume que se realizará solo en la oficina principal. Los marcajes diarios podrán ser de entrada o de salida, indicando de este modo si se está comenzando o finalizando la jornada laboral y pudiendo pedir pin de acceso en caso de que sea un marcaje de entrada. Los marcajes de entrada solo podrán realizarse en una franja horaria comprendida entre las 6:30 y las 24:00. Si fuera posible los marcajes producidos fuera de esta franja horaria deberían ser descartados por el terminal directamente. Si no existiera esa posibilidad se crearía una incidencia con los marcajes anteriores a esa hora. La posibilidad de realizar marcajes de entrada y la salida puede provocar que el orden y/o el número de marcajes no sean los correctos. El número ideal de marcajes por día son dos, primero uno de entrada y por ultimo uno de salida. La Tabla 3 muestra el resto de casos contemplados, si se considera un día con marcajes válidos, y en este caso que marcaje de entrada y de salida son utilizados para el cómputo de horas del día. El superíndice n representa agrupaciones de marcajes de salida o de entrada desde 1 hasta n. Los puntos suspensivos indican cualquier sucesión de marcajes de entrada y salida. Orden de marcajes Marcajes validos Entra y salida seleccionada Salidan, Entradan No - Entradan, Salidan Si Primer marcaje de entrada y primero de salida. Salidan, Entradan, Salidan Si Primer marcaje de entrada y primero de salida después de una entrada. Entradan, Salidan,, Entradan Si Primer marcaje de entrada y primero de salida. Salidan, Entradan, Salidan,… Si Primer marcaje de entrada y primero de salida después de una entrada. Entradan, Salidan, Entradan,… Si Primer marcaje de entrada y primero de salida. Tabla 3 Diariamente se analizara los marcajes de cada empelado registrando una incidencia y enviando una notificación por correo según los diferentes casos previstos:  No existe ningún marcaje, el día es hábil según el calendario laboral en vigor y el empleado no tiene aprobado vacaciones o permiso para ese día.  Existe un marcaje de entrada pero no de salida. Las horas computadas ese día serán 0. Análisis de requisitos____________________________________________________________ 38  El marcaje de entrada tiene hora posterior al límite de entrada especificado por la jornada laboral para el mes en cuestión.  El marcaje de salida tiene hora anterior al límite de salida especificado por la jornada laboral para el mes en cuestión.  El marcaje de entrada tiene hora posterior al límite de entrada especificado por la jornada laboral y el marcaje de salida tiene hora anterior al límite de salida especificado por la jornada laboral.  Existe marcaje de entrada y/o de salida y el día no es hábil según el calendario laboral en vigor o el empleado tiene aprobado vacaciones o permiso para ese día. En este caso el número de horas será computado Como ya se ha advertido la incidencia se creara si el usuario no tiene excepción de control asignada y se enviara una notificación por correo electrónico a su supervisor si no tiene una excepción de notificación en su perfil de usuario. El último día de la semana se analizaran las horas computadas a lo largo de toda la semana creando incidencias y enviando notificaciones si las horas totales son menores que las especificadas en la jornada laboral para el mes en cuestión. El número máximo de horas de una jornada laboral de jornada continua es de 7 horas. Para el cálculo del número de horas de cada día se restará una hora automáticamente correspondiente a la hora de comer si el número de horas de dicho día es mayor de 7 horas y 15 minutos. Esta resta no se realizará durante el periodo en que la jornada laboral intensiva está en vigor, aunque se supere el tiempo indicado. Los usuarios con privilegios podrán acceder a la información de marcajes, cálculo de horas semanales, e incidencias de todos los empleados del sistema. La información se deberá mostrar de manera apropiada incluyendo graficas que faciliten la comprensión y análisis de los datos. Los usuarios sin privilegios (rol Usuario) podrán acceder únicamente a información relativa a sus propios marcajes e incidencias. Los usuarios con privilegios dispondrán de una operación de verificación de la existencia de inconsistencia entre los datos almacenados por la aplicación y los almacenados por cada uno de los terminales biométricos. Entre las diferentes inconsistencias buscadas en este proceso se encuentran: Análisis de requisitos____________________________________________________________ 39  Usuario dado de alta en el sistema pero no existente en uno o varios terminales.  Usuario de baja en el sistema pero existente en uno o varios terminales.  Usuario dado de alta tanto en el sistema como en todos los terminales, pero con datos diferentes de PIN. Los usuarios con privilegios dispondrán de una operación de subsanación para reparar las inconsistencias encontradas durante el proceso de verificación. Los usuarios con privilegios dispondrán de una operación de inserción masiva de los usuarios del sistema en un terminal. Pensado para la inclusión de terminales nuevos en el sistema. Los usuarios con privilegios podrán acceder a la información de configuración de los terminales (MAC, dirección IP, mascara de red, DHCP activado) y de operatividad (número de marcajes totales que admite y número de marcajes almacenados) Los usuarios con privilegios podrán modificar determinados parámetros de configuración de los terminales de alta en el sistema. Los usuarios con privilegios podrán realizar algunas operaciones sobre los terminales:  Verificación de la conexión con los terminales.  Borrado de los marcajes almacenados en los terminales.  Obtención de número de marcajes almacenados en los terminales. 4.2 Requisitos del software El módulo de control de horarios como parte de la intranet corporativa y será accesible desde la barra principal de menús mediante un nuevo elemento y desde la botonera, mediante la inclusión de un nuevo icono. Podrá mantener un mínimo de 500 usuarios dados de alta y sin límites de marcajes. Mantendrá y gestionará la conexión con múltiples terminales. Este manejo de la comunicación incluye conexión inicial, reintento de conexión tras pérdidas de la misma, y sincronización de información de marcajes tras la recuperación. Análisis de requisitos____________________________________________________________ 40 Los terminales podrán funcionar de manera autónoma (modo off-line). Esto permite al terminal realizar autenticaciones aunque no esté conectado al servidor, pero será necesario realizar de manera automática la sincronización de marcajes entre el servidor y los terminales al volver a modo on-line. A continuación se exponen los requisitos funcionales mediante los diagramas de casos de uso para cada uno de los roles definidos en la intranet. Se muestra en la Figura 5 el diagrama UML los casos de uso para un usuario sin privilegios del sistema que corresponde al rol Usuario. Figura 5. Diagrama de casos de uso usuario genérico. Proceso de selección del terminal biométrico________________________________________ 47 5.2 Selección y análisis del terminal modelo Kreta 3 de Kimaldi La selección del terminal biométrico se ha realizado atendiendo varios factores. El primero de ellos, y fundamental, es que sea cumpla los requisitos del hardware. De entre todas las opciones posibles se tendrá en cuenta una serie de aspectos. Se primará que sea ofertado por un distribuidor nacional de garantía, con servicio técnico para posibles reparaciones y soporte técnico para las cuestiones de diferente índole, funcionamiento, configuración, que surjan en el transcurso del proyecto. Dicho distribuidor debería ser también fabricante o ensamblador de sus propias soluciones, con un amplio conocimiento de los productos que ofrece. Con una línea de productos completa y coherente, en continua evolución, pero que ofertando nuevos modelos de terminales no pierda la compatibilidad hacia atrás. Esto nos permitirá ampliar en futuro el sistema de control y gestión de horarios mediante la adquisición de nuevos equipos sin que haya que realizar enormes modificaciones en interfaces y funcionamiento debido a la adquisición de un nuevo modelo, al estar el anterior descatalogado. Se valorará la calidad de la calidad de la documentación del sistema biométrico, manual de instrucciones, guía de instalación, etc. Además de la aportación de proyectos de ejempló que ilustren de forma practica el manejo del terminal, así como programas para una simple configuración inicial. Kimaldi es un referente en el mercado de en equipos de identificación y control de personas que cumple todos los requisitos exigidos para proveer el sistema biométrico del desarrollo que nos ocupa. El momento del proceso de selección y adquisición del terminal Kimadi ofertaba diferentes líneas de productos optando finalmente por los terminales Kreta 3. Los terminales Kreta 3 permiten una cierta customización para adaptarse a las necesidades del cliente, pudiendo seleccionar entre diferentes capacidades de usuarios, diversos modelos de carcasas, varias interfaces de comunicación, etc. El terminal de Ref 01KRT3ESB11F1X1 (Figura 8) dispone de un sensor biométrico de huella dactilar y un lector de proximidad de tarjetas RFID, con vistas a futuros desarrollos, y presenta las siguientes características: Proceso de selección del terminal biométrico________________________________________ 48  Biometría mediante el sensor FIM20: a) Identificación del usuario por reconocimiento de huella digital 1:N hasta 4.000 huellas y 15.000 autenticaciones. También permite realizar la verificación 1:1 y 1:Subgrupo, combinando la lectura biométrica con la introducción de un password o lectura RFID. Esto reduce el tiempo de verificación, ya que con sólo poner el dedo y pulsar una tecla simplemente busca en un subgrupo total de huellas almacenadas. b) Tasa de identificación muy elevada: FAR: 1/100.000 y FRR: 1/1.000 c) Asignación de hasta 2 dedos por usuario. d) Múltiples modos de enrolamiento de usuario: local inmediato, local diferido o remoto. e) Módulo biométrico de alta calidad, con un potente algoritmo de matching y un sensor óptico de elevada dureza (7 Moh).  RFID: Identificación del usuario mediante radiofrecuencia a través de un lector de proximidad de baja frecuencia 125kHz (EM, Unique, Q5)  Conectividad a) Ethernet: Puerto Ethernet TCP/IP,UDP b) RS‐232: Puerto RS‐232 para conectividad de host.  Otras características: a) Función Auto on: detecta el dedo en el sensor. b) Permite el funcionamiento de terminal en modo off-line al mantener en el interior del dispositivo todos los datos necesarios para realizar la autenticación de un usuario. Los datos de los procesos de autenticación que tengan lugar mientras el terminal esté operando en modo off-line podrán ser accedidos al recuperar la conectividad. c) Caja office con teclado matricial de 4 filas x 4 columnas para la inserción de PIN y Display LCD, 20x2 caracteres para la muestra de mensajes. d) 2 años de garantía.  Documentación: a) Manual Módulo Kreta3 V 1.01: manual de especificaciones y funcionamiento del Módulo Kreta3, dedicado a Control de Presencia y Control de Acceso Proceso de selección del terminal biométrico________________________________________ 49 b) Guía rápida de instalación V 1.0: Muestra los primeros pasos con el terminal Kreta 3. Instalación y configuración inicial básica con la aplicación Servicio de localización. Además incluye un breve manual sobre el empleo del programa de ejemplo Demo kreta 3. c) Manual control SLK: Manual operativo del Servicio de Localización Kimaldi.  Programas complementarios: a) Demo kreta3: Aplicación de ejemplo de funcionamiento del terminal biométrico, con un alto componente didáctico. Para cada operación sobre el terminal muestra el contenido de la trama de datos que se envía al mismo. b) Servicio de localización: Aplicación que permite escanear una subred, en busca de dispositivos Kimaldi basados en la plataforma ID32 (por ejemplo, Kreta3 o BioMax2) conectados a ella. Una vez conectada permite la configuración de sus parámetros de conexión (IP, mascara de red, DHCP activado, etc). El material adquirido se compone del terminal biométrico Kreta 3 (Figura 8), un adaptador de corriente, un par de tarjetas RFID para pruebas y un CD-Rom con Manuales, herramientas y software Demo (Figura 7) Figura 8. Foto del terminal biometrico Kreta 3 Figura 7. Complementos adjuntos al terminal. Diseño________________________________________________________________________ 50 6. Diseño La definición del diseño está subdividida en dos capas fundamentales correspondientes a una aplicación cliente servidor, tal y como se ha comentado en otros capítulos de esta memoria. Así pues, por una parte se encuentra el diseño del modelo de negocio, donde se amplía el diagrama de clases correspondiente al modelo de datos para mantener las nuevas clases necesarias. Además se incluye un pequeño diagrama de componentes para mostrar la composición del modelo de negocios, y su relación con el terminal biométrico. Y por último una seria de diagramas de secuencia, para los casos de uso más significativos, en donde se muestra el conjunto de llamadas a métodos de clases que tienen lugar. El diseño de la interfaz gráfica viene claramente determinado por la utilización del framework Cairgorm en la misma. Es por eso que para la definición del mismo será suficiente con mostrar el modelo de datos y un diagrama de secuencia que muestre el conjunto de llamadas que se producen entre las diferentes capas (Modelo, Vista, Controlador) para un caso de uso representativo, mediante la utilización de Eventos, Comandos y Bussines Delegates, tal y como define el framework. Se trata pues de la especificación para un caso particular del diagrama expuesto en la Figura 4. 6.1 Diseño del nuevo módulo en la lógica de negocio Apoyados en diferentes diagramas UML y el desarrollo de los mismos mediantes las pertinentes explicaciones se expone en este capítulo el diseño de la lógica de negocio para la nueva funcionalidad a implementar. Primeramente se muestra en la Figura 9 el modelo de datos para el componente de Control de horario. Este solo mantiene la clase Empleado como enlace al modelo de datos original del diagrama de la Figura 3. La clase EmpleadoTerminalK3 representa a la clase de los empleados dados de alta en el sistema de control y gestión de horarios, que mediante una relación 1 a 1 está asociado con la clase Empleado del modelo original. De esta clase parten relaciones con el resto de las clases del modelo. De los atributos pertenecientes a esta clase se listan y Diseño________________________________________________________________________ 51 explican tan solo aquellos que no resultan triviales de entender a tenor de su nombre y el análisis previo:  códigoSemana: Hace referencia al código que identifica un horario semanal que tendrá asignado un empleado. Por defecto solo habrá almacenado un único horario semanal en todos los terminales, que permite fichar a cualquier hora de la semana, que será el utilizado por todos los empleados del sistema.  codigoIntegridad: Mantiene el estado del empleado en cada uno de los terminales del sistema mediante un código determinado. Empleado para las operaciones de verificación de la integridad y subsanación de la misma.  minucias: Mantiene los datos de la minucia de huellas para el empleado en cuestión. Dos minucias consecutivas son almacenadas en 400 bytes de datos.  estadoOperativo: Mantiene los estados del empleado en el sistema tras un alta o baja (INSERTADO o ELIMINADO). Este campo también puede mantener estados intermedios de un proceso de alta o baja sin finalizar, por ejemplo por un error en la captura de la huella, un fallo en la inserción o eliminación de información de dichos empleados en los terminales, etc. Se mantiene este estado intermedio con el fin de poder continuar con posterioridad con dicha operación.  estadoOperación: Mantiene el estado de una operación (Modificación, Verificación o Subsanación) sobre el empleado en cuestión, con propósito de comprobación, verificación y muestra de logs. Diseño________________________________________________________________________ 52 Figura 9. Diagrama de clases del modelo de datos del modulo de control y gestión de horarios. Diseño________________________________________________________________________ 53 La clase JornadaLaboral contiene especificación de la jornada laboral que se le aplica a un empleado dado de alta en el sistema de control y gestión de horarios. El atributo jornadaLaboralXML mantiene dicha especificación mediante lenguaje XML. Se muestra a continuación un ejemplo del mismo. Atributo jornadaLaboralXML de la clase JornadaLaboral La clase Incidencia mantiene información sobre él incumplimiento de la jornada laboral, la falta de marcajes o cualquier otro tipo de eventualidad, para un empleado. El atributo codigoIncidencia almacena el tipo de incidencia que se ha producido con un código al efecto. <jornadaLaboral> <jornadaOrdinaria> <meses>Enero;Febrero;Marzo;Abril;Mayo;Junio;Septiembre; Octubre;Noviembre;Diciembre</meses> <lunes>0900;1500</lunes> <martes>0900;1500</martes> <miercoles>0900;1500</miercoles> <jueves>0900;1500</jueves> <viernes>0900;1500</viernes> <sabado></sabado> <domingo></domingo> <horas>41</horas> </jornadaOrdinaria> <jornadaExtraordinaria> <meses>Julio;Agosto</meses> <lunes>0900;1400</lunes> <martes>0900;1400</martes> <miercoles>0900;1400</miercoles> <jueves>0900;1400</jueves> <viernes>0900;1330</viernes> <sabado></sabado> <domingo></domingo> <horas>35</horas> </jornadaExtraordinaria> </jornadaLaboral> Diseño________________________________________________________________________ 54 Código Descripción 001 Excedida la hora de entrada máxima fijada 002 Incumplida la hora de salida mínima fijada 003 Incumplida la hora de entrada mínima fijada 004 Excedida hora de salida máxima fijada 005 Fichaje de entrada no debido (Fichaje en un día festivo, vacaciones o definido como no laborable) 006 Sin fichaje de salida (Solo presente el fichaje de entrada) 007 Sin fichaje (Falta fichaje de entrada y salida en un día laborable) 008 Incumplido el cómputo de horas semanales definidas. La clase Marcaje mantiene información sobre cada uno de los fichajes que realiza un empleado dado de alta en el sistema. De los atributos que tiene esta clase se exponen con su pertinente definición, todos aquellos que no resultan triviales de deducir mediante su nombre y el análisis previo:  codigoEvento: Determina la validez de un marcaje, siendo el valor de marcaje correcto el “33” para los fichajes de entrada y el valor“31” para las incidencias de salida. La siguiente tabla muestra códigos para marcajes denegados: Código Descripción 38 EVENTO ACCESO PRESENCIA DENEGADO POR HORARIO 36 EVENTO ACCESO PRESENCIA DENEGADO POR PIN 35 EVENTO ACCESO PRESENCIA DENEGADO POR ACCESO  incidencia: Determina si es un marcaje de entrada con el valor “01” o de salida con el valor “02”  valido: Determina si un marcaje de entrada o salida en considerado valido y será utilizado para el computo de horas de un determinado día. La validez dependerá del código de evento, de la incidencia y del orden de los marcajes (ver Tabla 3) La clase TerminalKreta3 mantiene información de los terminales conectados al sistema. Esta clase está relacionada con la clase EmpleadoTerminalK3 a través de la clase AltaEnT3 para conformar una relación m a m. De esta manera un empeadoTK3 se Diseño________________________________________________________________________ 55 encuentra dado de alta en todos los terminales conectados y en un determinado terminal estarán todos los empleados dados de alta en el sistema. De los atributos que tiene esta clase se explican aquellos que no resultan simples de entender con el dato de su nombre y mediante el análisis previo:  terminalBloqueado: Mantiene información cuando el terminal está bloqueado debido a alguna operación en curso. Cuando el terminal está bloqueado su valor será ‘true’, y no se puede iniciar nunca otra operación mientras tanto, en caso contrario su valor será ‘false’.  modoOnlineActivado: Determina el modo de funcionamiento del terminal. Con modo online activo, los marcajes serán enviados por el terminal hacia la intranet cuando tienen lugar, en caso contrario tan solo se almacenan en el terminal. Por defecto y el modo común de funcionamiento será con el modo online activado.  configuraciónHoraria: Determina el rango de horas en un día que el terminal permite marcajes. Su valor será fijo, y permitirá marcajes a cualquier hora del día  configuraciónSemanal: Determina los días de la semana que el terminal permite marcajes dentro de la configuración horaria. Su valor fijo será de lunes a domingo. Con la configuración horaria se admite la captura de marcajes a cualquier hora y fecha, quedando la valoración de su validez bajo en funcionamiento de la lógica de negocio. Una vez concluido con el modelo de datos del servidor, se muestra un diagrama de componentes (Figura 10) donde quedan diferenciados los componentes principales de la lógica de negocio. Diseño________________________________________________________________________ 56 Figura 10. Diagrama de componentes de la lógica de negocio. Diseño________________________________________________________________________ 63 En la Figura 15 y Figura 16 se expone el diagrama de secuencia correspondiente a la lectura inicial de los datos de configuración de terminal, tras el arranque del servidor de aplicaciones. La Figura 16 es la continuación de la Figura 15 por el punto 5. La trama enviada por el handshake es una operación de ACK cuya respuesta iniciará el proceso de configuración. Los bucles del diagrama de la Figura 15 y su tratamiento mediante la llamada a processMassage() se repiten mientras queden pendientes peticiones de los diferentes parámetros de configuración. En la Figura 16, en el punto 5, comienza el tratamiento de la respuesta del ACK la cual provoca la petición del primer parámetro mediante el método getConfiguración(), es decir es la primera invocación del método processMassage() en el proceso de configuración inicial. A partir del punto 6 representa el tratamiento de la segunda llamada y subsiguientes, en donde se persiste el dato pedido en la iteración anterior y se solicita el siguiente a través del método getConfiguración(). En el procesamiento del último parámetro de configuración, no se realizará ninguna petición más. Lista de los diferentes parámetros solicitados en el proceso de arranque del servidor:  Dirección MAC  IP Terminal  IP Gateway  Máscara de red  DHCP  IP Remota  Puerto remoto Diseño________________________________________________________________________ 64 Figura 15. Diagrama de secuencia lectura/escritura de configuración del terminal durante el aranque del servidor (1ª parte) Diseño________________________________________________________________________ 65 Figura 16. Diagrama de secuencia lectura/escritura de configuración del terminal durante el aranque del servidor (2ª parte) Diseño________________________________________________________________________ 66 6.2 Diseño del nuevo componente de interfaz El modelo de datos mantenido mediante el ModelLocator está formado por clases VO de contenido muy similar al modelo de datos de la lógica de negocio. Este modelo está orientado a la representación visual de la información en la Interfaz Gráfica por lo que contendrá además de un subconjunto de datos provenientes del servidor datos calculados a partir de estos. Se muestra en la Figura 18 el diagrama de clases que constituye el modelo de datos para un usuario. En la Figura 16 se exponen un diagrama de secuencia de uno de los casos más significativos, Alta de usuario. De esta manera junto con el diagrama de Alta de usuario del subcapítulo anterior se tendrá una visión completa de la secuencia de ejecución desde que el Administrador del sistema comienza con esta operación hasta que finaliza. El diagrama comienza con la activación del evento click del botón Aceptar de la ventana de altas de empleados en el sistema. En ese momento se desencadena la sucesión de llamadas que tiene como resultado la llamada al método de fachada del servidor correspondiente. Con el tratamiento del resultado de esta llamada desde el comando que la invoca, mostrando una ventana con el resultado inicial de la operación. Aquí concluye la parte síncrona del proceso. A continuación el punto 2 del diagrama indica la llegada y tratamiento del evento de alta en terminal que llega por mensajería al topic de JMS, informando al usuario de la evolución del proceso mediante la ventana lanzada durante la secuencia que parte del punto 1. El punto 2 se ejecutará tantas veces como terminales biométricos conectados al sistema haya. Finalmente a partir del punto 3 se muestra la secuencia de llamadas para el tratamiento del último evento recibido mediante el sistema de mensajería y por el cual se da por concluido el proceso de Alta de usuario mostrando el resultado pertinente mediante la ventana lanzada durante la secuencia que parte del punto 1. Diseño________________________________________________________________________ 67 Figura 17. Diagrama de secuencia Alta usuario. Diseño________________________________________________________________________ 68 Figura 18. Diagrama de clases del modelos de datos mantenido en el cliente gráfico. Diseño________________________________________________________________________ 69 Finalmente se exponen algunos prototipos de las diferentes pantallas que compone la interfaz gráfica indicando donde se ubican los diferentes elementos tanto para la vista de gestor como para la de usuario sin privilegios. Prototipos para el roll gestor. La Figura 19 contiene un esquemático de la GUI de la intranet corporativa de Edosoft y en particular el prototipo del contenido del área de visualización para el módulo de control y gestión de horarios, que se encuentra bajo la barra de menús. La cual está compuesta por una botonera contextual, un TabNavigator con diferentes pestañas y un área de visualización de dados en la parte derecha. En este prototipo se muestra el contenido de la pestaña Empleados, un DataGrid donde aparecen todos los empleados dados de alta en la intranet, y la información relativa al control de horario de cada uno, si han sido dados de alta en el sistema. Además se muestra la ventana emergente empleada para el Alta y Modificación de datos de empleados en módulo. La Figura 20 muestra la misma pantalla que la figura anterior, pero con varios usuarios dados de alta en el sistema de gestión y control horaria. En el dataGrid aparece la información del perfil de usuario, y en la parte derecha un Canvas con un TabNavigator que contendrá en cada pestaña información de Marcajes e incidencias para cada usuario seleccionado en el Datagrid principal. La Figura 21 muestra el contenido de cada una de estas pestañas. La Figura 22 y Figura 23 expone los prototipos para la gestión de Jornadas laborales, la ventana emergente para su creación o modificación, la botonera contextual, el contenido de la pestaña Jornadas Laborales, compuesto por la visualización de los datos que constituyen una jornada laboral el parte derecha de visualización y un DataGrid en la parte izquierda que contiene todas las Jornadas Laborales creadas en el sistema. Por último la Figura 24 presenta el contenido de la pestaña Terminales Kreta 3 que contiene un DataGrid con información de todos los terminales conectados al sistema, así como su botonera relacionada para realizar distintas operaciones sobre los diferentes terminales. Diseño________________________________________________________________________ 70 Figura 19. Prototipo de interfaz gráfica del modulo de control y gestión de horarios I Diseño________________________________________________________________________ 71 Figura 20. . Prototipo de interfaz gráfica del modulo de control y gestión de horarios II Diseño________________________________________________________________________ 72 Figura 21. Prototipo de interfaz gráfica del módulo de control y gestión de horarios III Diseño________________________________________________________________________ 79 Por último se exponen un breves nociones de como interactúa el pool de conexiones en el ámbito del conector, haciendo un repaso a los métodos más significativos de las implementaciones a realizar. Clase TerminalKreta3XAResource El método sendReceivedMessageToMDB es el encargado de invocar invocar al método processMessage, definido en la interfaz TerminalKreta3Listener y desarrollado en la correspondiente implementación de la misma. Clase TerminalKreta3ResourceAdapter Mantiene los datos de conexión (direcciones IP, puertos) y descripción para todos los terminales configurados en el terminal en el archivo META-INF/ra.xml El método endpointActivation instancia los objectos de las clases TerminalKreta3Activation SpecTerminalKreta3XAResource que son mantenidos por esta clase. Para la primera asigna el Endpoint, que no es más que el listener para que pueda ser invocado el método processMessage. Con respecto a la segunda llama al método connectToTerminalKreta3 para realizar las conexiones a los terminales, previamente asigna el propio objeto de clase TerminalKreta3ResourceAdapter en esta, para poder acceder a los datos necesario para las conexiones. Clase TerminalKreta3ActivationSpec Tal y como muestra la Figura 27 mantiene el pool de conexiones a los terminales. El método connectToTerminalKreta3 crea un pool de conexiones, una por cada terminal configurado. Una vez establecida cada conexión envía un handshake consistente en una trama de askForReady. Cada conexión tiene asociado un hilo de comunicación (clase HiloComunicación) donde se realiza la conexión mediante un Socket TCP/IP (clase SocketBasico) y donde se leen las tramas recibidas por el mismo insertándolas en una cola. Y un hilo procesamiento (clase HiloProcesamiento) que lee de esta cola, que se instancia en esta clase con una implementación inline del método abstracto tratarTrama, en donde se hace una llamada al método tratarTramaLocal de esta clase. De esta manera el hilo procesamiento llama a tratarTrama para cada trama recibida, que llamara a su Diseño________________________________________________________________________ 80 vez al tratarTramaLocal, que como se verá llama a sendReceivedMessageToMDB de terminalKreta3XAResource, que finalmente invoca al listener. La conexión tiene asociada también un emisor de la clase TerminalKreta3Module, encargada del envío de tramas. Esta clase le será asignada un socket activo una vez se haya producido la conexión en el contexto del hilo de comunicación. También se asigna el objeto de la clase TerminalKreta3XAResource a partir del objeto resourceAdapter seteado previamente. Esto permitirá llamar al método sendReceivedMessageToMDB Finalmente inicia los hilos de procesamientos asociados a cada conexión encargados de procesar las tramas recibidas, para que comiencen la espera activa por tramas en el socket. El método tratarTramaLocal invoca a sendReceivedMessageToMDB de terminalKreta3XAResource encargado de invocar al listener. Clase TerminalKreta3Module Clase que hereda de SocketBasico con lo que permitirá setear un socket con conexión ya establecida con el método addActiveSocket, permitiendo el envío de tramas mediante el método enviar_datos. Este objeto es mantenido por cada conexión activa en el pool Clase TerminalKreta3ManagedConnectionFactory Mantiene una instancia de TerminalKreta3ResourceAdapter como punto de entrada para el envío de tramas a través de las conexiones. Clase TerminalKreta3ConnectionFactory La clase permite obtener objetos de clases que implementen la interfaz Connection, es decir, TerminalKreta3Connection en este caso, que se crea y se le asigna el pool de conexiones a partir del objeto de la clase TerminalKreta3ManagedConnectionFactory pasado en el constructor. El método getConnection devuelve el objeto de la clase TerminalKreta3Connection que mantiene el pool de conexiones. Diseño________________________________________________________________________ 81 El método getRecordFactory devuelve el objeto de la clase RecordFactory que permite la creación de MappedRecord. Este objeto será accesible desde el código mediante jndi y es el primer punto de acceso al conector. Clase TerminalKreta3Connection Mantiene el pool de conexiones que es seteado mediante el método setConnectionPull. El método createInteraction, instancia y retorna un objeto de la clase TerminalKreta3Interaction con el pool de conexiones pasado en el constructor, que será utilizado para el envío de tramas desde el código. Clase TerminalKreta3Interaction Es el último punto de entrada al conector desde el código El método execute recibe los datos mediante un objeto de la clase Record, que contiene información sobre la trama a enviar y sobre la conexión a utilizar, y se encarga de enviarlo empleando el pool. Clase TerminalKreta3MappedRecord Clase utilizada para contener la información de un determinado envío de datos mediante el conector. Además contiene información para la composición de tramas de órdenes, cabeceras, terminación de bloque y tramas especiales. Clase TerminalKreta3RecordFactory Factoría de MappedRecord, mediante createMappedRecord se obtiene un objeto de la clase TerminalKreta3MappedRecord. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 82 7. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3 7.1 Descripción general y funciones principales El Módulo Kreta3 se presenta como un terminal de altas prestaciones y adaptable, mediante configuración, a muy diversas combinaciones de lectores, actuadores e interfaces de usuario. En este apartado se describirán solo los aspectos del terminal que son necesarios para el desarrollo de este proyecto: Control de presencia (Aunque existe también el control de acceso, este no será empleado) Base de datos para 15.000 marcajes. Conectividad a Host: Ethernet. Soporte de biometría: - Hasta 2 sensores biométricos de identificación por huella. - Hasta 4.000 usuarios (identificación offline) - Modos de identificación: 1:1, 1:N, 1:n Las interfaces de usuario que dispone el terminal se dividen en elementos de entrada y salida. Entre las de entrada las más importantes son: Tecla verde (“Entrar”) Indica la Incidencia 01 (“Entrada”). Tecla roja (“Salir”) Indica la Incidencia 02 (“Salida”). Teclas 0..9 Permiten la introducción de un código numérico (típicamente el de PIN). Entre los elementos que componen la interfaz de salida cabe señalar: Display LCD Dispone de un display de 20 caracteres x 2 líneas. En la primera línea se indica la fecha y la hora, mientras que la segunda se utiliza para guiar al usuario en su interacción con el equipo. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 83 Zumbador (Buzzer) Señaliza la correcta operación del teclado, así como el éxito o fracaso del proceso de identificación del usuario. El módulo Kreta3 comprende diversos métodos de identificación de personas, pero para este desarrollo solo se empleara la identificación biométrica en modo 1:N 7.2 Comunicación IP Para acceder a los servicios de comunicación IP, hay que configurar adecuadamente los parámetros de red. La configuración se puede realizar a través del protocolo Kreta Classic, vía RS-232, aunque por simplicidad se ha empleado el Servicio de Localización Kimaldi que se detalla a continuación. Una vez la configurado el equipo, se dispone de dos protocolos distintos a través de Sockets, TCP o UDP. Para este proyecto se empleará comunicación TCP. El servicio de Localización Kimaldi hace posible la detección de los módulos Kreta3 que estén conectados a nuestra red de área local. Una vez localizado el equipo a partir de su dirección MAC es posible configurar sus parámetros IP y reiniciar el equipo. La petición de la localización desde el Host, hacia el módulo Kreta3 se realiza a través del puerto 2000. Y la recepción de tramas en el Host. Procedentes del módulo Kreta3 se realizan a través del puerto 2001. Cabe destacar que existe una DLL proporcionada por Kimaldi que permite la integración de este Servicio en cualquier aplicación software. La integración de éste funcionalidad en la intranet no será llevada a cabo, pero puedo ser una mejora para desarrollos futuros, y como tal será incluido en este capítulo de la memoria. La comunión tal y como se ha comentado con anterioridad se realiza a través de Sockets TCP. El protocolo utilizado es el Kreta-Classic disponible para este tipo de comunicación. El módulo Kreta3 se encuentra en modo servidor. Por tanto, puede aceptar tramas desde cualquier Host (ver SLK-Seguridad en Apartado 10.1.6.) El socket de conexión siempre será iniciado por el Host. Kreta3 sólo generará eventos TCP mientras dicho socket esté activo. La transmisión de comandos desde el Host hacia el módulo Kreta3 se realiza a través de un puerto arbitrario del Host (Local Port del Host). La recepción de tramas en el módulo Kreta3 se realiza a través del puerto 1001 (Remote Port desde el Host). Las tramas serie consistirán en valores ASCII-Hex según el formato de Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 84 trama descrito en el próximo capítulo. Se incluirán los caracteres delimitadores <STX>, <ETX>. Es interesante subrayar que aunque el módulo Kreta3 dispone de una dirección lógica para estar integrado en una red KPS, el direccionamiento del mismo se realiza a partir de su dirección IP. De entre los datos de configuración relativos a la comunicación del terminal destacan dos: la dirección MAC y la dirección IP. La dirección MAC de cada módulo Kreta3 es única y asignada por el fabricante. Está etiquetada encima de la electrónica en formato hexadecimal. Es un parámetro de solo lectura. La dirección IP de cada módulo Kreta3 será asignada por el usuario en función de las características del área local a la que se conecte. También puede ser asignada por el servidor de la LAN, si se tiene activado el protocolo DHCP. En general, se trata de un campo en la configuración, modificable por el usuario a través del Servicio de Localización Kimaldi o de cualquier servicio de conexión al Host. Por ultimo hablar sobre el formato de transmisión de datos hacia el lector. En el caso de manejar lectores biométricos tipo FIM2030, surgirá la necesidad de enviar información “a través” del módulo Kreta3, para algunas operaciones. Estas tramas no serán interpretadas por el módulo Kreta3, y por tanto deberán ser manejadas de un modo distinto a las tramas habituales. Por los motivos expuestos, las tramas dirigidas directamente a los lectores se denominarán “Extra Data”, y se transmitirán a continuación de un carácter separador de bloques (carácter “End Transmission Block” o <ETB>, ASCII $17). El formato “Extra Data” a través de TSP es: [Longitud][Datos][CRC]. - [Longitud]: Se trata de 4 bytes en formato ASCII-Hex. La longitud mayor soportada es 912 ($0390). - [Datos]: Cadena de 2*[Longitud] bytes. Contiene la información binaria expresada en ASCII Hex. Por ejemplo, un byte de valor $3F se codificará como ‘3F’, que son los bytes [$33 $46]. - [CRC]: Se trata de 2 bytes en formato ASCII-Hex. Constituye la suma de todos los bytes ASCII-Hex de [Longitud] y [Datos] en módulo 255, y luego con vertido este valor a ASCII-Hex. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 85 Recordar que “Extra Data” vendrá precedido del carácter <ETB> (End Transmission Block, ASCII $17), y se cerrará la trama con el carácter <ETX> (ASCII $03). 7.3 Presentación general del funcionamiento del módulo Kreta3 El equipo Kreta3 integra en un solo equipo un "Control de Presencia" y un "Control de Accesos". Estas funciones se pueden desempeñar separadamente o conjuntamente según sea la configuración del equipo. Tres bytes de configuración, CFG_Lista, CFG_Presencia y CFG_Accesos permiten las distintas posibilidades de funcionamiento que se muestran en el siguiente cuadro: CFG_Lista CFG_Presencia CFG_Accesos Funcionamiento Blanca o Libre TRUE FALSE Sólo control de presencia. Blanca o Libre FALSE TRUE Sólo control de accesos. Blanca o Libre TRUE TRUE Control de presencia y control de accesos. Blanca o Libre FALSE FALSE Automático: Control de presencia o control de accesos Negra X X Terminal bloqueado. Verde X X Accesos abiertos. En todos los casos, se generará un único marcaje con la información de todos los procesos realizados. La configuración para todos los terminales se realizará por defecto y de manera fija para que realicen funciones de control de presencia y acceso, para lo cual se configurará los tres bytes mencionados tal y como indica la tabla para este caso. Con el parámetro CFG_Presencia a "TRUE", el equipo Kreta3 registrará un marcaje por cada lectura procedente de su lector principal. Si además el byte de configuración CFG_LectorAuxiliar está a "TRUE", también se registrarán marcajes a partir de las lecturas capturadas por el lector auxiliar. Como no se emplea el lector auxiliar CFG_LectorAuxiliar estará asignado a “FALSE” de forma general y fija para todos los terminales. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 86 Cada marcaje recoge el código de la tarjeta o de usuario, la fecha y la hora de su generación, y un código de incidencia que indica el significado del evento. El equipo Kreta3 dispone de dos algoritmos distintos para generar marcajes por el lector principal. El byte de configuración CFG_FicharMasivo permite seleccionar el algoritmo deseado. Con CFG_FicharMasivo a "FALSE", el equipo Kreta3 interrogará a cada usuario el código de incidencia a registrar. Para minimizar las pulsaciones del teclado en caso de afluencia masiva, configure CFG_FicharMasivo a "TRUE". De este modo el equipo asociará automáticamente un código de incidencia, sin necesidad de teclear. Aunque no se espera una afluencia masiva de empleados se habilitará el fichaje masivo asignando al parámetro CFG_FicharMasivo el valor “TRUE”, con el fin de ahorrar un paso a los usuarios del sistema. Con este modo activado se emplea la “Adquisición del código de incidencia en Marcaje Masivo”. En este modo el equipo Kreta3 exhibirá igualmente la fecha y la hora en la primera línea de la pantalla y en la segunda se mostrará uno de los dos mensajes de modo de marcaje masivo, por ejemplo, "MODO ENTRADA" y "MODO SALIDA". El modo puede seleccionarse pulsando las teclas de Entrada/Salida. Si se registra una lectura mientras se exhibe el mensaje "MODO ENTRADA" se asociará el código de incidencia 01, mientras que si se muestra "MODO SALIDA" la incidencia asociada será la 02. Estos valores por defecto de las incidencias de “MODO ENTRADA” y “MODO SALIDA” se encuentran codificados en el parámetro CFG-UI_Incid_FicharMasivo de las respectivas UIs, y pueden ser modificados si es necesario. Una vez obtenida la huella dactilar asociada a la incidencia establecida, se comprobará su existencia en la base de datos. Si no existe se indicará también por pantalla y se generará un marcaje indicando el tipo de error. Si existe dicho usuario y es una ENTRADA se pasa a continuación a control de acceso. Si fuera una SALIDA se visualizará el texto asociado por la pantalla y se generará un evento con la incidencia obtenida. El evento se guardará en la base de datos del equipo Kreta3 para su posterior lectura por parte del Host. Adicionalmente, el evento se puede transmitir de forma inmediata al Host, en caso que el parámetro CFG_TrazaMarcaje valga “TRUE”. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 87 El algoritmo de control de acceso realiza diferentes comprobaciones en función de la configuración del terminal. Con la configuración que se empleada solo se control de horario y verificación del PIN, en caso de estar activo. Para ello consultará en primer lugar el registro de permisos del usuario en cuestión, se tomará de él el código semanal a utilizar para posteriormente leer el registro semanal y extraer de él el código horario a aplicar. La comprobación previa a este primer paso, del estado presente/ausente en el registro de permisos, para en caso de estar ya presente en el interior del recinto impedir el acceso y se generar un evento de error, se obviará al tener asignado el parámetro CFG_Antipassback el valor “FALSE”. Una vez obtenido el código del horario por uno de los dos métodos, se obtiene el registro horario y se comprueba si la hora actual pertenece a alguno de los tres intervalos del registro. En caso afirmativo se continúa con la comprobación del PIN. En caso contrario se generará un evento de error. En el siguiente paso se pregunta el PIN de acceso, si así consta en el registro de permisos. Si se falla el PIN se genera un evento de error. En caso de PIN coincidente o que no esté activado habrá concluido exitosamente el acceso. Se mostrará su texto asociado por la pantalla y se generará un evento de acceso con la incidencia obtenida. Como ocurre con las SALIDAS el evento se guardará en la base de datos del equipo Kreta3 para su posterior lectura por parte del Host. Adicionalmente, el evento se puede transmitir de forma inmediata al Host, en caso que el parámetro CFG_TrazaMarcaje valga “TRUE”. Cuando el proceso finaliza con el control de presencia se denomina evento de marcaje, y cuando está activo el control de acceso se denomina evento de acceso, aunque ambos tipos son almacenados en la tabla marcajes, distinguidos por su código de evento. Por lo que según esta configuración las entradas son eventos de control de acceso y las salidas eventos de marcajes. Esta distinción es realiza las propias especificaciones del terminal, pero en general hacemos referencia a ambos como marcajes de entrada y salida. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 88 7.4 Modelo de programación El modelo de programación es el conjunto de estructuras de datos e instrucciones que dispone el programador para acceder a ellas. 7.4.1 Configuración La configuración del equipo consta de numerosas estructuras. Se muestra a continuación tan solo aquellas que son significativas desde el punto de vista de configuración y manejo del terminal en el ámbito del módulo de control y gestión de horarios. Así mismo, dentro de cada estructura solo se hace referencia a los parámetros o elementos relevantes desde el mismo punto de vista. Array de parámetros, Kreta3-DB El array de parámetros en el módulo Kreta3-DB consta de 42 posiciones de un byte. Se numeran de la 1 a la 42 (en hexadecimal de la $01 a la $2A) y se expresan mediante dos dígitos hexadecimales. Cuando se represente un valor booleano se tomará como "FALSE" el valor $00 y como "TRUE" cualquier otro. Los parámetros de configuración que se emplean en este desarrollo se muestran a continuación, con su posición, nombre y significado: - $01 - CFG_Presencia: Es un valor Booleano. A "TRUE" obliga a realizar siempre las funciones de control de presencia del equipo. - $02 - CFG_Acceso: Es un valor Booleano. A "TRUE" obliga a realizar siempre las funciones de control de accesos del equipo. - $04 - CFG_FicharMasivo: Es un valor Booleano. A "TRUE" habilita los modos de "Entrada masiva" y "Salida Masiva" evitando así que deba teclearse el código de incidencia para cada marcaje. - $16 - CFG_Lista: Configura el modo de funcionamiento del control de acceso. El Valor $00 significa Lista Blanca, $01 Lista Libre y $03 Lista Verde. Por último, $02 ó $FF corresponden a Lista Negra. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 95 El segundo dígito tiene el siguiente significado: - 0: Evento de acceso correcto - 1: Evento de marcaje correcto - 2: Evento de acceso correcto por excepción - 3: Evento de acceso correcto por horarios - 4: Evento de marcaje erróneo por incidencia - 5: Evento de acceso denegado por permiso - 6: Evento de acceso denegado por PIN - 7: Evento de acceso denegado por excepción - 8: Evento de acceso denegado por horario - 9: Evento de acceso denegado por antipassback - A: Evento de acceso denegado por festivo - B: Evento de acceso denegado por exceso de aforo - D: Evento de enrolamiento biométrico diferido - E: Evento de enrolamiento biométrico erróneo - F: Evento de activación Online (accesos); Evento de alarma o timbre El segundo dígito contendrá el valor 3 indicando un marcaje correcto por horarios o los valores 5, 6, 7, en caso de que • Campo_Incidencia: 21 Para eventos de Presencia/Acceso el campo incidencia contiene dos dígitos hexadecimales con el número de incidencia tecleado por el usuario si éste es el caso. En nuestro caso para un marcaje de entrada tendrá el valor “01” y de salida con el valor “02”. 7.4.2 Descripción de las instrucciones Las instrucciones que admite el módulo Kreta3 así como las respuestas que emite tienen el siguiente formato: Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 96 {Grupo}{Objeto}{Operación}{Datos} Donde: - {Grupo} es un dígito decimal ASCII. - {Objeto} es un dígito decimal ASCII. - {Operación} es un dígito decimal ASCII. - {Datos} es una cadena de caracteres ASCII. Se muestra a continuación el conjunto de operaciones utilizadas para la configuración y operatividad necesaria del terminal. Operaciones de configuración Las instrucciones de configuración pertenecen al {Grupo}='3' y sus respuestas al {Grupo}='4'. Los objetos definidos empleados son: - Registro de Parámetros: {Objeto}='1' - Configuración IP-UDP Socket: {Objeto}='5' - Estructura de la Base de Datos: {Objeto}='6' Y las operaciones que aceptan que se han empleado son: - Write {Operación}='1': Permite almacenar datos en la memoria del equipo. Formato instrucción: - {Objeto}: 1,5 - {Operación}='1' - {Datos}: • Objeto ‘1’: se especificará mediante dos dígitos hexadecimales el número de parámetro a escribir ($01 al $2A) y dos dígitos más con el valor deseado para el parámetro. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 97 • Objeto ‘5’: se especificará mediante ocho dígitos hexadecimales la dirección IP. En caso de valores booleanos (parámetro $09), se usarán dos dígitos hexadecimales. En caso de Descripción (parámetro $0D), se usarán hasta 40 caracteres ASCII. Formato Respuesta: - {Objeto}: el que aparece en la instrucción. - {Operación}: el que aparece en la instrucción. - {Datos}: • Objetos ‘1’ y ‘5’: operación correcta indicada por 11. - Read {Operación}='2': Permite leer los valores almacenados en la memoria del equipo. Formato instrucción: - {Objeto}: 1,5 y 6. - {Operación}: 2 - {Datos}: Se especificará mediante dos dígitos hexadecimales la posición del array que se desea consultar. Formato Respuesta: - {Objeto}: el que aparece en la instrucción. - {Operación}: el que aparece en la instrucción. - {Datos}: el contenido de la posición del array referenciado. • Objeto ‘6’: se usa para verificar la estructura de la base de datos (por ejemplo el número de permisos, que tenemos disponibles). Se especificará un valor entre 01 y 09, correspondiente a los objetos de la base de datos. Observar que este objeto es Read-Only. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 98 Operaciones sobre la base de datos Las instrucciones sobre la base de datos pertenecen al {Grupo}='5' y sus respuestas al {Grupo}='6'. Los objetos definidos empleados son: - Reloj/Calendario: {Objeto}='0' - Tabla Horarios: {Objeto}='2' - Tabla Semanal: {Objeto}='3' - Tabla Permisos: {Objeto}='6' - Tabla Marcajes: {Objeto}='8' Y las operaciones que aceptan que se han empleado son: - DeleteRecord {Operación}='2': Permite borrar un registro de la base de datos. Formato instrucción: - {Objeto}: 2,3,6,8 - {Operación}: 2 - {Datos}: Para las tablas 2,3 se especificará el número de registro a borrar mediante cuatro dígitos hexadecimales. Para las tabla 6 se especificará el código de usuario a borrar mediante 10 dígitos hexadecimales Para la tabla 8 no se especificará argumento porque siempre se borrará el registro más antiguo (no se podrá borrar un marcaje si no se ha leído previamente a través de la instrucción ‘587’) Formato Respuesta: - {Objeto}: el que aparece en la instrucción. - {Operación}: el que aparece en la instrucción. - {Datos}: 11 para indicar operación correcta. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 99 - Store {Operación}='4': Permite guardar/modificar un registro de una tabla. Formato instrucción: - {Objeto}: 0,2,3,6 - {Operación}: 4 - {Datos}: Para la tabla 0 se especificara la fecha y hora en formato AAMMDDhhmmssnn dónde AAMMDD es la fecha, hhmmss corresponde a la hora, y nn es el día de la semana contando a partir de 01 para el lunes. Para las tablas 2 y 3 se especificará el número de registro a guardar/actualizar mediante cuatro dígitos hexadecimales seguido del valor del registro. Para la tabla 6 se especificará directamente el valor del registro a guardar/actualizar. En caso de estar dando de alta un nuevo usuario y usar módulos FIM2030, deberá añadirse la huella biométrica. Formato Respuesta: - {Objeto}: el que aparece en la instrucción. - {Operación}: el que aparece en la instrucción. - {Datos}: 11 para indicar operación correcta. - Size {Operación}='5': Devuelve el número de registros activos que contiene una tabla. Formato instrucción: - {Objeto}: 8 - {Operación}: 5 Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 100 - {Datos}: Ninguno. Formato Respuesta: - {Objeto}: el que aparece en la instrucción. - {Operación}: el que aparece en la instrucción. - {Datos}: cuatro dígitos hexadecimales indicando el número de registros activos de la tabla. - Size&Begin {Operación}='6': Devuelve el número de registros activos que contiene una tabla y a demás sitúa al principio de la tabla el puntero de lectura secuencial de dicha tabla. - Retrieve {Operación}='7': Devuelve el contenido de un registro de una tabla. Formato instrucción: - {Objeto}: 0,2,3,6,8 - {Operación}: 7 - {Datos}: Para las tablas 0,8 no hay argumentos Para las tablas 2,3 se especificará el número de registro a consultar mediante cuatro dígitos hexadecimales. Para las tablas 6 se especificará el código de usuario. Para la tabla 6, existe la opción de recuperar la huella biométrica. Ver siguiente subapartado. Formato Respuesta: - {Objeto}: el que aparece en la instrucción. - {Operación}: el que aparece en la instrucción. - {Datos}: el contenido del registro indicado. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 101 - RetrieveNext {Operación}='8': Devuelve el contenido del primer registro activo encontrado después de la posición apuntada por el puntero de lectura secuencial de esa tabla. Formato instrucción: - {Objeto}: 6 - {Operación}: 8 - {Datos}: No hay argumentos Formato Respuesta: - {Objeto}: el que aparece en la instrucción. - {Operación}: el que aparece en la instrucción. - {Datos}: el contenido del registro indicado si existe. En caso contrario se devolverá 00. Operaciones sobre periféricos (FIM2030) Las instrucciones sobre algunos periféricos del módulo Kreta3 pertenecen al{Grupo}='7' y sus respuestas al {Grupo}='8'. El único objeto definido que hemos empleado es: - FIM2030 actuando como Lector Principal: {Objeto}='1' Y única operaciones utilizada para este objeto es: - Scan FP {Operación}='3': Permite escanear una o dos veces la huella de un usuario. Esta función es Online, de modo que desde el Host se puede gestionar el proceso de enrolamiento de un nuevo usuario. Formato instrucción: - {Objeto}: 1 - {Operación}: 3 Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 102 - {Datos}: Se especificará mediante dos dígitos hexadecimales el número de veces que se escanea la huella (sólo es posible $01 ó $02). Formato Respuesta: - {Objeto}: el que aparece en la instrucción. - {Operación}: el que aparece en la instrucción. - {Datos}: ‘11’ seguido de la cadena en formato Extra Data conteniendo una o dos huellas. 7.5 Pruebas y ejemplos de uso Se muestra a continuación el formato de algunas de las tramas empleadas y ejemplos de tramas utilizas tanto desde la aplicación de prueba suministrada por el fabricante como en un pequeño cliente de comunicaciones desarrollado previo al desarrollo del módulo. En primer lugar las referentes a la gestión de usuarios. Alta de usuario El alta de usuario se realiza a través de la operación ‘564’. El formato de trama será el siguiente: <STX>564[CódigoUsuario|PIN|Semanal|Presencia]3<ETB>[Extra_Data]<ETX> Es decir, justo al final del comando usado habitualmente para dar de alta, se añade: - ‘3’: Dirección a la que vamos a mandar los datos biométricos. ‘1’ correspondería al FIM Principal, ‘2’ al FIM Auxiliar y ‘3’ a los dos anteriores. - <ETB> (End Transmission Block, ASCII $17): Termina el bloque de comando y va a empezar el bloque de Extra Data. - [Extra Data]: Las dos muestras de la huella biométrica son transferidas en un formato binario. Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 103 Ejemplo de trama alta del usuario 0000000001 con PIN activo 1234, código semanal 05, no presente y su correspondiente huella: {0x02, 0x35, 0x36, 0x34, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x31, 0x31, 0x31, 0x32, 0x33, 0x34, 0x30, 0x35, 0z30, 0x30, 0x33, 0x17, [400 bytes], 0x03} Modificación del permiso de usuario Una vez dado de alta un usuario, podemos modificar su código semanal o su PIN sin necesidad de adjuntar de nuevo su huella biométrica. Para ello, usaremos la misma operación ‘564’ en su formato habitual: <STX>564[CódigoUsuario|PIN|Semanal|Presencia]<ETX> Ejemplo de trama de modificación del usuario 0000000001 deshabilitando PIN. {0x02, 0x35, 0x36, 0x34, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x30, 0x30, 0x31, 0x32, 0x33, 0x34, 0x30, 0x35, 0z30, 0x30, 0x03} Baja de usuario El proceso de baja de usuario se realiza normalmente a partir del código de usuario. El módulo Kreta3 procederá automáticamente a borrar la memoria del módulo biométrico que funcione como lector principal, y eventualmente del auxiliar. No se requiere manejar información biométrica. <STX>562[CódigoUsuario]<ETX> Ejemplo de trama de eliminación del usuario 0000000001: {0x02, 0x35, 0x36, 0x33, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x03} Lectura del permiso de usuario La operación ‘567’ (ver Apartado 11.3.7.) nos permite recuperar el registro de la tabla de permisos correspondiente a un código determinado de usuario: <STX>567[CódigoUsuario]<ETX> Estudio y prueba de la interfaz para el manejo del terminal biométrico Kreta3______________ 104 Si además queremos recuperar la información biométrica del usuario, deberemos añadir la dirección del módulo biométrico al final del comando: <STX>567[CódigoUsuario]0<ETX> Es decir, justo al final del comando usado habitualmente para realizar la lectura, se añade: - ‘0’: Dirección de la que vamos a leer los datos biométricos. ‘0’ significa “indistinto” y nos devuelve la lectura del primer FIM que la tenga disponible (normalmente, el FIM Principal). ‘1’ correspondería exclusivamente al FIM Principal, mientras que‘2’forzaría la obtención de la huella procedente del FIM Auxiliar. La respuesta correcta será evidente. No obstante, en caso de error, éstos son los códigos que aparecen: - ‘667A0’: ha fallado la lectura en el FIM Principal, y no existe FIM Secundario. - ‘667B0’: ha fallado la lectura en el FIM Secundario. - ‘667C0’: ha fallado la lectura en los dos FIM. Ejemplo de trama de obtención del usuario 0000000001 en cualquiera de los dos FIM: {0x02, 0x35, 0x36, 0x37, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x30, 0x03} Obtención de datos biométricos del usuario Previo al proceso de alta, será necesario obtener los datos biométricos del usuario que vamos a registrar. En aplicaciones de un solo módulo Kreta3, o bien para simplificar al máximo el software de aplicación, es posible escanear las huellas de usuario a través del propio módulo Kreta3. En esta circunstancia, el módulo Kreta3 está operando Online, puesto que se limita a mandar al Host los datos obtenidos. Veamos con un poco de detalle cómo funciona esta segunda opción. Para dar de alta a un nuevo usuario, necesitamos dos lecturas de la misma huella dactilar. Dado que el formato “Extra Data” requiere de un CRC, lo más sencillo será pedir Implementación________________________________________________________________ 111 intranetEF.ear\intranet.war\WEB-INF\flex\services-config.xml" -contextroot "." -locale en_US necesario para la utilización de la BlazeDS. BlazeDS es una tecnología de mensajería asincrónica para componentes de servidor desarrollados en Java que permite a los desarrolladores conectar aplicaciones Adobe Flex y Adobe AIR con entornos empresariales Java. El resultado de la compilación se despliega directamente en el directorio .war ubicada en el .ear del directorio deploy del servidor de aplicaciones del entorno de desarrollo. jboss-4.2.2.GA-icef\server\default\deploy\intranetEF.ear\intranet.war De esta manera queda perfectamente ubicado para su ejecución en el servidor de aplicaciones como parte web de la aplicación ICEF. 8.2 Implementación del servidor Se muestra es este subcapítulo todos los proyectos software que en conjunto implementan el servidor del módulo. Para estos se lista su contenido, y se da algunos detalles acerca de su compilación, dependencias y despliegue en entorno de desarrollo. 8.2.1 Implementación de la lógica de negocio El proyecto que conforma la implementación de la parte servidora de la aplicación corresponde a un proyecto Java Empresarial que puede ser editado y compilado con la herramienta Eclipse. El proyecto de nombre IntranetEF contiene los siguientes elementos:  src: Contiene el código fuente estructurado en paquetes.  docs: Contiene los JavaDocs de las clases más significativas.  pojos: Directorio de destino de los pojos de la interfaz gráfica que se generan de forma automática a partir de sus homónimos en la aplicación de servidor mediante la herramienta Gas3. Para realizar este proceso se dispone de una tarea al efecto en el bulid.xml para ser ejecutada mediante la herramienta Ant. Una vez creado son movidos manualmente al directorio de pojos de la GUI.  classes: Compilados de la aplicación. Implementación________________________________________________________________ 112  build.xml: Fichero de entrada para la ejecución de diferentes tareas mediante Ant  build.properties: Fichero que define propiedades empleado por build.xml Se muestra a continuación la estructuración del código fuente en el directorio src:  com.edosoftfactory.intranet.ejb.entities: Contiene beans de entidad.  com.edosoftfactory.intranet.ejb.listener: Contiene el Message-driven beans, que es empleado como listener del conector.  com.edosoftfactory.intranet.ejb.sessions: Contiene los beans de sesión.  com.edosoftfactory.intranet.ejb.encrypt: Contiene utilidades para la encriptación de los datos en la base de datos.  com.edosoftfactory.intranet.pojos.controlhorario: Contiene los pojos para el envío de información al cliente.  com.edosoftfactory.intranet.report: Contiene las clases relacionadas con el envío de correos electrónicos.  com.edosoftfactory.intranet.util.controlhorario: Contiene la clase Utils que agrupa diferentes métodos estáticos que se utilizan de forma generalizada en el código.  META-INF: Directorio que se incluye en la generación del jar con diferente información. La compilación se realiza en la versión del JDK 1.6 mediante la correspondiente tarea definida en build.xml y ejecutada mediante Ant. El resultado de la compilación se empaqueta en el correspondiente archivo .jar y se copia en el directorio .ear del directorio deploy del servidor de aplicaciones del entorno de desarrollo, mediante otra tarea al efecto. Este proyecto presenta una dependencia con el proyecto del conector relativo a la interfaz TerminalKreta3Listener. Implementación________________________________________________________________ 113 8.2.2 Implementación del conector El proyecto que conforma la implementación del conector corresponde a un proyecto Java que puede ser editado y compilado con la herramienta Eclipse. El proyecto de nombre kreta3TerminalConnector contiene los siguientes elementos:  src: Contiene el código fuente estructurado en paquetes.  build/clases: Compilados de la aplicación.  deploy: Directorio destino donde se copia el archivo jar empaquetado a partir de las clases compiladas, mediante la tarea al efecto en el build.xml para ser ejecutada mediante Ant. También contiene el archivo data source kreta3Terminal-ds.xml. Contiene los dos elementos necesarios para realizar el despliegue del conector en el servidor de aplicaciones.  build.xml: Fichero de entrada para la ejecución de diferentes tareas mediante la herramienta Ant. Se muestra a continuación la estructuración del código fuente en el directorio src:  com.edosoftfactory.intranet.terminalKreta3.comunicacion: Contiene todas las clases relativas a la comunicación a nivel de sockets con los terminales.  com.edosoftfactory.intranet.terminalKreta3.jca.cci: Contiene la implementación de las clases del conector relacionadas con la ejecución del mismo desde el código que lo emplea.  com.edosoftfactory.intranet.terminalKreta3.jca.inbound: Contiene la interfaz que implementa el message-driven bean que actúa de Listener.  com.edosoftfactory.intranet.terminalKreta3.spi: Contiene la implementación de las clases del conector relacionadas con la comunicación.  com.edosoftfactory.intranet.terminalKreta3.util: Contiene la clase Constantes, UtilesCadenas y ConnectorLogger. La compilación se realiza en la versión del JDK 1.6 mediante la correspondiente tarea definida en build.xml. Y el resultado de la compilación se empaqueta en el correspondiente archivo rar y se copia junto con el “data source” en el directorio deploy del proyecto y del servidor de aplicaciones del entorno de desarrollo, mediante la correspondiente tarea de la utilidad Ant. Implementación________________________________________________________________ 114 8.2.3 Implementación de los planificadores El proyecto que conforma la implementación de los planificadores corresponde a un proyecto Java que puede ser editado y compilado con la herramienta Eclipse. El proyecto de nombre Scheduler contiene los siguientes elementos:  srcControlDairio: Contiene el código fuente del planificador Control Diario estructurado en paquetes.  buildControlDairio/clases: Compilados del planificador Control Diario.  srcCambioModo: Contiene el código fuente del planificador Control Diario estructurado en paquetes.  buildCambioModo/clases: Compilados del planificador Control Diario.  deploy: Directorio destino donde se copia los archivos sar, uno por cada planificador, empaquetado a partir de las clases compiladas, mediante la tarea al efecto en el build.xml para ser ejecutada mediante Ant. Contiene el elemento necesario para realizar el despliegue de los planificadores en el servidor de aplicaciones.  build.xml: Fichero de entrada para la ejecución de diferentes tareas mediante la herramienta Ant. Se muestra a continuación la estructuración del código fuente de los directorios srcControlDiario y srcCambioModo:  com.edosoftfactory.intranet.controlDiario.schedulerControlDiario : Contiene la clase del planificador Control Diario.  com.edosoftfactory.intranet.cambioModo.schedulerCambioModo: Contiene la clase del planificador Cambio Modo. La compilación se realiza en la versión del JDK 1.6 mediante la correspondiente tarea definida en el archivo build.xml. Y el resultado de la compilación se empaqueta en los correspondientes archivos sar y se copian en el directorio deploy del proyecto y del servidor de aplicaciones del entorno de desarrollo, mediante la correspondiente tarea de Ant. Este proyecto presenta una dependencia con el proyecto IntenetEF relativo a la interfaz remota del bean de sesión ControlHorarioFacade. Pruebas______________________________________________________________________ 115 9. Pruebas Las pruebas funcionales automatizadas diseñadas para el módulo de control y gestión de horarios abarca la mayor parte de la funcionalidad del servidor. Las pruebas relativas al cliente se han limitado a la especificación de una lista de comprobación que contempla la totalidad de los casos de uso, la cual se ha realizado de forma manual. 9.1 Pruebas GUI Existen algunos frameworks de pruebas poco evolucionados para las pruebas automatizadas de aplicaciones desarrolladas en Flex. Por este motivo y dado el reducido número de casos de uso el test funcional de la interfaz gráfica del módulo corresponderá a una serie de casos de prueba propuestos que se realizara de forma manual. Condiciones iniciales del test funcional 1. El terminal biométrico debe estar completamente vacío. Se puede comprobar su estado, y proceder al borrado de las diferentes tablas mediante la aplicación demo proporcionada por el fabricante. 2. Cambio de la fecha del sistema al día 09-27-2013, para la correcta visualización de la información de los datos de prueba. 3. El servidor de aplicaciones debe estar arrancado con el despliegue de la intranet realizado en el directorio deploy de este. 4. Ejecución del script de populación al efecto adjunto en el proyecto de pruebas, en la ruta: “/recursos/icef_prod_recreate_20110709.sql”, que inserta en la base de datos información sobre los empleados que se emplean para realizar los casos de prueba. 5. Acceso a la intranet corporativa: a. Acceder a la interfaz de la intranet mediante un navegador con Plugin de Adobe Flash instalado. (http://localhost:8080/ControlHorario.html) b. Realizar el login con dos diferentes usuarios en función del roll que se pretenda probar: i. Roll Administrador: Login: - Password: ii. Roll Usuario: Login: - Password: Pruebas______________________________________________________________________ 116 Test funcional para Roll Administrador El usuario de prueba sin privilegios, Prueba0, ya se encuentra dado de alta en el sistema con información biométrica, marcajes, e incidencias. Parte del cometido de este test es la comprobación de la correcta visualización de esta información por parte de usuarios con roll administrador. Jornada Laboral Descripción Resultado Caso 1 Crear Jornada Laboral VERIFICADO Caso 2 Modificar Jornada Laboral VERIFICADO Caso 3 Eliminar Jornada Laboral VERIFICADO Caso 4 Eliminar Jornada Laboral asociada a un empleado VERIFICADO Empleado Descripción Resultado Caso 5 Alta Empleado correcta para empleado Prueba1. VERIFICADO Caso 6 Alta Empleado correcta para empleado Prueba1. VERIFICADO Caso 7 Modificación empleado Prueba1 VERIFICADO Caso 8 Modificación empleado Prueba1 VERIFICADO Caso 9 Baja Empleado Prueba1 VERIFICADO Caso 10 Alta empleado Prueba1 tras baja previa VERIFICADO Caso 11 Verificación empleado Prueba1 VERIFICADO Caso 12 Subsanación empleado Prueba1 innecesaria VERIFICADO Caso 13 Verificar empleado Prueba1, eliminado del terminal VERIFICADO Caso 14 Subsanación empelado Prueba1 VERIFICADO Pruebas______________________________________________________________________ 117 Terminal Descripción Resultado Caso 17 Comprobar el número de marcajes en el terminal VERIFICADO Caso 18 Borrado de marcajes en el terminal VERIFICADO Caso 19 Comprobación de conectividad con terminal VERIFICADO Caso 20 Comprobar conectividad con terminal desconectado. VERIFICADO Caso 21 Desbloqueo de terminal en estado no bloqueado. VERIFICADO Caso 22 Desbloqueo de terminal en estado bloqueado. VERIFICADO Caso 23 Modificación de configuración del terminal VERIFICADO Marcajes e Incidencias Descripción Resultado Caso 24 Comprobación de los marcajes de la semana en curso para el usuario Prueba0. VERIFICADO Caso 25 Comprobación de los marcajes del mes en curso para el usuario Prueba0. VERIFICADO Caso 26 Comprobación de los marcajes del año en curso para el usuario Prueba0. VERIFICADO Caso 27 Comprobación de las incidencias de la semana en curso para el usuario Prueba1. VERIFICADO Caso 28 Comprobación de las incidencias del mes en curso para el usuario Prueba0. VERIFICADO Caso 29 Comprobación de las incidencias del año en curso para el usuario Prueba0 VERIFICADO Caso 30 Comprobación de las incidencias por tipo. VERIFICADO Marcajes Descripción Resultado Caso 15 Marcaje de entrada para Prueba1 VERIFICADO Caso 16 Marcaje de salida para Prueba1 VERIFICADO Pruebas______________________________________________________________________ 118 Test funcional para Roll Usuario El usuario de prueba sin privilegios, Prueba0, ya se encuentra dado de alta en el sistema con información biométrica, marcajes, e incidencias. El cometido de este test es la comprobación de la correcta visualización de esta información para Prueba0 de sus propios marcajes e incidencias. Marcajes e Incidencias Descripción Resultado Caso 1 Comprobación de los marcajes de la semana en curso. VERIFICADO Caso 2 Comprobación de los marcajes del mes en curso. VERIFICADO Caso 3 Comprobación de los marcajes del año en curso. VERIFICADO Caso 4 Comprobación de las incidencias de la semana en curso. VERIFICADO Caso 5 Comprobación de las incidencias del mes en curso. VERIFICADO Caso 6 Comprobación de las incidencias del año en curso. VERIFICADO Caso 7 Comprobación de las incidencias por tipo. VERIFICADO 9.2 Pruebas modelo de negocio 9.2.1 Especificación A continuación se especifican los casos de prueba a desarrollar. Cada uno de los tests especificados pertenecerá a una o varias de las suits de pruebas (agrupación de casos de pruebas) según la naturaleza de la misma. La pertenencia de cada uno de los casos a dichas suists viene indicado en la las diferentes tablas de este capítulo. Existen 3 suits diferentes: Casos de prueba manual (1) En esta suit se engloban los casos de prueba que se realizan utilizando la intranet conectada al terminal biométrico. Al ejecutar la suit será necesario interactuar con el Pruebas______________________________________________________________________ 119 terminal para el desarrollo de la misma., para la captura de datos biométricos en las altas de empleados. Casos de prueba automático con un solo terminal (2) En esta suit se engloban los casos de prueba que se realizan utilizando la intranet conectada al simulador de terminal biométrico en configuración de un solo terminal. Casos de prueba automático con múltiples terminales (3) En esta suit se engloban los casos de prueba que se realizan utilizando la intranet conectada al simulador de terminal biométrico en configuración de múltiples terminales. Alta Usuario Descripción 1 2 3 Caso 00 Alta exitosa de empleado en terminal/terminales. X X X Caso 01 Alta fallida de empleado en terminal. Empleado ya creado. X X Caso 03 Alta fallida del empleado en terminal (error en la captura de huellas [sin captura]). X X Caso 04 Alta empleado en terminal después de alta fallida (error en la captura de huellas [sin captura]). X X Caso 05 Alta fallida en terminal (Jornada Laboral no existe). X X Caso 06 Alta fallida. Terminal bloqueado X X Baja Usuario Descripción 1 2 3 Caso 00 Baja exitosa de empleado en terminal/terminales. X X X Caso 01 Baja fallida de empleado en terminal. Empleado no existente. X X Caso 02 Baja fallida de empleado en terminal. EmpleadoTK3 no dado de Alta. X X Caso 03 Baja fallida de empleado en terminal. Empleado de baja. X X Caso 04 Baja fallida. Terminal bloqueado. X X Pruebas______________________________________________________________________ 120 Verificación Usuario Descripción 1 2 3 Caso 00 Verificación de un usuario en terminal/terminales. Verificación correcta. Empleado completamente integro. X X X Caso 01 Verificación masiva en terminal/terminales. Resultado de las verificaciones: -ID_EMPLEADO: Correcto -ID_EMPLEADO_52: De baja en persistencia pero existe en terminal. -ID_EMPLEADO_53: De alta en persistencia pero no existe en terminal. -ID_EMPLEADO_54: Existe tanto en persistencia como en terminal pero con minucias diferentes -ID_EMPLEADO_55: Existe tanto en persistencia como en terminal pero con valor del atributo 'pin activo' diferente. Sistema necesita subsanación. X X X Caso 02 Verificación de un usuario en terminal/terminales. Verificación con resultado erróneo. Empleado de baja en persistencia pero de alta en el terminal. X X X Caso 03 Verificación de un usuario en terminal/terminales. Verificación con resultado erróneo. Empleado de alta en persistencia y existe en terminal, pero minucias diferentes X X X Caso 04 Verificación de un usuario en terminal/terminales. Verificación con resultado erróneo. Empleado de alta en persistencia y existe en terminal, pero con distinto pin. X X X Modificación Usuario Descripción 1 2 3 Caso 00 Modificación exitosa de empleado en terminal/terminales. X X X Caso 01 Modificación fallida de empleado en terminal. Empleado no existente. X X Pruebas______________________________________________________________________ 127 Simulador de terminales Como elemento principal a modelar se encuentra el diagrama de clases de Figura 29, que conforma el modelo de datos del simulador encargado de contener todos los datos pertenecientes a Terminales, Empleados y Marcajes tal y como lo hace el Terminal Kreta 3, para una correcta simulación de su funcionamiento. Se muestra en diagrama de la Figura 30 un diagrama de componentes formado por los diferentes elementos funcionales que componen el simulador, así como sus interfaces externas. Figura 29. Diagrama de clases del modelo de datos mantenido por el simulador. Pruebas______________________________________________________________________ 128 Por último se muestran una serie de diagramas de secuencia en donde se especifica el flujo de ejecución durante el arranque del simulador y tras la recepción de comandos, ya sean propios del conjunto de órdenes del Terminal Kreta3 o comandos de control para la ejecución de comportamientos. Figura 30. Daigrama de compoenntes del simulador de terminales biometricos Kreta 3 Figura 31. Daigrama de secuencia del flujo de recepción y ejecución de comandos en el simulador (1ª parte) Pruebas______________________________________________________________________ 129 La Figura 31 muestra el diagrama de colaboración durante el arranque del simulador desde la función main hasta que los hilos principales de ejecución son iniciados y quedan a la espera de algún evento. Figura 32. Daigrama de secuencia del flujo de recepción y ejecución de comandos en el simulador (1ª parte) Pruebas______________________________________________________________________ 130 La Figura 32 muestra el diagrama de secuencia operación de alta diferida, desde que el comando es recibido, procesado y la respuesta al mismo es devuelta. 9.2.3 Implementación El proyecto que constituye la implementación de las pruebas para la aplicación corresponde a un proyecto Java que puede ser editado y compilado con la herramienta Eclipse. Fundamentalmente el proyecto contiene un framework propio de pruebas que pretende hacer más fácil la creación de casos de prueba, los propios casos de prueba y un simulador de terminal que permite automatizar pruebas y realizar las mismas con configuración de múltiples terminales. El framework desarrollado emplea la librería JUnit. El proyecto de nombre TestIntranetEF contiene los siguientes elementos:  src/test: Contiene el código fuente estructurado en paquetes.  clases: Compilados de la aplicación.  build.xml: Fichero de entrada para la ejecución de diferentes tareas mediante ant Se muestra a continuación la estructuración del código fuente en el directorio src:  com.edosoftfactory.test.controlHorario. Clases fundamentales del framework de pruebas.  com.edosoftfactory.test.controlHorario.accion: Conjunto de clases de acciones que pueden ser asociadas a eventos esperados.  com.edosoftfactory.test.controlHorario.conectores: Conectores de diversos tipos (JMS, RMI, SQL, TCP) que permiten las conexiones necesarias para el funcionamiento del entorno de pruebas. Permitiendo la recepción de mensajes, la interacción con la fachada de la lógica de negocio, modificación directa de la base de datos y control para tests del simulador de terminales.  com.edosoftfactory.test.controlHorario.configuracion: Datos de configuración que utiliza el conector del simulador para establecer comunicación al puerto de control del mismo.  com.edosoftfactory.test.controlHorario.constantes: Constantes empleadas por los tests. Datos que permiten definir, referenciar, empleados, jornadas laborales, terminales, etc. Pruebas______________________________________________________________________ 131  com.edosoftfactory.test.controlHorario.modelo: Conjunto de clases de eventos que sirven para definir los eventos esperados en un caso de prueba.  com.edosoftfactory.test.controlHorario.simuladorTK3. comunicacion: Contiene todas las clases relacionadas con la comunicación del simulador: Sockets, colas e hilos de comunicación y procesamiento genérico de tramas de órdenes de terminal y control.  com.edosoftfactory.test.controlHorario.simuladorTK3. configuracion: Contiene archivos relativos a la configuración del simulador y los comportamientos para el envío asíncrono de marcajes.  com.edosoftfactory.test.controlHorario.simuladorTK3.constantes: Contiene la clase donde se define las contantes utilizadas el en código de simulador.  com.edosoftfactory.test.controlHorario.simuladorTK3.modelo: Contiene las clases que conforman el modelo de datos necesario para el funcionamiento del simulador.  com.edosoftfactory.test.controlHorario.simuladorTK3.run: Contiene las clases principales del simulador, incluida la clase principal Simulador.java  com.edosoftfactory.test.controlHorario.simuladorTK3.util: Contiene la clase de apoyo para el parseo y la conformación de tramas.  com.edosoftfactory.test.controlHorario.suite.automatico. multiplesTerminales: Conjunto de casos de pruebas que testean la intranet conectada al simulador de terminal en su configuración de múltiples terminales.  com.edosoftfactory.test.controlHorario.suite.automatico. terminalUnico: Conjunto de casos de pruebas que testean la intranet conectada al simulador de terminal en su configuración de terminal único.  com.edosoftfactory.test.controlHorario.suite.manual: Conjunto de casos de pruebas que testean la intranet conectada al terminal biométrico  com.edosoftfactory.test.controlHorario.suite.util: Contiene la clase Utils que agrupa diferentes métodos estáticos que se utilizan de forma generalizada en los casos de prueba. También contiene la clase LoggerUtil para facilitar el logeo del framework de pruebas. La compilación se realiza en la versión del JDK 1.6 utilizando tal y como se ha comentado la librería JUnit 4. Pruebas______________________________________________________________________ 132 9.2.4 Configuración y ejecución Tal y como se comenta en el apartado anterior existen 3 suits diferentes para las pruebas del Modelo de Negocio, cada una de las cuales requiere una serie de pasos de configuración previa y posterior ejecución. Este apartado parte de un correcto despliegue de la aplicación en un entorno de desarrollo o de preproducción. Para todas las Suits es necesario la creación previa de un usuario en la base de datos llamado “test” con password “test000”, y con accesos permitidos a la base de datos Icef desde el host donde se ejecuten las pruebas. Con este usuario se realizaran operaciones directas sobre la base de datos con el fin de restaurar su estado al momento antes de la ejecución de cada caso de prueba. Además, como en el caso de las pruebas de la interfaz gráfica, será necesario la ejecución de un script almacenado en el proyecto de pruebas cuyo nombre y ruta es /recursos/icef_prod_recreate_20110709.sql, para la inserción de la base de datos de los datos iniciales necesarios para la ejecución de las suits. La ejecución solo será necesaria una vez. Suit manual En esta suit se engloban los casos de prueba que se realizan utilizando la intranet conectada al terminal biométrico. Al ejecutar la suit será necesario interactuar con el terminal para el desarrollo de la misma que deberá estar configurado y conectado a la red de manera adecuada. Para la instalación y configuración inicial del terminal se han de seguir las siguientes instrucciones:  Alimente Kreta3, con el cable Ethernet conectado.  Ejecute KSearch, para configurar los parámetros IP de Kreta3. KSearch es la utilidad software que permite detectar y configurar los dispositivos Kimaldi conectados a la red y ha sido proporcionado junto con el terminal. a) El puerto SLK se abre automáticamente b) Buscar dispositivos Kimaldi conectados a nuestra LAN (marque “Forzar respuesta en modo broadcast…” si nuestra LAN no corresponde a la dirección 192.168.123.xx ) c) Kreta3 tendría que aparecer en la lista. Asegúrese de que la HW Address (MAC Addr.) se corresponde con el dispositivo a configurar. Pruebas______________________________________________________________________ 133 d) Leer configuración, de modo que se pueda editar en la parte baja de la pantalla. e) Especifique IP Address y Remote Host (la dirección IP del ordenador), o marque Obtener una IP automáticamente (DHCP) f) Escribir configuración, para enviar los nuevos datos a Kreta3 g) Aplicar configuración. Kreta3 reiniciará. h) Después de unos segundos, Buscar de nuevo y Kreta3 tendría que aparecer otra vez en la tabla, esta vez con la nueva IP Address. i) Leer configuración otra vez, para estar seguros que Remote Host se ha actualizado correctamente. Remote Host es necesario para ejecutar DemoKreta. Figura 33. Pantalla principal del KSearch. Pruebas______________________________________________________________________ 134 Los valores adecuados para las pruebas para los diferentes parámetros son los siguientes: DIRECCION IP:192.168.1.10 PUERTO: 6000 GATEWAY: 192.168.1.1 MASCARA DE RED: 255.255.255.0 DHCP: False HOST REMOTO: 192.168.1.35 PUERTO REMOTO: 6001 Nota: La dirección del terminal biométrico, del Gateway y el host remoto podrán variar en función de la configuración de red donde se encuentre instalando el terminal y el host desde donde se ejecutan las pruebas. Posteriormente se configura el conector de la intranet para una adecuada comunicación con el terminal mediante el archivo Kreta3TerminalConnector\src\METAINF\ra.xml En este se debe comentar las configuraciones para el resto de pruebas y eliminar los comentarios del apartado que aplica para este caso: Una vez concluido el paso anterior se realiza un nuevo despliegue del conector con la configuración modificada mediante la ejecución de tag kreta3Terminal- <!-- Configuracion terminal unico real --> <config-property> <config-property-name>terminalKreta3Hosts</config-property-name> <config-property-type>java.lang.String</config-property-type> <config-property-value>[email protected]</config-property-value> </config-property> <config-property> <config-property-name>terminalKreta3Ports</config-property-name> <config-property-type>java.lang.Integer</config-property-type> <config-property-value>1001</config-property-value> </config-property> <config-property> <config-property-name>terminalKreta3CaracterSeparador</config-property-name> <config-property-type>java.lang.String</config-property-type> <config-property-value>;</config-property-value> </config-property> Pruebas______________________________________________________________________ 135 connector-deploy del build.xml del proyecto Kreta3TerminalConnector mediante la herramienta Ant de Apache desde el eclipse, y se relanza el servidor de aplicación. En último lugar se ejecuta desde el eclipse la suit como una Suit de JUnit mediante la clase que la contiene: com.edosoftfactory.test.controlHorario.suite.manual.TestsTerminalUnico .java Suit automática con un único terminal En esta suit se engloban los casos de prueba que se realizan utilizando la intranet conectada al simulador de terminal biométrico en configuración de un solo terminal. En este caso no es necesario disponer de ningún terminal conectado. Tan solo hay necesidad de ejecutar el Simulador de terminal con la configuración de un solo terminal y la configuración y despliegue del conector con los parámetros adecuados como en el caso anterior. Para configurar el Simulador en modo de simulación de un solo terminal se modifica el fichero de propiedades com.edosoftfactory.test.controlHorario.simuladorTK3.modelo.Config.xml cambiando el valor de la propiedad CONFIGURACION a SIMPLE A continuación se ejecuta el simulador desde el eclipse mediante la clase: com.edosoftfactory.test.controlHorario.simuladorTK3.run.Simulador obteniendo por consola los diferentes mensajes del arranque del simulador y quedando este a la espera de conexión por parte del servidor de la aplicación. <!-- MULTIPLE O SIMPLE --> <entry key="CONFIGURACION">SIMPLE</entry> Pruebas______________________________________________________________________ 136 De igual manera se configura el conector de la intranet para una adecuada comunicación con el terminal mediante el archivo Kreta3TerminalConnector\src\METAINF\ra.xml En este se debe comentar las configuraciones para el resto de pruebas y borrar el comentario del apartado que aplica para este caso: Una vez concluido el paso anterior se realiza un nuevo despliegue del conector con la configuración modificada mediante la ejecución de tag “kreta3Terminal- <!-- Configuracion terminal unico simulado: desarrollo --> <config-property> <config-property-name>terminalKreta3Hosts</config-property-name> <config-property-type>java.lang.String</config-property-type> <config-property-value>[email protected]</config-property-value> </config-property> <config-property> <config-property-name>terminalKreta3Ports</config-property-name> <config-property-type>java.lang.Integer</config-property-type> <config-property-value>6000</config-property-value> </config-property> <config-property> <config-property-name>terminalKreta3CaracterSeparador</config-property-name> <config-property-type>java.lang.String</config-property-type> <config-property-value>;</config-property-value> </config-property> 2014-04-15 11:08:12,414 INFO [main] com.edosoftfactory.test.controlHorario.simuladorTK3.run.Simulador.main(Simulador.jav a:21) - Cargo las propiedades iniciales 2014-04-15 11:08:12,466 INFO [main] com.edosoftfactory.test.controlHorario.simuladorTK3.run.Simulador.main(Simulador.jav a:24) - Se inicializa la persistencia de TK3s, empleados y marcajes 2014-04-15 11:08:12,467 INFO [main] com.edosoftfactory.test.controlHorario.simuladorTK3.run.Simulador.main(Simulador.jav a:29) - Se inicializa el hilo de comunicación de comandos CORE->: Terminal [1] 2014-04-15 11:08:12,469 INFO [main] com.edosoftfactory.test.controlHorario.simuladorTK3.run.Simulador.main(Simulador.jav a:35) - Se crea el hilo reproductor que empieza parado 2014-04-15 11:08:12,469 INFO [main] com.edosoftfactory.test.controlHorario.simuladorTK3.run.Simulador.main(Simulador.jav a:39) - Se inicializa el hilo de comunicación de control TEST->: espera por conexión 2014-04-15 11:08:12,472 INFO [Thread-2] com.edosoftfactory.test.controlHorario.simuladorTK3.run.ServidorComunicacionControl. run(ServidorComunicacionControl.java:77) - Servidor comunicación control: esperando por conexión Desarrollos futuros______________________________________________________________ 143 Creación de pruebas de sistemas para la aplicación. Las pruebas realizadas se han limitado a pruebas funcionales automatizadas para la prueba del backend y una prueba manual para la prueba del frontend. Sería necesario para evaluar las capacidades y la robustez de la parte servidora realizar la simulación de algunos escenarios reales donde se realicen altas, bajas, modificaciones, acceso a los datos de terminal y de usuarios(marcajes, incidencias y datos generales) mientras se reciben un gran número de marcajes a diferentes horas del día. Para esta prueba tan solo habrá que configurar una prueba que realice secuencial o paralelamente, depende del caso, las operaciones anteriormente mencionadas. Y para el envío de marcajes, aprovechando la función reproductora del Simulador, tan solo habrá que desarrollar un fichero con un gran número de marcajes aleatorios para los usuarios dados de alta en cada momento. Configuración de relés para el control de apertura de las puertas de la oficina. El horario flexible proporciona numerosas ventajas, pero también conlleva algunas desventajas. Entre estas se encuentra la complejidad de organización para que el primero empleado en llegar disponga de acceso al centro de trabajo mediante la llave en cuestión. El terminal dispone de relés que mediante su correcta configuración podría actuar sobre pestilleras eléctricas instaladas en las puertas de la oficina, tras un marcaje correcto de personal con permisos para esta acción. Este podría ser un interesante desarrollo futuro con numerosos retos, tales como el aseguramiento de la seguridad y la fiabilidad. Transaccionalidad en operaciones de Altas, Bajas y Modificaciones: Ocultación y automatización de las operaciones de verificación y subsanación. Tras el uso del nuevo módulo de control y gestión de horarios durante un tiempo considerable, con un único terminal, las operaciones de verificación y posterior subsanación no han sido apenas empleadas. Si con la compra de algún terminal más para los otros accesos a la oficina se continuara esta tendencia, se podría valorar la automatización de las operaciones de verificación y subsanación, quedando fuera del control de la interfaz. Para cada operación de alta, baja o modificación se evaluaría que ha finalizado correctamente. En caso contrario se lanzaría automáticamente un proceso de verificación y uno posterior de subsanación, retornando al sistema al estado anterior al Desarrollos futuros______________________________________________________________ 144 fallo producido. Esto convertiría a las operaciones de altas bajas y modificaciones sobre los diferentes terminales instalados, en transaccionales. Adquisición e instalación de un lector de huella dactilar de sobremesa conexión a PC Se ha demostrado que las altas en el sistema empleando el mismo terminal biométrico instalado en el punto de acceso a las instalaciones puede resultar algo incómodo. Al estar alejado el terminal biométrico del PC donde se gestiona el alta, señalar la correcta posición del dedo para la captura, o indicar la necesidad de realizar una nueva captura si es necesario, obliga en determinadas ocasiones al gestor a desplazarse desde su puesto de trabajo al terminal durante esta operación. Añadir al sistema un lector de huella dactilar de sobremesa conectado al PC para la captura de los datos biométricos que después emplear en el alta diferida mejoraría el procedimiento de altas. Esta opción se valoró en el proceso de requisitos de usuario, pero se suprimió para no incrementar el gasto del proyecto, y más aun teniendo en cuenta que las operaciones de Alta de empleado en sistema son de escasa frecuencia para una PYME como Edosoft. En cualquier caso se podría incluir en un desarrollo futuro como mejora o si se decidiera comercializar la intranet o el módulo de control y gestión de horarios por separado sería indispensable. Funcionalidad de detección y configuración de terminales biométricos En la actualidad antes de conectar el terminal biométrico Kreta 3 a la red para su utilización como parte del sistema es necesaria su configuración. Para ello como ya se ha comentado con anterioridad se emplea el programa Servicio de localización, mediante el cual se realiza su detección y configuración de red. Una vez accesible se configura la intranet para una adecuada conexión al mismo. Incluido en el software del terminal Kimaldi aporta unas dlls bibliotecas de enlace dinámico, para realizar esta configuración de red inicial para cualquier terminal Kreta 3 conectado a la misma, como parte de la funcionalidad de un desarrollo propio. Sería interesante añadir la posibilidad de configurar terminales desde la propia intranet, facilitando de este modo la operación de altas de terminales en el sistema. Desarrollos futuros______________________________________________________________ 145 Automatización de los despliegues Completar la funcionalidad que se realiza mediante Ant para poder realizar despliegues en máquinas remotas de todos los componentes que constituyen la Intranet, tanto de los ya existentes en el momento de comienzo de este proyecto, core del servidor, y GUI, como los nuevos desarrollados, conector y planificador. Automatización del cambio de Modo (Entrada y Salida) y empleo del antipassback Implementación de un planificador que dos veces al día se ejecute (A media noche y al medio día) cambiando el modo en que está configurado el terminal (Entradas o salidas masivas), evitando que el primer usuario que ficha una salida o una entrada en una jornada laboral tenga que realizar el cambio manual de modo, interactuando con el teclado. Esta funcionalidad es necesaria para evitar en gran medida que algunos usuarios, por error, tenga seleccionado un modo inadecuado a la hora de fichar, produciéndose, por ejemplo, dos marcajes de entrada en un día, o un primer marcaje de salida al empezar el día. La segunda entrada, o un marcaje de salida sin uno previo de entrada, no son computadas según las especificaciones, pero el usuario no se da cuenta de esta eventualidad hasta que le llega una incidencia o hasta revisar sus marcajes realizados en la intranet. Este cambios al resultar bastante sencillo de implementar y necesario para mejorar la usabilidad del sistema fueron implementados y puestos en producción al poco tiempo de la implantación del módulo de control y gestión horaria. Está modificación forma parte del código entregado y así consta en el capítulo 8.2.3 Implementación de los planificadores. Resultados y conclusiones________________________________________________________ 146 11. Resultados y conclusiones Según los objetivos planteados inicialmente se ha llegado a unos resultados satisfactorios, obteniendo un sistema de control y gestión de horarios operativo, en el contexto de una aplicación existente, una intranet corporativa para la gestión de los procesos empresariales. Actualmente el módulo de control y gestión de horarios se encuentra en producción, con un número ínfimo de bugs hallados durante un periodo considerable de tiempo, signo de un excelente proceso de desarrollo. Aunque durante el tiempo de desarrollo y el periodo que la aplicación lleva en producción se han especificado nuevos requisitos, lo requisitos iniciales se han identificado correctamente e implementados en su totalidad, dando como resultado un módulo con las características justas y necesarias para el control y la gestión horario de los empleados de Edosoft. Cabe destacar el concienzudo trabajo de ingeniería inversa para conocer el estado de la intranet en los inicios del proyecto y la validación de integración del nuevo módulo a desarrollar, tras la se pudo afirmar con rotundidad que la nueva funcionalidad podría ser desarrollada a partir de la ya existente sin que surgiera ningún tipo de problema de incompatibilidad a posteriori o dificultad no contemplada. Otro de los éxitos del desarrollo ha sido la fase de pruebas, cuyas pruebas funcionales abarcan la totalidad de los casos de uso, con varias pruebas automatizadas para cada uno de estos, teniendo como punto de entrada los métodos de fachada del backend de la aplicación. Por otro lado la interfaz gráfica también dispone de un conjunto de pruebas manuales especificadas, que abarcan también el total de las operaciones que se realizan desde la misma, aunque debido a la complejidad de estas, gran parte de los pocos fallos encontrados estaban ubicados en el frontend de la aplicación. La elección del terminal y el proveedor ha sido otro de los grandes aciertos. El terminal robusto, fiable, con una documentación impecable, y con una funcionalidad adecuada a las necesidades ha facilitado el trabajo de integración del mismo como elemento hardware en el nuevo módulo desarrollado. Quizás solo un pero, la funcionalidad que el terminal ofrecía era muy superior a lo que el proyecto requería, y Resultados y conclusiones________________________________________________________ 147 aunque algunas de estas características se podían haber empleado en el transcurso del desarrollo para realizar en el terminal cierto control, se ha optado por realizar el mismo como parte de la lógica de negocio, para independizar lo máximo posible el modulo del terminal empleado, pudiendo cambiar el mismo por otro, siempre y cuando cumpla con un número reducido de requisitos. Y qué decir del proveedor, el proceso de compra ágil con un asesoramiento adecuado, y un soporte durante el transcurso del proyecto inmejorable. Como única sombra del desarrollo del proyecto se ha de destacar la infraestimación temporal de alguna de las tareas, que unido a la falta de continuidad en la ejecución del mismo ha provocado un retraso temporal de un 25% con respecto al total estimado. Es difícil en cualquier caso atribuir que parte del retraso corresponde a la infraestimación temporal de algunas tareas, como por ejemplo la de pruebas, y que porcentaje a la falta de continuidad y el trabajo en periodos cortos de dedicación diaria. A pesar de esta eventualidad, el producto obtenido es de gran calidad y está dando unos resultados realmente buenos en su funcionamiento diario. Herramientas de edición, compilación y control de la configuración_______________________ 148 12. Herramientas de edición, compilación y control de la configuración Implementación -IDE Eclipse Ganimedes: Codificación y compilación de la aplicación servidora y el proyecto de pruebas. -Cliente Git: Control de versiones. -IDE Adobe Flex Builder 3: Codificación y compilación de la Interfaz Gráfica de Usuario. Memoria -Argo UML 0.32.1: Elaboración de diagramas de clases del servidor (Java) y diagramas de componentes en general. -Microsoft Visio 2013: Diagramas de secuencia. -Balsamiq Mockups For Desktop: Prototipo de pantallas de la GUI. -UML4AS: Elaboración de diagramas de clases del cliente (ActionScript). -Microsoft Word 2013: Redacción y edición de esta memoria. -Microsoft Project 2013: Diagrama de Gannt. Acrónimos____________________________________________________________________ 149 13. Acrónimos AFAS: Automatic Fingerprint Autentication System. CORBA: Common Object Request Broker Architecture DHCP: Dynamic Host Configuration Protocol GUI: Graphic User Interface JDBC: Java Database Connectivity JMS: Java Message Service J2EE: Java 2 Platform, Enterprise Edition LAN: Local Area Network MAC: Media Access Control MXML: Macromedia Extensible Markup Language MVC: Modelo Vista Controlador RFID: Radio Frequency IDentification RIA: Rich Internet applications RMI: Remote Method Invocation SMTP: Simple Mail Transfer Protocol CVS: Concurrent Versions System UOI: Unidad Organizativa Interna VO: Value Object XML: Extensible Markup Languag Bibliografía__ _________________________________________________________________ 150 14. Bibliografía [1]. Biometría, http://es.wikipedia.org/wiki/Biometria. [2]. Sensor de huella dactilar, http://es.wikipedia.org/wiki/Sensor_de_huella_digital. [3]. D. Maltoni, D. Maio, A. K. Jain, S. Prabhakar “Handbook of Fingerprint Recognition” Springer, 2009. [4]. J. Areitio Bertolín, M. T. Areitio Bertolín, “Análisis en torno a la tecnología biométrica para los sistemas electrónicos de identificación y autenticación” Revista española de electrónica, núm. 630, pp. 56-67, 2007. [5]. Introducción a la biometría, http://www.monografias.com/trabajos43/biometria/biometria.shtml. [6]. A. K. Jain, S. Z. Li, “Encyclopedia of biometrics” Springer, 2009 [7] http://es.wikipedia.org/wiki/Servidor_de_aplicaciones [8] Kimaldi “Kreta3 Manual de Instalación y Programación v. 1.01” 2009 [9] Kimaldi “Primeros pasos con Kreta3” 2009 Apéndice I. Manual de usuario____________________________________________________ 151 Apéndice I. Manual de usuario El acceso al módulo de control y gestión horaria se realiza a través del menú “Control horario” de la barra de menús. El menú está compuesto por dos opciones: “Listar" y "Revisar”. Con la primera de estas opciones, habilitada para todo tipo de usuarios, se accede a la información de nuestros propios marcajes e incidencias asociadas. La única precondición para tener acceso a esta opción del menú es estar dado de alta en el sistema de control horario. Con la segunda opción, habilitada solo para usuarios con privilegios (Administradores y Jefes de UOI), se puede acceder a la información de marcajes e incidencias de todos los usuarios dados de alta, información de terminales Kreta3 conectados, gestión de jornadas laborales, y a toda la funcionalidad necesaria para realizar el resto de operaciones que permiten gestionar el sistema de Control horario. Figura 37. Menú Control horario. Apéndice I. Manual de usuario____________________________________________________ 152 1. Opción Listar Tal y como se muestra en la Figura 38. Pantalla con información de marcajes y jornada laboral pertenecientes a la opción del menú Listar., el usuario pude obtener información de los marcajes realizados e incidencias asociadas, mediante tres pestañas a la derecha del área de visualización, bajo la barra de menús. En la primera pestaña se muestran todos los marcajes de entrada y salida realizados por el usuario. En la segunda pestaña se muestran los marcajes agrupados por días, junto con las horas totales y las horas realmente computadas (descontada la hora del almuerzo para jornadas de más de 7 horas) para cada una. Para cada una de estas pestañas en la parte inferior se muestra el número de horas totales y número de horas computadas. Una tercera pestaña muestra información de las incidencias en marcajes que se han producido para el usuario en cuestión. La siguiente tabla muestra los códigos de incidencias con su correspondiente significado: Código de incidencia Significado. 001 Excedida la hora de entrada máxima fijada 002 Incumplida la hora de salida mínima fijada 003 Incumplida la hora de entrada mínima fijada 004 Excedida hora de salida máxima fijada 005 Fichaje de entrada no debido (Fichaje en un día festivo, vacaciones o definido como no laborable) Figura 38. Pantalla con información de marcajes y jornada laboral pertenecientes a la opción del menú Listar.