SISTEMA BIOMETRICO DIGITAL (SBD)-RMIMANUAL DE TECNICO

GUSTAVO SALAZAR ESCOBARCARLOS CESAR CERON

ING. PABLO MAGÉ IMBACHÍDocente

UNIVERSIDAD DEL CAUCAFACULTAD DE INGENIERÍA ELECTRÓNICA Y

TELECOMUNICACIONESPROGRAMA DE INGENIERÍA DE SISTEMAS

SISTEMAS DISTRIBUIDOSPOPAYÁN

2015

TABLA DE CONTENIDOS

1. INTRODUCCIÓN ......................................................................................... 3

1.1. DESCRIPCIÓN GENERAL DEL PROBLEMA ....................................................... 4 1.2. REQUERIMIENTOS DEL PROBLEMA .............................................................. 4

2. ANÁLISIS ................................................................................................... 5

2.1. ANÁLISIS DE REQUERIMIENTOS ................................................................. 5 2.2. CASOS DE USO ................................................................................... 6

2.2.1 ALTO NIVEL............................................................................. 8 3. DISEÑO .................................................................................................... 10

3.1. DIAGRAMA DE CLASES .......................................................................... 10 3.2. DIAGRAMA DE SECUENCIA ..................................................................... 11

4. ARQUITECTURA DEL SISTEMA................................................................... 12

4.1. DIDTRIBUCIÓN DE ARCHIVOS…….............................................................. 12 4.2. DIAGRAMA DE IMPLANTACIÓN ................................................................. 14

5. BIBLIOGRAFÍA ......................................................................................... 14

1. INTRODUCCIÓN

Java RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java [1].

Vamos a ver qué clases necesitamos para hacer nuestros clientes y servidores de rmi, sin extendernos demasiado. Luego veremos cada uno de estos puntos por detallado.

InterfaceRemota: Es una interface java con todos los métodos que queramos poder invocar de forma remota, es decir, los métodos que queremos llamar desde el cliente, pero que se ejecutarán en el servidor.

ObjetoRemoto: Es una clase con la implementación de los métodos de InterfaceRemota. A esta clase sólo la ve el servidor de rmi.

ObjetoRemoto_Stub: Es una clase que implementa InterfaceRemota, pero cada método se encarga de hacer una llamada a través de red al ObjetoRemoto del servidor, esperar el resultado y devolverlo. Esta clase es la que ve el cliente y no necesitamos codificarla, java lo hace automáticamente para nosotros a partir de ObjetoRemoto.

En el pc/máquina servidor de rmi deben correr dos programas

Rmiregistry: Este es un programa que nos proporciona java (está en JAVA_HOME/bin, siendo JAVA_HOME el directorio en el que tengamos instalado java). Una vez arrancado, admite que registremos en él objetos para que puedan ser invocados remotamente y admite peticiones de clientes para ejecutar métodos de estos objetos.

Servidor: Este es un programa que debemos hacernos nosotros. Debe instanciar el ObjetoRemoto y registrarlo en el rmiregistry. Una vez registrado el ObjetoRemoto, el servidor no muere, sino que queda vivo. Cuando un cliente llame a un método de ObjetoRemoto, el código de ese método se ejecutará en este proceso [2].

1.1 Descripción General del Problema

El sistema biométrico digital (SBD) es una herramienta software que permita realizar el control de acceso y estadísticas a la FIET. El sistema será usado por tres tipos de usuarios: Administrativos, Docentes y Estudiantes. El SBD debe contar con un administrador que se encargará de registrar a los usuarios en el SBD y generar las estadísticas por día, por mes o por tipo de usuario. El acceso a la FIET lo harán los diferentes tipos de usuarios bien sea por la portería norte o potería sur, mediante dos modalidades: el uso de tarjetas RFID, o el uso de lector de huellas.

De esta manera pueden identificarse 2 tipos de nodos dentro de este sistema, el cliente, que es aquel que envía la información, al servidor, que es aquel que realiza el tratamiento de los datos y hace disponible la información. Todo este proceso es realizado usando RMI.

1.2 Requerimientos del problema

Se requiere para este sistema lo siguiente:

En el servidor debe quedar registrada la fecha y hora del ingreso o salida de los diferentes tipos de usuarios, por cualquiera de las dos porterías de la FIET.

Funciones del Administrador:El Administrador del sistema debe realizar las siguientes funciones:

Registrar los usuarios del sistema: solicitando los datos que se muestran en la Tabla1, esta información se usará para las tarjetas RFID, la información debe almacenarse en un archivo denominado rfid_id.txt, donde id corresponde al número de identificación del usuario.

Registrar la huella digital: en este caso se simula la lectura de la huella se genera la clave RFC (vista en la primera práctica de laboratorio) pero para ello el usuario debe haber registrado los datos de la tarjeta RFID, en caso contrario el usuario no estará habilitado para registrar su huella.

Generar estadísticas: El SBD debe generar 3 tipos de estadísticas. Estadísticas diarias: Dado un número de identificación y una fecha, el sistema debe

mostrar la información que se describe en la Tabla 2, que básicamente consiste en mostrar las entradas y salidas realizadas por el usuario en una fecha determinada.

Estadísticas diarias: Dado un número de identificación y un mes, el sistema debe mostrar la información que se describe en la Tabla 3, que básicamente consiste en mostrar los días y el número de veces que el usuario uso el SBD en ese mes. La información se debe mostrar por cada semana.

Estadísticas por tipo de usuario: Dado un nombre de mes, el sistema debe mostrar la información que se describe en la Tabla 4, que básicamente consiste en mostrar por cada tipo de usuario el número de veces que cada tipo de usuario uso el SBD en un mes determinado.

La clave y la identificación del administrador, se guardan en un archivo admin.txt, y solo podrán ser modificadas por el administrador.

Funciones del Usuario:

Los usuarios podrán ingresar al sistema ya sea por tarjeta RFID o usando la huella dactilar. Ingreso/salida con tarjeta RFID Para simular este ingreso desde una GUI, el usuario debe

proveer su número de identificación. El SBD debe comparar dicha información con la almacenada en el servidor, si el dato es correcto, el servidor le solicita al usuario que suministre su apellido paterno-como un mecanismo de seguridad- si la identificación y el apellido paterno coinciden se le permitirá su ingreso o salida, mostrando un mensaje en la pantalla.

Ingreso/salida con huella digital: Para simular este ingreso desde una GUI, el usuario selecciona esta opción y el SBD lee el archivo rfid_id.txt, si el archivo existe lee la clave RFC

y la compara con la que existe en el sistema, dicha comparación debe ser realizada en el servidor para habilitar su ingreso o salida.

Tener en cuenta que toda entrada al sistema bloquea el intento de usar otra entrada con el mismo RFID o la misma huella dactilar, el mismo comportamiento pasa con el intento de salir 2 o más con el mismo RFID o con la huella dactilar.

Información adicional.Tabla 1. Usuarios

Tabla 2: Estadísticas diarias

Nota: por cada entrada – salida realizada se debe repetir las 2 filas últimas de la tabla 2.

Tabla 3: Estadísticas mensuales

Nota: Por cada semana (4) se debe repetir las 2 filas últimas de la tabla 3

Tabla 4: Estadísticas por tipo

2. Análisis

Se realizará ahora la especificación de los requerimientos concertados inicialmente con el cliente del sistema a ser implementado. El enunciado presentado en la sección inmediatamente anterior describe en forma textual lo que se desea del sistema. En esta sección se efectuará una descripción más acorde con el contexto informático, usando notación UML y algunos artefactos como diagramas de clases, diagrama de casos de uso y diagramas de secuencia.

2.1 Análisis de Requerimientos

Se listan a continuación los requerimientos funcionales y no funcionales del sistema.

Requisitos Funcionales

REFERENCIA FUNCION CATEGORIAR1 Registrar usuarios EVIDENTER2 Estadísticas por día EVIDENTER3 Estadísticas por mes EVIDENTER4 Estadísticas por tipo de usuario EVIDENTER5 Ingresar por RFID EVIDENTER6 Salir por RFID EVIDENTER7 Ingresar por huella EVIDENTER8 Salir por huella EVIDENTER9 Registrar Huella EVIDENTE

R10 Iniciar Sesión(Administrador) OCULTOR11 Modificar datos Administrador EVIDENTER12 Comprobar datos de usuario EVIDENTE

Los requisitos no funcionales especifican las propiedades del sistema como las restricciones del entorno o de la implementación, rendimiento, dependencias con las plataformas, flexibilidad, extensibilidad y confiabilidad.

2.1 Casos de Uso

Un diagrama de casos de uso es un diagrama del sistema que contiene actorescasos de uso y sus relaciones. Para el Sistema Biométrico Digital RMI setienen los siguientes actores:

Usuario: es la instancia que realiza registros de ingresos y salidas en las porterías por parte de los usuarios a través de RFID o huella.

Administrador: es la persona autorizada en gestionar o registrar usuarios, además de buscar las estadísticas.

Cada forma en que los actores usan el sistema representa un caso de uso, es decir son fragmentos de funcionalidad del sistema que es de valor para los actores. Por tanto un caso de uso es una especificación de una secuencia de acciones que el sistema lleva a cabo interactuando con sus actores.

El siguiente diagrama ilustra este punto.

Diagrama de Casos de Uso

2.1.1 Alto Nivel

Caso de Uso Crear usuariosActores AdministradorPrioridad AltaDescripción Este caso de uso inicia cuando el

Administrador desea ingresar un nuevo usuario (con sus datos) en la servidor, y así generar un archivo con los datos del usuario.

Caso de Uso Modificar Datos AdministradorActores AdministradorPrioridad AltaDescripción Este caso de uso inicia cuando el

Administrador cambiar sus datos tales como identificacion y clae.

Caso de Uso Registrar HuellaActores AdministradorPrioridad AltaDescripción Este caso de uso inicia cuando el

Administrador genera la clave RFC, pero para ello el usuario debe haber registrado los datos, en caso contrario el usuario no estará habilitado para registrar su huella.

Caso de Uso Generar Estadísticas por díaActores Administrador

Caso de Uso Iniciar SesionActores AdministradorPrioridad AltaDescripción Este caso de uso inicia cuando el

Administrador, introduce su identificación y clave para acceder a acciones que maneja el sensor.

Prioridad AltaDescripción Este caso de uso inicia cuando el

administrador suministra una identificación y una fecha, el sistema le permitira ver las entradas/salidas realizadas por un usuario en una fecha determinada.El usuario debe haber sido creado previamente.

Caso de Uso Generar Estadísticas por mesActores AdministradorPrioridad AltaDescripción Este caso de uso inicia cuando el

administrador suministra una identificación y un mes, el sistema le permitira ver las entradas/salidas realizadas por un usuario y el numero de veces que uso el SBD en ese mes. El usuario debe haber sido creado previamente.

Caso de Uso Generar Estadísticas por tipo de usuario

Actores AdministradorPrioridad AltaDescripción Este caso de uso inicia cuando el

administrador suministra un mes el sistema le permitira ver las el numero de veces que usuario de cada tipo uso el SBD en ese mes. El usuario debe haber sido creado previamente.

Caso de Uso Ingresar RFIDActores UsuarioPrioridad AltaDescripción Este caso de uso inicia cuando el

Usuario selecciona la opción en el menú, y suministra una identificación, el sistema valida si el usuario existe buscando el archivo con esa identificación y en caso de ser afirmativo le permite el ingreso.

Caso de Uso Salir RFIDActores UsuarioPrioridad AltaDescripción Este caso de uso inicia cuando el

Usuario selecciona la opción en el menú, y suministra una identificación, el sistema valida si el usuario existe buscando el archivo con esa identificación y en caso de ser afirmativo le permite salir.

Caso de Uso Ingresar huellaActores UsuarioPrioridad AltaDescripción Este caso de uso inicia cuando el

Usuario selecciona la opción en el menú, el archivo rfid_id.txt, si el archivo existe lee la clave RFC y la compara con la que existe en el sistema, y en caso de ser afirmativo le permite el ingreso.

Caso de Uso Salir huellaActores UsuarioPrioridad AltaDescripción Este caso de uso inicia cuando el

Usuario selecciona la opción en el menú, el archivo rfid_id.txt, si el archivo existe lee la clave RFC y la compara con la que existe en el sistema, y en caso de ser afirmativo le permite salir.

Caso de Uso Confirmar EntradaActores UsuarioPrioridad AltaDescripción Este caso de uso inicia cuando el

caso de uso Ingresar RFID se inicia,despues de esto el sistema le pide al usuario ingresar el aellido paterno, el sistema valida si el apellido paterno correspode con la identificacion suministrada en el caso de uso Ingresar RFID, en caso de ser afirmativo le permite el ingreso.

3. Diseño

El diseño del sistema permite obtener una perspectiva tanto estática en cuanto a las relaciones entre los componentes identificados, como dinámica, en cuanto a la forma con la que se presenta interacción entre dichos componentes.

3.1. Diagrama de Clases

3.2. Diagrama de Secuencia

Se ilustrarán las acciones que conllevan el llamado a un procedimiento remoto, por medio del siguiente diagrama de secuencia.

Diagrama de secuencia de iniciar sesión

return boolean

login()

iniciarsesion(login)

iniciarsesion(login)

getObj()

btnIniciarActionPerformed(evt)

setArgs(String)

setObj(obj1)

lookup(String)

initComponents()

interfazLogin(args)Usuario

interfazLogin Obj:usuarioIntUsuario :Naming UsuarioImpl login

return boolean

login()

iniciarsesion(login)

iniciarsesion(login)

getObj()

btnIniciarActionPerformed(evt)

setArgs(String)

setObj(obj1)

lookup(String)

initComponents()

interfazLogin(args)

4. Arquitectura del sistema

El Sistema Biométrico Digital se diseñó de acuerdo a la siguiente arquitectura.

El directorio src contiene los archivos fuente escritos en el lenguaje Java, organizados en paquetes (equivalentes a carpetas en el entorno de Windows) de acuerdo a la funcionalidad que implementan. El directorio bin contiene los archivos con extensión .class, originados en el proceso de compilación de los archivos fuente .java, manteniendo la estructura de subdirectorios de src tal como se define en las siguientes figuras.

4.1. Distribución de archivos

5. Bibliografía

[1] http://es.wikipedia.org/wiki/Java_Remote_Method_Invocation[2] http://www.chuidiang.com/java/rmi/rmi.php