Proyecto Biometria

UNIVERSIDADE DA CORUÑA

FACULTADE DE INFORMÁTICA Departamento de Tecnoloxías da Información e as Comunicacións

PROXECTO FIN DE CARREIRA DE ENXEÑERÍA TÉCNICA EN

INFORMÁTICA DE XESTIÓN

Sistema de gestión de huellas dactilares en

formato digital

Autor: José Antonio Orgueira Pérez

Tutor: Antonino Santos del Riego

A Coruña, enero de 2003

Agradecimientos

A mis padres, familiares, amigos y compañeros de facultad porque sin ellos nada

sería posible.

A todos los que me ofrecieron su ayuda desinteresada en los foros de Internet

consultados.

A Nino, por todo.

A todos ellos, Gracias.

Sistema de Gestión de huellas

dactilares en formato digital

3

Resumen

Este proyecto constituye un acercamiento al ámbito de la biometría. En concreto, nos

centraremos en el reconocimiento de huellas dactilares, desarrollando un sistema

que, sobre el soporte de una base de datos, permita una gestión de las entidades

involucradas sobre una arquitectura cliente-servidor.

El sistema hará la autenticación de los usuarios a través de un dispositivo lector de

huellas dactilares. En el proceso de autenticación se utiliza el algoritmo de

comprobación de plantillas basadas en la obtención de minucias.

Tanto la gestión de la base de datos como las comprobaciones de usuarios registrados

estarán orientadas a la WEB, pudiéndose realizar cualquiera de las tareas a través de

un navegador.

Palabras claves Biometría, Autenticación, Reconocimiento, Huellas dactilares, Web, Tomcat,

Apache, Java, JSP, Javabeans, MySQL

Sistema de Gestión de huellas Índice


4

ÍNDICE

1. INTRODUCCIÓN 6

2. DOMINIO DE APLICACIÓN. AUTENTICACIÓN Y HUELLAS DACTILARES

2.1. Autenticación de usuarios 9

2.2. Autenticación biométrica 11

2.3. Huellas dactilares 15

3. ESTADO DEL ARTE

3.1. Huella digital por ultrasonidos 20

3.2. Los dedos de gelatina de Matsumoto 21

3.3. Algoritmo de huellas 23

4. METODOLOGÍA

4.1. Modelado 36

4.2. Lenguajes y herramientas 53

4.3. Diseño y desarrollo 74

5. VALIDACIÓN DEL SISTEMA 111

6. CONCLUSIONES 113

Sistema de Gestión de huellas Índice


5

ANEXO I: Manual del Administrador 114

ANEXO II: Comando de creación de tablas 127

BIBLIOGRAFÍA 129

DIRECCIONES WEB 131

ÍNDICE DE FIGURAS 132

ÍNDICE DE TABLAS 134

Introducción

6

1. INTRODUCCIÓN En el ámbito de las tecnologías de la seguridad, uno de los problemas

fundamentales a solventar es la necesidad de autenticar de forma segura la identidad

de las personas que pretenden acceder a un determinado servicio o recinto físico. De

este modo, surge la biometría, también conocida como técnicas de identificación

biométrica, con el objetivo de resolver este problema a partir de las características

propias de cada individuo, como la voz, huella dactilar, rostro, etc.

Éstas técnicas de identificación biométrica, frente a otras formas de autenticación

personal como el uso de tarjetas o PINes (Personal Identification Number), o número

de identificación personal, como el usado en cajeros automáticos, tienen la ventaja de

que los patrones no pueden perderse o ser sustraídos, ni pueden ser usados por otros

individuos en el caso de que lleguen a tener accesible nuestra tarjeta personal y, o,

PIN.

Se debe tener en cuenta que gran parte de los sistemas de autenticación actuales están

basados únicamente en el uso de una tarjeta personal y, o, un PIN, con sus

consecuentes problemas de seguridad.

Sea cual sea la técnica seleccionada para una determinada aplicación, tendremos que

ponderar en cada caso las restricciones o peculiaridades que pueden tener cada una

de las técnicas, frente al grado de seguridad añadido que conseguimos y del que

anteriormente no disponíamos. Estas características vienen dadas básicamente por

los siguientes aspectos:

ü Necesidad de un dispositivo de adquisición específico (lector de huella

dactilar, micrófono, cámara, etc.) allí donde esté el usuario.

Introducción

7

ü Posible variabilidad con el tiempo del patrón a identificar (afonías,

catarros en voz, uso de gafas/bigote/barba en el rostro, etc.).

ü Probabilidad de error individual de cada una de las técnicas (en función de

la técnica elegida).

ü Aceptación por parte del usuario de cada una de las técnicas, en función de

si son o no técnicas intrusivas, cómodas, que mantengan (o al menos lo

parezca) la privacidad, sencillas de usar, etc.

De este modo, en función de la situación en que necesitemos realizar una

autenticación segura del usuario, se buscará cuál es la técnica (ó combinación de

técnicas) biométrica más adecuada en función de los cuatro parámetros

fundamentales anteriormente mencionados.

En este contexto, el objetivo de este proyecto es el desarrollo de un sistema de

gestión de huellas dactilares en formato digital. Estamos interesados en que los

usuarios que lo soliciten puedan pasar a formar parte de nuestra base de datos, para

lo cual les permitiremos mandarnos sus datos y las imágenes digitalizadas de sus

huellas, pudiendo enviarnos un número variable de estas, una por cada uno de los

dedos.

Tras la solicitud, será el administrador del sistema el que se encargue, de la gestión

de la información generada (altas, bajas, modif.).

Por ultimo el sistema dispondrá de la posibilidad de la autenticación de un usuario

dado de alta previamente, donde se capturará la huella de esta persona y se

comparará contra la de la base de datos enviada con anterioridad.

Debemos para ello, desarrollar una base de datos, con los datos de interés sobre la

persona, así como con las imágenes digitalizadas de sus huellas.

Introducción

8

Todo el proceso se realizara a través de Internet, sobre una arquitectura

cliente-servidor.

Los objetivos principales del proyecto son:

ü Diseño y desarrollo de una base de datos con información sobre los

usuarios e imágenes de sus huellas dactilares.

ü Diseño y desarrollo del sistema de gestión.

ü Integración de un algoritmo de autenticación sobre las huellas facilitadas.

ü Validación del sistema.

Dominio de la aplicación

9

2. Domino de aplicación. Huellas dactilares en formato digital

2.1 Autenticación de Usuarios

En la actualidad uno de los requisitos primordiales de los sistemas informáticos son

los mecanismos de seguridad que han de incluir al menos un sistema que permita

identificar a las entidades (elementos activos del sistema, generalmente usuarios) que

intentan acceder a los objetos (elementos pasivos, como ficheros o capacidad de

cómputo), mediante procesos tan simples como una contraseña o tan complejos

como un dispositivo analizador de patrones de la retina.

Los sistemas que habitualmente utilizamos para identificar a una persona, como el

aspecto físico o la forma de hablar, son demasiado complejos para una computadora;

el objetivo de los sistemas de identificación de usuarios no suele ser identificar a una

persona, sino autenticar que esa persona es quien dice ser realmente. Aunque

seguramente ambos términos nos parecerán equivalentes, para una computadora

existe una gran diferencia entre ellos: imaginemos un sistema de identificación

biométrico basado en el reconocimiento de la retina; una persona miraría a través del

dispositivo lector, y el sistema sería capaz de decidir si es un usuario válido, y en ese

caso determinar de quién se trata; esto es identificación.

Sin embargo, lo que habitualmente hace el usuario es introducir su identidad (un

número, un nombre de usuario, etc.) además de mostrar sus retinas ante el lector. En

este caso, el sistema no tiene que identificar a esa persona, sino autenticarlo:

comprobar los parámetros de la retina que está leyendo con los registrados en una

base de datos como identificativos del usuario. En este caso, se está reduciendo el


10

problema de una población potencialmente muy elevada a un grupo de usuarios más

reducido, el grupo de usuarios del sistema que necesita autenticación.

Los métodos de autenticación se suelen dividir en tres grandes categorías, en función

de lo que utilizan para la verificación de identidad: (a) algo que el usuario sabe, (b)

algo que éste posee, y (c) una característica física del usuario o un acto involuntario

del mismo. Esta última categoría se conoce con el nombre de autenticación

biométrica.

Es fácil identificar ejemplos de cada uno de estos tipos de autenticación: un

password es algo que el usuario conoce y el resto de personas no, una tarjeta de

identidad es algo que el usuario lleva consigo, la huella dactilar es una característica

física del usuario.

Por supuesto, un sistema de autenticación puede, y debe, para incrementar su

fiabilidad, combinar mecanismos de diferente tipo, como en el caso de una tarjeta de

crédito unida al PIN de los cajeros automáticos o en el de un dispositivo generador

de claves para el uso de One Time Passwords.

Cualquier sistema de identificación (aunque se les llame así, recordemos que

realmente son sistemas de autenticación) ha de poseer unas determinadas

características para ser viable; obviamente, ha de ser fiable con una probabilidad muy

elevada, económicamente factible para la organización y ha de soportar con éxito

cierto tipo de ataques, por ejemplo, ataques por fuerza bruta.

Además de estas características se tiene otra, no técnica sino humana, pero quizás la

más importante: un sistema de autenticación debe ser aceptada por los usuarios, que

serán al fin y al cabo quienes lo utilicen. Por ejemplo, imaginemos un potencial

sistema de identificación para acceder a los recursos de la Universidad, consistente

en un dispositivo que fuera capaz de realizar un análisis de sangre a un usuario y así


11

comprobar que es quien dice ser; seguramente sería barato y altamente fiable, pero

nadie aceptaría dar un poco de sangre cada vez que desee consultar su correo.

2.2. Autenticación biométrica

A pesar de la importancia de la criptología en cualquiera de los sistemas de

identificación de usuarios, existe otra clase de sistemas en los que no se aplica esta

ciencia, o al menos su aplicación es secundaria. Es más, parece que en un futuro no

muy lejano estos serán los sistemas que se van a imponer en la mayoría de las

situaciones en las que se haga necesario autenticar a un usuario. En general son más

amigables para el usuario, no va a necesitar recordar passwords o números de

identificación complejos y, como se suele decir, el usuario se puede olvidar la tarjeta

de identificación en casa, pero nunca se olvidará de su mano o su ojo, y son mucho

más difíciles de falsificar que una simple contraseña o una tarjeta magnética. Las

principales razones por la que no se han impuesto ya en nuestros días es su elevado

precio, fuera del alcance de muchas organizaciones, y su dificultad de

mantenimiento.

Estos sistemas son los denominados biométricos, basados en características físicas

del usuario a identificar. El reconocimiento de formas, la inteligencia artificial y el

aprendizaje son las ramas de la informática que desempeñan el papel más importante

en los sistemas de identificación biométricos; la criptología se limita aquí a un uso

secundario, como el cifrado de una base de datos de patrones de retinas, o la

transmisión de una huella dactilar entre un dispositivo analizador y una base de

datos.


12

La autenticación basada en características físicas existe desde que existe el hombre y,

sin darnos cuenta, es la que más utiliza cualquiera de nosotros en su vida cotidiana: a

diario identificamos a personas por los rasgos de su cara o por su voz.

Obviamente aquí el agente reconocedor lo tiene fácil porque es una persona, pero en

el modelo aplicable a redes de comunicaciones el agente ha de ser un dispositivo que,

basándose en características del sujeto a identificar, gestione el acceso a un

determinado recurso.

Los dispositivos biométricos tienen tres partes principales:

ü Un mecanismo automático que lee y captura una imagen digital o analógica

de la característica a analizar.

ü Una entidad para manejar aspectos como la compresión, almacenamiento o

comparación de los datos capturados con los registrados en una base de

datos (que son considerados válidos).

ü Una interfaz de aplicaciones.

El proceso general de autenticación sigue unos pasos comunes a todos los modelos

de autenticación biométrica: captura o lectura de los datos que el usuario a validar

presenta, extracción de ciertas características de la muestra (por ejemplo, las

minucias de una huella dactilar), comparación de tales características con las

registradas en una base de datos, y decisión de si el usuario es válido o no.


13

En la figura 1 se muestra la estructura clásica del Diagrama de Bloques de un

Sistema de Reconocimiento Biométrico.

Adquisición dedatos

Autentificador

Extracciónde

Características

Preproc.de la

Señal

Algoritmo deReconocimiento

Obtención delos Modelos

de la BD

Decisión

Persona

Incógnita

Figura 1. Diagrama Sistema Reconocimiento Biométrico

Es en la Decisión donde principalmente entran en juego las dos características

básicas de la fiabilidad de todo sistema biométrico: las tasas de falso rechazo y de

falsa aceptación. Por tasa de falso rechazo (False Rejection Rate, FRR) se entiende la

probabilidad de que el sistema de autenticación rechace a un usuario legítimo porque

no es capaz de identificarlo correctamente, y por tasa de falsa aceptación (False

Acceptance Rate, FAR) la probabilidad de que el sistema autentique correctamente a

un usuario ilegítimo; evidentemente, una FRR alta provoca descontento entre los

usuarios del sistema, pero una FAR elevada genera un grave problema de seguridad,

proporcionando acceso a un recurso a personal no autorizado.


14

Para determinar las prestaciones de un sistema biométrico se suele utilizar la tasa de

éxito (Success Rate, SR) que responde a una combinación de los dos factores

anteriores:

SR= 1 – (FAR +FRR)

El FAR y el FRR responden a parámetros inversamente proporcionales, por tanto,

variarán en función de las condiciones prefijadas por el programa de identificación

biométrica. Así si por ejemplo se tiene que utilizar el programa en un entorno de

máxima seguridad, se intentará que el FAR sea lo más pequeño posible, aunque esta

acción signifique de forma explícita, el incremento drástico del factor FRR.

Por lo tanto se debe fijar un parámetro o umbral que permita igualar los dos factores,

asegurando de esta manera el óptimo funcionamiento del sistema. Este umbral se

denomina tasa de error igual (Equal Error Rate, ERR), y es el que determinará,

finalmente, la capacidad de identificación del sistema. En la figura 2 se muestra la

relación dicha relación.

Figura 2. Relación entre FAR, FRR y ERR


15

2.3. Huellas dactilares

Típicamente la huella dactilar de un individuo ha sido un patrón bastante bueno para

determinar su identidad de forma inequívoca, ya que está aceptado que dos dedos

nunca poseen huellas similares, ni siquiera entre gemelos o entre dedos de la misma

persona. Por tanto, parece obvio que las huellas se convertirían antes o después en un

modelo de autenticación biométrico: desde el siglo pasado hasta nuestros días se

vienen realizando con éxito clasificaciones sistemáticas de huellas dactilares en

entornos policiales, y el uso de estos patrones fue uno de los primeros en establecerse

como modelo de autenticación biométrica.

Cuando un usuario desea autenticarse ante el sistema sitúa su dedo en un área

determinada, el área de lectura. Aquí se toma una imagen que posteriormente se

normaliza mediante un sistema de finos espejos para corregir ángulos, y es de esta

imagen normalizada de la que el sistema extrae las minucias (ciertos arcos, bucles y

remolinos de la huella) que va a comparar contra las que se tiene en la base de datos.

Es importante resaltar que el sistema no analiza la huella en sí sino las minucias,

concretamente la posición relativa de cada una de ellas.


16

Figura 3. Huella dactilar con minucias

Las huellas de los dedos presentan como característica principal, la presencia de un

conjunto de crestas o partes donde la piel se eleva sobre las partes más bajas o valles

existentes entre las crestas. Con respecto a estas crestas se definen dos características

particulares que obedecen al termino de minucias:

ü Final de cresta (ridge ending). Característica definida como el punto donde

la cresta acaba de forma abrupta.

ü Bifurcación de la cresta (ridge bifurcation). Característica definida como el

punto en el que la cresta se bifurca en dos o más crestas.

Estas dos características quedan unívocamente definidas a partir de su localización

(coordenadas x, y respecto al sistema de coordenadas central de la imagen) y de su

orientación (ángulo θ).


17

Está demostrado que dos dedos nunca pueden poseer más de ocho minucias

comunes, y cada uno tiene al menos entre 30 y 40 de éstas. En la figura 3 se muestra

una imagen de una huella digitalizada con sus minucias. Si la comparación de las

posiciones relativas de las minucias leídas con las almacenadas en la base de datos es

correcta, se permite el acceso al usuario, denegándose obviamente en caso contrario.

Los sistemas basados en reconocimiento de huellas son relativamente baratos, en

comparación con otros biométricos, como los basados en patrones de retinas. Sin

embargo, tienen en su contra la incapacidad temporal de autenticar usuarios que se

hayan podido herir en el dedo a reconocer. Un pequeño corte o una quemadura que

afecte a varias minucias pueden hacer inútil al sistema. También elementos como la

suciedad del dedo, la presión ejercida sobre el lector o el estado de la piel pueden

ocasionar lecturas erróneas.

Estado del Arte

18

3. Estado del Arte

Algunos aeropuertos experimentan tecnologías de seguridad que basadas en el

reconocimiento del iris y la mano. La identificación dactilar es uno de los más

extendidos; el rostro, el menos invasivo. La asignatura pendiente, la estandarización.

Poner el dedo en un escáner, hablar por un micrófono o mirar de cerca a una cámara

puede ser suficiente para pasar el control de seguridad y acceder a una instalación o

sistema informático. La tecnología biométrica ha traspasado los laboratorios de

espionaje, recintos militares y gubernamentales para extender sus aplicaciones al

mercado empresarial y de consumo.

Algunos expertos consideran que el reconocimiento del rostro puede ser la

herramienta más útil para la identificación en aeropuertos. Las cámaras de seguridad

graban a distancia y permiten comparar las capturas con bases de datos de imágenes.

De hecho, uno de estos sistemas se utilizó en la última edición de la final de fútbol

americano, la Super Bowl, celebrada en Tampa, Florida.

Los aeropuertos de San Francisco y Nueva York emplean sistemas que reconocen la

geometría de la mano de los empleados. El mismo sistema se utiliza en el aeropuerto

israelí de Tel Aviv para los pasajeros frecuentes de las líneas aéreas El Al. En

Heathrow (Londres) se está realizando una experiencia con 2.000 pasajeros

norteamericanos de las aerolíneas British Airways y Virgin Atlantic (deben estar

registrados y grabar el iris en una base de datos).

En la actualidad la extensión masiva de estos sistemas se ve frenada por la falta de

estándares. Demasiados sistemas propietarios. Microsoft, uno de los fundadores del

BioAPI, estándar propuesto en 1995 por el Biometric Consortium patrocinado por el

Estado del Arte

19

Gobierno de Estados Unidos, salió del grupo de 60 empresas y agencias para crear su

propia tecnología. El Departamento de Defensa cuenta con una organización y un

laboratorio de biométrica, donde prueba la utilidad de los más de 600 productos

existentes en el mercado. El Departamento de Energía desarrolla un escáner

holográfico que analizará, a través de ondas de radio y en tres dimensiones a los

pasajeros para comprobar si esconden armas.

La industria está concentrada en los sistemas de identificación dactilar. En general,

son los más económicos; los más baratos sobre los 120 € .

Los expertos consideran que para no atentar contra la intimidad una de las mejores

opciones es usar sistemas híbridos que almacenen los datos biométricos en tarjetas

inteligentes e infraestructuras de clave pública. De esta forma se evita que la

información se encuentre en bases de datos. En la actualidad están en estudio

sistemas que analizan el olor humano, las venas de la mano o la forma de andar.

Estado del Arte

20

3.1 Huella digital por ultrasonidos

Este esquema funciona por ultrasonidos, lo que evita los fallos que hasta ahora se

producían con la lectura óptica por suciedad en la piel o en el dispositivo de escaneo.

La empresa valenciana especializada en tecnologías de seguridad Mundiscan

Electronic Systems ha presentado recientemente el primer sistema infalible de

identificación por huella dactilar basado en ultrasonidos.

Se trata de una tecnología desarrollada en la última década, que ha demostrado una

alta fiabilidad al extraer los rasgos más característicos e inequívocos de las personas

para posteriores procesos de identificación. Este nuevo sistema, sustituye al de

identificación por huella dactilar basado en la tecnología óptica.

Esta última tecnología ocasionaba problemas debido a las dificultades de lectura, si

la piel o el dispositivo de escaneo se encontraban sucias, algo que provocaba

consecuentemente un rechazo en el mercado. Mundiscan Electronic Systems es la

única empresa que a través del uso de los ultrasonidos ha conseguido superar este

problema imponiendo un método de identificación infalible. La tecnología es

aplicable a los controles de edificios que requieren un alto nivel de seguridad como

aeropuertos, bancos, sedes gubernamentales, empresas privadas, instalaciones

militares o prisiones.

El sistema biométrico por ultrasonidos consiste en el envío de ondas de diferentes

frecuencias que rebotan contra la base de la huella y el dispositivo de escaneo,

penetrando cualquier tipo de suciedad encontrada en los dedos como grasa, polvo o

manchas de tinta. De esta forma, se obtiene una imagen sin errores de las crestas y

los valles del dedo escaneado, consiguiendo una gran precisión en la captura de la

imagen que facilitará los procesos identificativos posteriores.

Estado del Arte

21

3.2 Los dedos de gelatina de Matsumoto

Recientemente ha salido publicada una noticia que está provocando un debate

sobre la valoración de la biometría: un criptógrafo japonés llamado

Matsumoto ha descubierto un método para engañar con un "dedo de gelatina" a 11

sensores biométricos en el 80% de los intentos.

El estudio se basa en conseguir una huella artificial que engañe a los sistemas de

autenticación. El profesor Matsumoto muestra como conseguir artificialmente una

huella que puede servir como la original.

Hacer una huella artificial directamente de una huella real:

ü Materiales: Plástico moldeable, lámina de gelatina sólida

ü Como hacer un molde: Poner el plástico en agua caliente para ablandarlo,

presionar el dedo contra el, obteniendo el molde.

ü Preparación del material: Mezclar la gelatina con un liquido en una

proporción del 50 %, añadir agua hirviendo (30cc) a la gelatina sólida (30g)

en una botella y mezclarlos.

ü Como hacer una huella falsa: Verter el líquido en el molde, meterlo en un

refrigerador para que enfríe y se obtiene la huella.

Matsumoto ha realizado el test sobre 11 dispositivos biométricos en el mercado. No

olvidemos que existen dispositivos con biosensor que garantizan que con un dedo de

gelatina no va a poder realizarse la intrusión.

Estado del Arte

22

Dependiendo del nivel de seguridad deseado se puede optar por una solución de

seguridad más efectiva, por ejemplo, el uso de biosensores, cámaras de vigilancia,

combinaciones de varias biometrías, combinaciones con smart cards y PinPad, etc.

Al igual que con cualquier sistema de seguridad, existen vulnerabilidades y

soluciones para las mismas. Por primera vez se está dotando de una inteligencia a

nuestras máquinas por medio del reconocimiento preciso del usuario que interactúa

con el sistema, y esto solo lo podemos conseguir con reconocimiento biométrico.

El “dedo de gelatina” ha provocado un avance en algunos fabricantes y para otros,

más previsores, les ha confirmado algo que podía pasar.

De todas formas, todos ellos día a día siguen realizando test de otro tipo de posibles

vulnerabilidades para crear una evolución y un acercamiento asintótico al punto

limite de seguridad del 100%.

Estado del Arte

23

3.3 Algoritmos de huellas

Autenticación significa comprobar si un individuo es quien dice ser. El algoritmo de

autenticación que se utiliza en el presente proyecto, está formado por dos bloques: en

primer lugar se extraen las minucias características de la huella “actual” del usuario

que se va a autenticar (algoritmo de extracción de minucias) y, en segundo lugar, se

comparan esas minucias características de su huellas con las minucias almacenadas

en la base de datos en forma de “plantilla” (algoritmo de comparación de minucias).

Cuando hablamos de huella “actual”, se hace referencia a la huella situada sobre el

lector de huellas dactilares (también huella “en vivo”), mientras que la “plantilla” se

corresponde con las características extraídas de una huella anteriormente,

normalmente para ser almacenada en una base de datos.

Se dice que un usuario ha sido autenticado si las características extraídas de la huella

“actual” coinciden con las de la “plantilla” dentro de un límite de tolerancia para el

algoritmo de comparación de minucias.

3.3.1 Algoritmo de extracción de minucias

Una de las tareas más importantes en un sistema de reconocimiento de huellas es la

extracción de las minucias de una imagen capturada de una huella. Debido a las

imperfecciones de la imagen adquirida, en algunos casos el algoritmo de extracción

puede obviar algunas minucias, y en otros se pueden añadir minucias falsas . Las

imperfecciones de la imagen pueden también generar errores al determinar las

coordenadas de cada minucia y su orientación relativa en la imagen.

Estado del Arte

24

Todos estos factores contribuyen a disminuir la fiabilidad del sistema de

reconocimiento, puesto que el reconocimiento de huellas dactilares está basado en la

comparación, dentro de unos límites de tolerancia, del patrón biométrico, o conjunto

de minucias extraídas, adquirido “en vivo” y el almacenado.

A continuación describiremos en profundidad cada una de las fases de este algoritmo

y lo que se consigue en estas.

3.3.1.1 Normalización de la imagen

El objetivo de esta fase es disminuir el rango de variación de grises entre los valles y

las crestas de la imagen para facilitar el proceso en las siguientes etapas.

Figura 4. (a)Huella original (b) Huella normalizada

3.3.1.2 Cálculo del campo orientación

El campo orientación representa la orientación local de las crestas que contiene la

huella. Para estimarlo, la imagen se divide en bloques de 16x16 píxeles y se calcula

la inclinación para cada píxel, en coordenadas x e y. Debido a la carga

Estado del Arte

25

computacional del proceso de reconocimiento, es suficiente aplicar una máscara de

3x3 píxeles para el calculo de la inclinación en cada píxel.

Figura 5. (a) Huella orientada (b) Campos realineados

El ángulo de orientación se calcula a partir de la información de la inclinación.

Frecuentemente, en algunos bloques, el ángulo de orientación no se calcula

correctamente debido a ruidos y daños en los valles y las crestas de la imagen

capturada. Como no pueden existir variaciones significativas del ángulo entre

bloques adyacentes, se aplica un nuevo filtro “espacial” de 5x5 píxeles al campo

orientación estimado para reordenar correctamente todos los segmentos. La figura

5(a) muestra el campo orientación obtenido a partir del cálculo de la inclinación. La

figura 5(b) muestra los campos realineados después de aplicar el filtro “espacial”.

3.3.1.3 Selección de la zona de interés

Debido a que la imagen contiene “ruido” de fondo, el algoritmo puede generar

minucias fuera del área ocupada por la huella. Para evitar este problema, se

selecciona el área de imagen, definida por todos los bloques de 16x16, en la que

existe una alta variación del nivel de grises en la dirección normal de las crestas

existentes (el campo orientación normal de las crestas se había calculado

Estado del Arte

26

previamente). Después de esto el área de la imagen con ruido, que será excluido en

las siguientes etapas, se define por bajas variaciones en todas las direcciones. En la

figura 6 se muestran las variaciones de una huella y la región de interés obtenida a

partir de esta.

Figura 6. (a) Variaciones de la huella (b) Región importante

3.3.1.4 Extracción de crestas

Para decidir si un píxel pertenece o no a una cresta dada, es necesario filtrar la

imagen de la huella con dos máscaras adaptables, ambas capaces de incrementar el

nivel de gris el la dirección normal de la cresta. La orientación de la máscara se

adapta a cada bloque de 16x16 píxeles, dependiendo los ángulos obtenidos del

campo orientación realineados de la figura 5(b).

Si el nivel de gris de un píxel excede un umbral en las dos imágenes filtradas, se

considera que el pixel pertenece a la cresta; de otra forma se asigna a un valle,

produciendo una imagen binaria de la huella. Las dimensiones de la máscara son

LxL y están definidas por las ecuaciones dadas en (1) y (2).

Estado del Arte

27

( ) ( )[ ]

+−=⋅Π=

−

−

caso otroen , 0

:si , 2

1),( 0

1

20

cc

uu

uctgvvEuevuh θδ

δ

( ) ( )[ ]

+−=⋅

Π=

−

−

caso otroen , 0

:si , 2

1),( 02

20

cc

vv

vtguuEvevuh θδ

δ

[ ]Lvu ,1, ∈∀

donde u y v son las coordenadas de un píxel en la máscara; (uc, vc) es el centro de la

máscara; θ, es el ángulo de orientación de la cresta en cada bloque de la imagen, y δ,

es un parámetro para ajustar la función máscara al ancho de la cresta. La figura 7(a)

muestra la imagen filtrada con una de las máscaras “espaciales”. La figura 7(b)

representa la imagen binaria obtenida después de aplicar un umbral, produciendo

bordes de crestas lisos.

Figura 7. (a) Imagen filtrada (b) Imagen binaria obtenida

Estado del Arte

28

3.3.1.5 Perfilar las crestas

Para simplificar el proceso en las siguientes etapas, se filtra la imagen para perfilar

las crestas de la huella y eliminar las manchas de ciertas áreas. Para conseguir esto,

se extraen primero los componentes de baja frecuencia y a continuación se eliminan

a la imagen original, proporcionando los componentes de alta frecuencia necesarios

para perfilar las crestas, como se deduce de:

[ ] [ ] [ ] [ ] [ ] [ ]( )vufvufvufvufvufvup LH ,,,,,, −⋅+=⋅+= λλ

donde p[u,v], es el resultado de perfilar la imagen; f[u,v], es la imagen binaria;

fH[u,v] y fL[u,v] son, respectivamente, las imágenes de alta y baja frecuencia; y λ es

un factor (λ>0), que determina el grado de perfilación. En la figura 8(a) se muestra el

resultado de la huella después de aplicarle el primer filtro. Se puede aplicar un

nuevo filtro para eliminar las crestas falsas debidas a manchas en la imagen. En este

caso se utiliza una máscara “espacial” capaz de adaptar su orientación localmente a

la orientación de la cresta.

Figura 8 . (a) Imagen después del primer filtro perfilador (b) Imagen

después del segundo filtro perfilador con máscara espacial

Estado del Arte

29

3.3.1.6 Simplificación

En este paso se aplican dos algoritmos consecutivos paralelos de simplificación, para

reducir a un único píxel el ancho de las crestas en la imagen binaria. Estas

operaciones son necesarias para simplificar es siguiente análisis estructurale de la

imagen para la extracción de las minucias de la huella.

La simplificación se debe realizar sin modificar la estructura original de las crestas

de la imagen. Durante este proceso, el algoritmo no puede calcular mal los

comienzos, finales y, o bifurcaciones de las crestas, ni las crestas se pueden romper.

3.3.1.7 Eliminar imperfecciones

Después de la simplificación, dependiendo de la calidad de la imagen, las

imperfecciones estructurales de la huella original permanecen en un cierto grado.

Esto conlleva crestas rotas, crestas falsas y huecos; así que, es necesario aplicar un

algoritmo para eliminar todo las líneas que no se corresponden a crestas y un

algoritmo para enlazar crestas rotas. La figura 9(a) muestra la imagen adelgazada

obtenida una vez aplicado el algoritmo de adelgazamiento y eliminación de

imperfecciones.

Figura 9. (a) Imagen después de la simplificación y eliminación de imperfecciones

(b) Patrón de minucias después del proceso de eliminación de conjuntos

Estado del Arte

30

3.3.1.8 Extracción de minucias

En la última etapa, se extraen las minucias de la imagen simplificada, obteniendo el

patrón biométrico de la huella (plantilla). Este proceso conlleva la determinación de:

(i) si un píxel pertenece o no a una cresta y, (ii) si es así, si es una bifurcación,

comienzo o final de cresta obteniendo así un grupo de candidatos a minucias. A

continuación, todos los puntos en el borde de la zona de interés se borran. Entonces,

puesto que la densidad de minucias por unidad de área no puede exceder un cierto

valor, todos los conjuntos de puntos candidatos cuya densidad excede este valor son

sustituidos por una simple minucia localizada en el centro del conjunto. En la figura

9(b) se muestra el patrón de minucias resultante.

Una vez finalizado el proceso de extracción de minucias la plantilla contiene entre

70 y 80 minucias. En la figura 10 se muestra el patrón de minucias obtenido

superpuesto sobre la imagen de la huella normalizada:

Figura 10. Patrón de minucias

Estado del Arte

31

3.3.2. Algoritmo de comparación de minucias

Con el emparejamiento se determina si dos huellas son del mismo dedo o no. Las dos

características usadas en el emparejamiento de huellas son los finales y las

bifurcaciones de las crestas (minucias).

A continuación se explica en detalle cada una de las etapas del algoritmo de

comparación de minucia:

Para cada minucia detectada, se almacenan los siguientes parámetros:

ü Coordenadas x e y de la minucia.

ü Orientación definida como la orientación local de la cresta asociada.

ü El tipo de minucia, que puede ser final de cresta o bifurcación.

ü La cresta asociada.

Para la comparación de las minucias se utilizarán las coordenadas polares de estas.

3.3.2.1 Alineación del conjunto de minucias

Si denotamos por P al conjunto M de minucias en la imagen plantilla tenemos que:

( ) ( )( )TPM

PM

PM

TPPP yxyxP θθ ,,,...,,, 111=

y llamando Q al conjunto de N minucias en la imagen de “entrada” (la que se va a

compara con la imagen plantilla) tenemos:

Estado del Arte

32

( ) ( )( )TQN

QN

QN

TQQQ yxyxQ θθ ,,,...,,, 111=

Para cada minucia Pi )1( Mi ≤≤ y Qj )1( Nj ≤≤ en el conjunto de minucias de la

imagen de “entrada” y de la plantilla, denotamos rotate[i][j] como el ángulo de

rotación entre la imagen de “entrada” y la plantilla, tomando Pi y Qj como el punto

de referencia de la imagen. Si podemos tomar Pi y Qj como un par de minucias, las

crestas asociadas de Pi y Qj son iguales dentro de un cierto grado rotate[i][j], que

asumiremos de un valor entre 0 y 360, en otro caso pondremos rotate[i][j] como 400

para representar el hecho de que Pi y Qj no se corresponden con un par de minucias.

Figura 11. Alineación de la cresta de entrada y la cresta plantilla

Si Pi y Qj no son del mismo tipo, se asigna 400 a rotate[i][j]. Por otra parte

denotaremos por R y r a las crestas a las que pertenecen de las minucias Pi y Qj . Se

compara R con r para obtener las diferencias de estas dos crestas de acuerdo a la

ecuación siguiente:

∑ =−= L

i ii drdRL

distDiff0

)()(1

_

Estado del Arte

33

∑ =−= L

i ii rRL

angDiff0

)()(1

_ αα

Donde L es el número de puntos grabados. R(di) es la distancia desde el punto i en la

cresta R a la minucia Pi. R(α i ) es el ángulo entre la línea que conecta el punto i

sobre la cresta R a la minucia Pi y la orientación de la minucia Pi ; r(di ) y r(α i )

tienen significados similares.

Si Diff_dist es más grande que Td o diff_ang es mayor que To, se pone rotate[i][j] a

400. De otra forma calculamos rotate[i][j] como:

Rotate[i][j] = dir_Temp – dir_in

Donde dir_temp es la orientación de Pi y dir_in es la orientación de Qj.

Para alinear el conjunto de minucias de entrada con el conjunto de minucias de la

plantilla en la coordenada polar, lo que se necesita hacer es trasladar las minucias de

la imagen de entrada y las de la plantilla a coordenadas polares con respecto a las

minucias de referencia Pi y Qj, y a continuación añadir el ángulo rotate[i][j] al

ángulo radial de la coordenada polar de cada minucia de “entrada”. Es decir, para

una minucia (xi, yi, θi)T aplicamos la siguiente ecuación:

( ) ( )[ ][ ]

−

+

−−

−+

=

−

−

ri

ri

ri

ri

ri

i

i

i

jirotatexx

yyyxxx

e

r

θθθ

1

22

tan

Donde (xr, yr, θr)T es la coordenada de la minucia de referencia, y (ri, ei, θi)T es la

representación de la minucia en el sistema de coordenadas polares (ri representa la

Estado del Arte

34

distancia radial, ei representa el ángulo radial, y θi ; representa la orientación de la

minucia con respecto a la minucia de referencia).

3.3.2.2 Comparación de las minucias alineadas

Los pasos del algoritmo de comparación de minucias son los siguientes:

1) Para )1( Mii ≤≤ y )1( Njj ≤≤ , si rotate[i][j]=400, se repite este paso y se

elige otro Pi y Qj , sino se va al paso 2. Si se ha hecho para todos los pares de

minucias, se va al paso 5.

2) Poner Pi y Qj como minucia de referencia. Convertir cada minucia en el

conjunto de minucias de la plantilla y conjunto de minucias de entrada al

sistema de coordenadas polares con respecto a la correspondiente minucia de

referencia a través del método descrito al final de la sección 2.1.

3) Representar las minucias de la plantilla y de la entrada en el sistema de

coordenadas polares como cadenas simbólicas, concatenando cada minucia

en orden creciente de ángulos radiales:

( ) ( )( )TpM

pM

pM

Tpppsi ererP θθ ,,,...,,, 111=

( ) ( )( )TQN

QN

QN

TQQQsi ererQ θθ ,,,...,,, 111=

4) Comparar las cadenas resultantes Pis y Qj

s para encontrar el nivel de

coincidencia de Pis y Qj

s. Asignar a m_score[i][j] el valor del resultado.

Continuar en el paso 1.

Estado del Arte

35

5) Encontrar el máximo valor de m_score[i][j] y usarlo como el nivel de

coincidencia del conjunto de minucias de la entrada y la plantilla. Si el nivel

de coincidencia es mayor que un umbral, se considera que la imagen de

“entrada” se originó a partir de la misma huella que la plantilla, sino se

considera que las dos imágenes provienen de dedos diferentes.

36

4. Metodología

Para el desarrollo del proyecto, seguiremos una metodología clásica, que incluirá los

siguientes pasos:

1. Modelado. Análisis del dominio de la aplicación.

a. Estudio de los actores del sistema

b. Estudio de los casos de uso

c. Estudio de las clases del dominio

d. Estudio y desarrollo de la base de datos

2. Selección de las herramientas de desarrollo

3. Diseño y desarrollo de la(s) aplicación(es)

4. Validación de la arquitectura resultante

4.1 Modelado

En primer lugar se hace un análisis del problema, usuarios, requisitos funcionales,

etc. Para ello utilizaremos el Lenguaje Universal de Modelado (“Unified Modeling

Language”, UML en lo sucesivo) pues constituye un estándar utilizado ampliamente

en el desarrollo de software.

Puesto que va a ser este el lenguaje que vamos a utilizar para modelar nuestra

aplicación, haremos una breve introducción y resaltaremos sus principales

características:

Lenguaje Unificado de Modelado

37

4.1.1. El Lenguaje Unificado de Modelado

El UML es un estándar para escribir “planos” de software. El UML se puede utilizar

para visualizar, especificar y documentar los artefactos de un sistema que involucran

una gran cantidad de software.

El UML es apropiado para modelar desde sistemas de información en empresas hasta

aplicaciones distribuidas basadas en Web, como es este caso, e incluso para sistemas

de tiempo real.

Es un lenguaje muy expresivo, que cubre todas las vistas necesarias para desarrollar

y luego desplegar tales sistemas.

El UML es un lenguaje y por lo tanto se constituye como un método de desarrollo de

software. UML es independiente del proceso, aunque para utilizarlo

óptimamente se debería usar en un proceso que fuese dirigido por los casos de uso,

centrado en la arquitectura, iterativo e incremental.

Un lenguaje proporciona un vocabulario y las reglas para combinar palabras de ese

vocabulario con el objetivo de posibilitar la comunicación. El lenguaje de modelado

es un lenguaje cuyo vocabulario y reglas se centran en la presentación conceptual y

física de un sistema.

El modelado proporciona una compresión del sistema. Nunca es suficiente un único

modelo. Más bien, para comprender cualquier cosa, a menudo se necesitan múltiples

modelos conectados entre sí, excepto en los sistemas más triviales. Para sistemas con

una gran cantidad de software, se requiere un lenguaje que cubra las diferentes vistas

de la arquitectura de un sistema mientras evoluciona a través del ciclo de vida del

desarrollo del software.


38

El vocabulario y las reglas de un lenguaje como el UML indican cómo crear y leer

modelos bien formados, pero no dicen que modelos se deben crear ni cuando se

deberían crear. Esta es la tarea del proceso de desarrollo de software.

UML es un lenguaje para visualizar

UML es algo más que un simple montón de símbolos gráficos. Mas bien detrás de

cada símbolo en la notación UML hay una semántica bien definida. De esta manera,

un desarrollador puede escribir un modelo en UML, y otro desarrollador, o incluso

otra herramienta, puede interpretar ese modelo sin ambigüedad.

UML es un lenguaje para especificar

En este contexto, especificar significa construir modelos precisos, no ambiguos y

completos. UML cubre la especificación de todas las decisiones de análisis, diseño e

implementación que se deben de realizar al desarrollar y desplegar un sistema con

gran cantidad de software.

UML es un lenguaje para construir

UML no es un lenguaje de programación visual, pero sus modelos se pueden

conectar de forma directa con una gran variedad de lenguajes de programación, entre

los que está Java. Esta correspondencia permite ingeniería directa, la generación de

código a partir de un modelo UML en un lenguaje de programación.

UML es un lenguaje para documentar

Una organización de software que trabaje bien produce toda clase de artefactos

además de código ejecutable: requisitos, arquitectura, diseño, código fuente, etc.

Tales artefactos no son solo los entregables de un proyecto, también son críticos en el

control, la medición y comunicación que requiere un sistema durante su desarrollo y

después de su despliegue.


39

El UML cubre toda la documentación de la arquitectura de un sistema y todos sus

detalles. UML también proporciona un lenguaje para expresar requisitos y pruebas.

Finalmente, UML proporciona un lenguaje para modelar las actividades de

planificación de proyectos y gestión de versiones.

Actores del sistema

40

4.1.2. Actores del sistema

Nuestro sistema cuenta con dos tipos de usuarios, llamados actores en UML.

Admin i s t rado rU s u a r i o

Figura 12. Actores del sistema

Actor Administrador: Es el encargado de mantener los datos de la base de datos.

Su trabajo consiste en dar altas, bajas y modificaciones de los usuarios en la base de

datos. Todo su trabajo podrá ser realizado a través de la web, previa autenticación

biométrica, de la que se encarga el servidor.

Actor usuario: Representa la persona que hace el envío de la imagen de su huella así

como los datos referentes a ella, a través de la web, para pasar a formar parte de la

base de datos. Tiene también la posibilidad de autenticarse para verificar que su

huella y datos se han incorporado a la base de datos.

Casos de uso

41

4.1.3 Casos de uso

Casos de uso del Actor Administrador

En la figura 12 se muestra el diagrama de casos de uso para el actor

“Administrador”.

A d m i n i s t r a d o r

( f r o m A c t o r e s )

A u t e n t _ a d m i n

G e s t i ó n

< >

A l t a _ a d m i n

M o d i f i c a c i ó n V i s u a l i z a c i ó n

< >

< >

B a j a

< >

< >

< >

< >

Figura 13. Casos de uso de Administrador

Casos de uso

42

El caso “Gestión” es el más general, representa la interacción del administrador con

el sistema, cuando realiza las tareas de administración. Hace uso, además del caso de

uso “Autenti_admin.”, que autenticará al administrador.

El caso “Autenti_admin” representa la autenticación del actor ante el sistema, que

nos permitirá tener control sobre los privilegios correspondientes a cada actor.

Para este caso de uso se va a usar la autenticación biométrica, que nos va a asegurar

el acceso exclusivo, por parte del administrador, a las páginas desde las que se

realizan las tareas de administración (altas, bajas, modificaciones).

El caso de uso “Alta del administrador” (Alta_admin.) tiene como fin introducir un

usuario, que previamente lo halla solicitado, en la base de datos de nuestra

aplicación. Para ello lo que realiza es el cambio de valor de un campo de la tabla de

usuarios.

Se trata de cambiar el campo Alta de ‘F’ a ‘T’, es decir de False a True. De este

modo un usuario con el campo Alta a ‘T’ estará dado de alta en la base de datos,

mientras que uno que lo tenga a ‘F’, se encontrará en espera.

El caso de uso “Baja” borrará de la base de datos a un usuario, tanto los datos

personales como los datos de las huellas enviadas. En este último punto se

eliminarán físicamente las imágenes de las huellas, así como las plantillas generadas

a partir de estas.

Casos de uso

43

La “Modificación” se encarga como su propio nombre indica de la modificación de

los datos referentes a un usuario (excepto la clave primaria), que ya halla sido dado

de alta en la base de datos. Se mostrarán, en primer lugar, los datos actuales de un

usuario, y se le permitirá al administrador introducir los cambios que desee, para

luego actualizar estos datos en la base de datos.

La “Visualización” consiste, en un primer momento, en dar una lista de los usuarios

de la base de datos, para a continuación mostrar todos los datos que constan

referentes al usuario seleccionado.

Por lo tanto este proceso se realizará para altas, bajas y modificaciones con el fin de

que el administrador sepa en todo momento lo que está realizando. Así primero se

visualizarán todos los usuarios y una vez seleccionado uno, se le mostrará la

información completa referente a este, para que confirme la operación que está a

punto de realizar.

Casos de uso

44

Casos de uso del Actor Usuario

La figura 13 representa los casos de uso del actor “Usuario”.

A l t a _ n u e v o _ u s u

A u t e n t i c a r

g e n e r a r _ p l a n t i l l a

A l t a _ u s u a r i o

< >U s u a r i o

( f r o m A c t o r e s )

A l t a _ e x i s t e n t e _ u s u

Figura 14. Casos de uso Usuario

El caso de uso “Alta” realizado por los usuarios vía web, se especializa en dos: en

primer lugar están los usuario que por primera vez solicita el alta en nuestra base de

datos, en segundo lugar tenemos a los usuarios que ya hayan solicitaron el alta en

algún momento y posteriormente deciden enviar alguna otra huella.

Para el primer caso (Alta_nuevo_usu), se le presentará al usuario un formulario para

que introduzca tanto los datos personales como, la posibilidad de enviar una imagen

de cada una de sus huellas.

Casos de uso

45

En el segundo caso (Alta_existente_usu), el usuario ya realizó en algún momento el

caso anterior, y decide enviar más huellas. Para este caso, el usuario se tendrá que

identificar para confirmar que ya consta en la base de datos, y se le dará la

posibilidad del envió de imágenes nuevas.

El caso de uso “Autenticar” representa la validación final del sistema, ya que

consiste en la comprobación de la identidad de un usuario que con anterioridad haya

pasado a formar parte de la base de datos.

Se autentica la huella “en vivo” de un usuario con la plantilla generada en el

momento del alta. Si el dedo que en ese momento está sobre el lector pertenece a un

usuario que ,con anterioridad, había enviado la huella de ese mismo dedo, la

autenticación será exitosa. En caso contrario se le indicará el motivo del fracaso: bien

porque no es un usuario registrado o bien porque estando en la base de datos no

coincide el dedo que tiene sobre el lector con alguna de las imágenes de huellas que

haya enviado.

El caso “Generar plantilla” genera una plantilla a partir de una imagen. Esta plantilla

almacena las características (minucias) extraídas de la huella, que la van a hacer

única. De esta manera guardamos información referente a la persona, pero que no la

compromete en ningún momento, utilizándose para autenticar la huella en “vivo”.

La utilización de estas plantillas tiene como principal ventaja el tamaño de estas, ya

que mientras una imagen de una huella ocupa unos 100 Kb, la plantilla nos ocupa

aproximadamente 1 Kb , y reúne toda información utilizada en el algoritmo de

autenticación, que nos va a servir para diferenciar unas huellas de otras.

Lenguajes y Herramientas

46

4.1.4. Base de Datos

La aplicación de gestión de huelas dactilares se basa en el mantenimiento de una

base de datos que recoge toda la información referente a los usuarios y sus huellas

dactilares. Por lo tanto, necesitaremos crear esa base de datos.

La base de datos va a estar formada por tres tablas con las que mantenemos la

información sobre los usuarios en una de ellas (tabla usuarios), información sobre las

huellas en la otra (tabla huellas), y una última en la que mantendremos la

información que concierne al administrador (tabla admin).

En el desarrollo de esta base de datos utilizaremos un enfoque entidad-relación, para

posteriormente, convertir el modelo resultante en un modelo relacional, que será

implementado directamente en el sistema gestor de base de datos elegido.

En primer lugar, realizaremos un análisis de los requisitos de nuestro sistema.

ü Referente a la persona, nos interesan sus datos personales, dirección,

teléfono, etc, siendo el identificador único de cada persona su DNI.

ü Cada persona podrá hacer un envío entre una y diez imágenes de huellas,

una por cada uno de sus dedos.

ü Las huellas se asociarán a los usuarios por medio del DNI de estos.

ü Las huellas se asociarán a una mano y a un dedo de la persona que los

envió.


47

ü A partir de cada huella se generará una plantilla característica de la misma,

que agilizará el proceso de autenticación.

ü Para la autenticación del administrador se mantendrá una plantilla, extraída

a partir de su huella, en la base de datos.

En nuestro caso mantendremos en la base de datos tanto las imágenes de las huellas

como las plantillas generadas. Este no es el procedimiento habitual ya que

precisamente la ventaja de almacenar las plantillas es la de no guardar información

relevante del usuario, como lo son sus huellas. Además, a partir de las plantillas no

hay forma de reconstruir las huellas, por lo que la identidad del usuario está

totalmente protegida.

Otra ventaja de los sistemas biométricos que almacenan las plantillas características

de las personas, es que estas plantillas son del orden de 100 veces menores que las

imágenes a partir de las que se generan. Por lo tanto, la base de datos será

considerablemente menor.

De lo expuesto anteriormente, obtenemos la lista de candidatos a entidades del

dominio y otra con las posibles relaciones.

Ca Candidatos a Entidades Ca Candidatos a Relaciones

US USUARIO TI TIENE: huella

H HUELLA PE PERTENECE: usuario

SS ADMINISTRADOR T

Tabla 1. Candidatos a Entidad y Relación


48

4.1.4.1. Modelo Entidad-Relación

Para un estudio de la estructura de los elementos del dominio, así como de sus

relaciones, utilizaremos el modelo Entidad-Relación (ER). La figura 14 muestra el

modelo entidad-relación resultante:

Usuario Administrador

Persona

Huella

Nombre

Dirección

Pais

Provincia

Localidad

CP

email

http

id_persona

NombrePlantilla

id_huella

mano

dedo

plantilla

1

N

Figura 15. Modelo Entidad-Relación


49

4.1.4.2. Diccionario de datos

Entidad Administrador

Persona que, como su nombre indica, se va a encargar de administrar la base de datos

de usuarios y huellas.

Atributos:

ID_ADMINISTRADOR Numérico. Clave principal.

NOMBRE Nombre del Administrador.

PLANTILLA Plantilla generada a partir de la huella.

Clave Principal: ID_ADMINISTRADOR

Clave alternativa: NOMBRE

Entidad Huella

Imagen digitalizada de la huella enviada por un usuario.

Atributos:

ID_HUELLA Clave principal de la huella

ID_USUARIO Identificador del usuario al que pertenece la huella.

MANO Mano a la que pertenece la huella.

DEDO Dedo al que pertenece la huella.

PLANTILLA Plantilla que se obtiene a partir de la imagen

Clave principal: ID_HUELLA


50

Entidad Usuario

Persona que nos envía su/s huella/s en formato digital y que pasarán a formar parte

de nuestra base de datos.

Atributos:

ID_USUARIO Numérico. Clave principal.

NOMBRE Nombre del Usuario.

DIRECCIÓN Dirección donde reside el usuario, será una cadena de

texto.

C.P. Código Postal del lugar de residencia del usuario.

LOCALIDAD Localidad de residencia del usuario.

PROVINCIA Provincia de residencia del usuario.

PAIS País de residencia del usuario.

EMAIL Dirección correo del usuario.

WEB Página web del usuario.

ALTA Estado en el que se encuentra (T/F).

Clave Principal: ID_USUARIO


Relación Huella – Usuario

Relación “tener”. Una huella concreta pertenece a un usuario, mientras que un

usuario tiene desde una a diez posibles huellas en la base de datos. Por lo tanto,

estamos ante una relación 1:N.


51

4.1.4.3. Modelo Relacional

El estudio del modelo entidad-relación nos lleva al siguiente esquema de tablas, que

compone un modelo relacional completo del dominio de la aplicación.

Tabla Administradores

ID_ADMINISTRADOR Entero No nulo

NOMBRE Texto No nulo

PLANTILLA Texto No nulo

Clave principal: ID_ADMINISTRADOR

Dependencias Funcionales

ID_ADMINISTRADOR -> NOMBRE, PLANTILLA

3º Forma Normal

Tabla Usuarios

ID_USUARIO Entero No nulo

NOMBRE Texto No nulo

DIRECCIÓN Texto No nulo

C.P. Entero

LOCALIDAD Texto

PROVINCIA Texto

PAIS Texto

EMAIL Texto

WEB Texto

ALTA Texto No nulo


52

Clave principal: ID_USUARIO



ID_USUARIO -> NOMBRE, DIRECCIÓN, C.P., LOCALIDAD, PROVINCIA ,

PAIS, EMAIL, WEB

NOMBRE -> ID_USUARIO, DIRECCIÓN, C.P., LOCALIDAD, PROVINCIA ,

PAIS, EMAIL, WEB

3º Forma Normal

Tabla Huellas

ID_HUELLA Texto No nulo

USUARIO Entero No nulo, Clave foránea

MANO Texto No nulo

DEDO Texto No nulo

PLANTILLA Texto No nulo

Clave principal: ID_HUELLA

Clave foránea: USUARIO referencia ID_USUARIO en tabla Usuarios.


ID_HUELLA -> USUARIO, MANO, DEDO, PLANTILLA.

3º Forma Normal


53

4.2 Lenguajes y herramientas

4.2.1 Programación Web

La idea de usar la Web como un entorno de aplicaciones se fue desarrollando con el

tiempo, de modo que cada etapa de innovaciones tecnológicas servía de trampolín

para la aparición de nuevas ideas. El primer modelo operativo consistía simplemente

en un servidor Web que enviaba los documentos que se le pedían. En este entorno, el

contenido no cambiaba a no ser que alguien proporcionara una nueva versión del

documento. La figura 15 muestra este entorno.

Navegador Web Servidor Web

GET/doc.html

<HTML>...<HTML>

Figura 16. Modelo de servidor de documentos estáticos

Documentos HTML


54

HTTP (Hypertext Transfer Protocol) es un protocolo de petición/respuesta simple en

el que el navegador Web solicita un documento, normalmente utilizando el comando

GET, y el servidor Web devuelve el documento en forma de un flujo de datos HTML

(Hypertext Markup Language), precedido por unas cuantas cabeceras descriptivas.

Rápidamente se hizo evidente que si una persona podía revisar los documentos

gestionados por el servidor Web, también podía hacerlo un programa de texto

procesado como una secuencia de comandos Perl. El navegador Web no aprecia la

diferencia porque el resultado de una petición HTTP sigue siendo un flujo de datos

en HTML. Más aún, el navegador puede enviar algo más que una simple petición:

puede enviar parámetros, incluyéndolos en la URL (Universe Reason Locate) o

enviando un flujo de datos con la petición. Esto sugiere que una petición HTTP

puede interpretarse como una consulta a una base de datos y los resultados de la

consulta se pueden usar para construir dinámicamente un documento HTML. Con el

desarrollo del servidor Web NCSA HTTPd llegó una nueva especificación, los CGI

(Common Gateway Interface).

El servidor Web invoca a un programa CGI como respuesta a cierto tipo de

peticiones, generalmente peticiones de documentos de un directorio concreto o

nombres de fichero con una extensión específica, como por ejemplo .cgi. Los

parámetros de la petición se pasan como pares clave/valor y las cabeceras de

respuesta como variables de entorno. El programa lee estos parámetros y las

cabeceras, realizan la tarea de la aplicación con la que se está trabajando, y entonces

genera una respuesta HTTP. La respuesta se envía al navegador Web solicitante

como si fuera un documento estático corriente.


55

La figura 16 ilustra el flujo del proceso.


GET/cgi-bin/pgm

<HTML>…</HTML>

Figura 17. Contenido dinámico generado por una secuencia de comandos CGI

Los CGI normalmente generan un nuevo proceso para cada petición HTTP. Esto

supone un problema cuando el tráfico es escaso, pero provoca sobrecarga cuando el

nivel de tráfico aumenta. En esta situación, los CGI no se ajusta, a nuestras

necesidades.

Se produjo una mejora significativa con la parición, en 1997, de la API Servlet de

Java, que fue seguida rápidamente por la API JSP (acrónimo de Java Server Pages,

las Paginas Java en servidor). Esta tecnología lleva todo el potencial de Java al

servidor Web, con conectividad a base de datos, acceso a trabajo en red, operaciones

de subprocesos y, sobre todo, un modelo de proceso diferente.

Programa CGI

Base de datos


56

Los servlets y las páginas JSP operan desde un solo ejemplar o instancia que

permanece en la memoria y utiliza múltiples subprocesos para responder a distintas

peticiones de forma simultánea. La figura 17 muestra ilustra el uso de esta

tecnología.


GET / requestURI

<HTML>…</HTML>

Figura 18. Aplicaciones dinámicas usando servlets, JSP y J2EE.

Motor de servlets

Página JSP

Servicios J2EE

Base de datos

Otros servicios

Servlets


57

El modelo de aplicación Web ha ido evolucionando a medida que la Web ha ido

madurando y la experiencia lograda en cada fase ha determinado los requisitos para

la siguiente. La oleada inicial de Java en cliente en forma de applets fue muy

popular, pero acabó causando decepción al aplicarse en la práctica. La utilidad de los

applets estaba limitada por el considerable número de incompatibilidades entre

navegadores, por los excesivos períodos de descarga con modems lentos y por las

restricciones de seguridad. Debido a esto el desarrollo de los applets se hizo más

lento y la tecnología Java en servidor se convirtió en el mayor área de crecimiento.

Java en el servidor no sufre las restricciones del entorno applet. No aparecen

inconsistencias del navegador porque no es necesario que este posea una máquina

virtual Java. El navegador sólo tiene que generar HTML, y esto lo puede hacer

razonablemente bien hasta los navegadores más antiguos. No es precisa la

configuración del cliente ni la descarga desde otros recursos de extensos archivos de

clase. Del mismo modo, las consideraciones de seguridad se limitan a aquellas ya

gestionadas por el servidor Web, que está normalmente en un entorno cerrado con

controles separados.


58

4.2.2 El lenguaje Java

Para el uso de la API del lector tenemos varias posibilidades: una es el uso de la API

C/C++ que nos viene con la documentación del dispositivo de huellas dactilares

disponible, y que nos llevaría a la utilización de la tecnología CGI del lado del

servidor; la otra posibilidad con la que contamos es el uso de Java aprovechando las

clases Java (java wrappers) que nos vienen con el entorno de desarrollo para el

programador.

El uso de CGI nos llevaría a utilizar la tecnología de Microsoft ASP (Active Server

Pages) para la generación dinámica de páginas, y todo ello trabajando bajo el

Servidor de Microsoft (IIS). Por el otro lado el uso de Java como leguaje de servidor

nos llevaría a utilizar JSP (Java Server Pages) para la generación dinámica de

páginas; pudiendo optar por una serie de servidores que funcionen como

contenedores de servlets: JRun, Tomcat, etc.

Hemos optado por el uso de Java y sus tecnologías Servlets, JSP y Javabeans como

lenguaje para el desarrollo de los distintos módulos de la aplicación por

una serie de motivos que discutimos a continuación:

Java presenta una serie de ventajas frente a otros lenguajes, entre los cuales

destacamos los siguientes:

ü Seguridad

El modelo de seguridad de Java tiene tres componentes

principales: el cargador de clases, el verificador bytecode y

SecurityManager.


59

El verificador bytecode se asegura de que el programa se haya compilado

correctamente, que obedezca a las restricciones de acceso de la VM (Virtual

Machine, en castellano Maquina Virtual) y que el programa no acceda a

datos privados sino tiene que hacerlo.

El cargador de clases según recupera las clases de la red de trabajo, se

almacenan en servidores Web independientes, de esta forma se evita que

cargue por error una clase que pretenda ser un complemento a la clase

principal o que interfiera en el proceso de carga de las clases procedentes de

otro servidor.

SecurityManager es el encargado de establecer la política de acción de la

VM. La política de seguridad determina las actividades que puede efectuar

la VM y bajo qué casos.

ü Core API

La interfaz Core API proporciona un conjunto de funciones comunes a

todas las plataformas que puedan trabajar con Java.

La interfaz se divide en paquetes, que son grupos de clases que pueden

desarrollar una serie de funciones. En uno de estos paquetes se encuentra

las bases del lenguaje de programación, tales como el control de texto y

proceso de errores.

ü Estándares abiertos

En la actualidad la VM se puede utilizar con más de una decena de

combinaciones de hardware y sistemas operativos. Los archivos escritos en

este lenguaje no se han de compilar en todas las plataformas.


60

Lo importante es que dichas plataformas trabajen con la VM. Una

aplicación en Java que se escriba hoy, se ejecutará en todas las plataformas

que trabajen con la VM, aunque aún no se haya creado.

ü Distribuido y dinámico

El cargador de la VM busca los archivos class que se encuentran en una red

o en un disco duro, proceso completamente transparente al usuario,

haciendo que la distribución de las aplicaciones en Java sea completamente

transparente. Estas propiedades permiten que el explorador compatible con

Java se adapte automáticamente a los protocolos que obtiene desde un

nuevo sitio Web.

ü Orientada a objetos

La Programación Orientada a Objetos, u Object Oriented Programming

(OOP), es una forma de escribir un software que se puede volver a utilizar y

cuyo mantenimiento es realmente sencillo. Java es un lenguaje de

programación orientado a objetos. De hecho, Core API es un conjunto de

componentes OOP que se conoce como librería class. Las librerías class

permiten que los programadores se ahorren muchos dolores de cabeza

cuando han de desarrollar nuevos proyectos.

ü Multitarea

Una aplicación monotarea tiene un thread (hilo de proceso) que será quien

se encargue de ejecutar todo lo que se le pida. Con este sistema únicamente

puede desarrollar una tarea cada vez.


61

Las aplicaciones multitarea pueden utilizar varios thread a la vez durante la

ejecución. Estos thread se comunican entre sí, por lo que podrán cooperar

entre ellos pareciendo, de cara al usuario, que el programa lo está

ejecutando un único thread, pero más rápido que con las aplicaciones

monotarea.

ü Administración de memoria y recolección de “basura”

El sistema recupera la memoria temporal en el momento tras cierta cantidad

de tiempo sin que el programa activo la solicite. De esta forma se libera al

desarrollador de una parte tediosa del trabajo.

La ingeniería de componentes ha hecho posible que se lleven a cabo grandes

avances en hardware y en tecnología electrónica. La programación basada en

componentes lleva esta idea al mundo del software. En el ámbito Java , esto es lo que

significa JavaBeans.

Un bean de Java es un componente elemental reutilizable de software. Se trata de

bloques de construcción que sirven para crear aplicaciones.

Para que los beans funcionen sólo se necesita la VM Java. Esto permite que los

beans bien construidos se utilicen en cualquier entorno Java: applets, servlets,

páginas JSP o aplicaciones Java autónomas.

Por su parte , los servlets son clases Java que amplían la funcionalidad de un servidor

Web mediante la generación dinámica de páginas Web. Un entorno de ejecución

denominado motor de servlets administra la carga y descarga del servlet, y trabaja

con el servidor Web para dirigir peticiones a los servlets y enviar la respuesta a los

clientes.

Puesto que hemos optado por la utilización de servlets en detrimento de la interfaz

CGI, vamos a explicar alguna de sus ventajas principales:


62

ü Rendimiento

La tecnología CGI normalmente inicia un nuevo proceso para gestionar

cada petición que les llega. Los servlets, al contrario, se cargan cuando se

solicitan por primera vez y permanecen indefinidamente en la memoria. El

motor de servlets carga un solo ejemplar o instancia de la clase Servlet y le

lanza peticiones empleando un conjunto de subprocesos disponibles

(threads o hilos). La mejora del rendimiento con este sistema es

considerable.

ü Simplicidad

Los servlets se ejecutan en una VM en un entorno de servidor controlado y

solo necesitan el HTTP básico para comunicarse con sus clientes. No es

preciso que el cliente tenga un software especial, ni siquiera en los

navegadores antiguos.

ü Sesiones http

Aunque los servidores HTTP no tienen capacidad para recordar detalles de

una petición previa del mismo cliente, la interfaz API Servlet proporciona

una clase HttpSession que permite superar esta limitación.

ü Acceso a la tecnología Java

Al ser aplicaciones Java, los servlets tienen acceso directo a toda la gama de

características Java, como el uso de subprocesos, acceso a redes y

conectividad a base de datos.


63

ü Comunicación

Como cada invocación de un programa CGI desencadena un proceso

independiente, la comunicación entre ellos se debe hacer con frecuencia a

través de ficheros, lo que puede ralentizar bastante la operación. Si estos

programas pertenecen a un mismo servidor, su intercomunicación suele ser

igualmente problemática.

ü Seguridad

Algunas variantes de CGI tienen graves problemas de seguridad. Aunque se

utilicen los últimos estándares o lenguajes relativamente seguros, el sistema

no ofrece garantías suficientes de protección.

Una Página Java en servidor,o “Java Server Pages” (JSP) es una plantilla para una

página Web que emplea código Java para generar un documento HTML

dinámicamente. Las páginas JSP se ejecutan en un componente del servidor

conocido como contenedor de JSP, que las traduce a servlets Java equivalentes.

Por esta razón los servlets y las páginas JSP están íntimamente relacionados. Lo que

se puede hacer con una tecnología es, en gran medida, también posible con la otra;

aunque cada una tiene sus capacidades propias. Como son servlets, las páginas JSP

tienen todas las ventajas de los servlets, pero además tienen ventajas propias:

ü Se vuelven a compilar automáticamente cuando es necesario.

ü Como están en el espacio común de documentos del servidor Web, dirigirse

a ellas es más fácil que dirigirse a los servlets.

ü Como las páginas JSP son similares al HTML, tienen mayor compatibilidad

con las herramientas de desarrollo Web.


64

JavaScript es un lenguaje de programación creado por Netscape con el objetivo de

integrarse en HTML y facilitar la creación de páginas interactivas sin necesidad de

utilizar scripts de CGI o Java.

El código de programa de JavaSript, llamado script, se introduce directamente en el

documento HTML y no necesita ser compilado, es el propio navegador el que se

encarga de “traducir” dicho código.

Gracias a JavaScript podemos desarrollar programas que se ejecuten directamente en

el navegador (cliente) de manera que éste pueda efectuar determinadas operaciones o

tomar decisiones sin necesidad de acceder al servidor.


65

4.2.3 Herramientas

Apache ha sido desarrollado por diversos de usuarios que han tenido que reparar sus

fallos alguna vez y que han agregado funciones al software del servidor web,

disponible en los primeros días de la World Wilde Web.

Es uno de los mejores servidores de Web utilizado en la red Internet desde hace

mucho tiempo, únicamente le hace competencia un servidor de Microsoft, el IIS. Por

lo que éste servidor es uno de los mayores triunfos del software libre.

La configuración y administración de Apache está basada en un sistema de ficheros,

editable desde un editor de textos. Las características principales de Apache son las

siguientes:

ü Permite instalar los servicios de aplicación CGI, Perl y Java.

Opcionalmente, y como medida común de acceso a Internet por los equipos

de la empresa, dispone de un servicio proxy, permitiendo especificar la

seguridad de acceso a Internet, así como impedir el acceso no deseado

desde el exterior.

ü Implementa los últimos protocolos, aunque se base en HTTP/1.1

ü Puede ser adaptado a diferentes entornos y necesidades, con los diferentes

módulos de apoyo y con la API de programación de módulos.

ü Incentiva la realimentación de los usuarios, obteniendo nuevas ideas,

informes de fallos y parches para solucionar los mismos.


66

ü Funciona sobre un gran número de plataformas (Unix, Linux, Vms,

Win32,OS2).

ü Módulos cargados dinámicamente.

ü Utilización de SSL para transacciones seguras.

ü Soporte para host virtuales.

ü Alto desempeño.

Para conseguir que nuestro servidor web sea un servidor seguro, es conveniente

utilizar la tecnología SSL (Secure Socket Layer) que detallamos a continuación:

SSL es una tecnología desarrollada por Netscape en 1994 junto con su primer

navegador, para asegurar la privacidad y fiabilidad de las comunicaciones entre dos

aplicaciones. Utiliza un sistema de cifrado asimétrico basado en claves

pública/privada para negociar una clave de sesión que se utilizará para establecer

una comunicación basada en cifrado simétrico. SSL es el protocolo de cifrado más

utilizado en Internet en estos momentos y es el más usado en servidores web donde

se solicita información confidencial, además es abierto y de dominio público, y su

implementación es sencilla.

La seguridad de SSL actualmente proporciona servicios de cifrado de datos, servidor

de autenticación, integridad de mensaje y autenticación de cliente para una conexión

TCP/IP.


67

ü Cifrado de datos

La información transferida se cifra utilizando un algoritmo de clave secreta,

capaz de cifrar grandes volúmenes de información en muy poco tiempo, por

lo que resultará ininteligible en manos de un atacante, garantizando así la

confidencialidad.

ü Autenticación de servidores

El usuario puede asegurarse de la identidad del servidor al que se conecta y al

que posiblemente envíe información personal confidencial. De esta forma se

evita que un usuario se conecte a un servidor “impostor” que haya copiado las

páginas del servidor al que suplanta. Estos ataques se conocen como Web

spoofing, y se utilizan para hacerse con las contraseñas y números de tarjeta

de crédito de los usuarios.

ü Integridad de mensajes

Se impide que pasen inadvertidas modificaciones intencionadas o

accidentales en la información mientras “viaja” por Internet.

ü Autenticación de cliente

Permite al servidor conocer la identidad del usuario, con el fin de decidir si

puede acceder a ciertas áreas protegidas. En este caso, el cliente debe tener

instalado un certificado en su computadora o en una tarjeta inteligente, que le

permitirá autenticarse ante el servidor web. Se evitan así ataques comunes de

captación de contraseñas mediante el uso de analizadores de protocolos

(sniffers) o el ataque por fuerza bruta con contraseñas.


68

SSL puede tener una clave de sesión de 40 bits o de 128 bits, dicha clave es

generada en cada transacción. La longitud de la clave hará más difícil romper el

cifrado. La mayoría de los navegadores soportan una clave de 40 bits para sesiones

SSL, mientras que las últimas versiones soportan claves de sesión de 128 bits.

Las funciones son:

ü Verificación de la Identidad

Emitir al servidor del cliente un Certificado Digital único, asegurándole la

autenticidad a las personas que visitan su servidor web y permitiendo que

las comunicaciones se cifren para obtener una mayor privacidad, y

confiabilidad en las transacciones de comercio o de comunicaciónes.

ü Mantener la seguridad

Un servidor SSL debe mantener la seguridad e integridad de la información

a través del método de clave pública/privada.

ü Facilidad de Utilización

A pesar de la gran seguridad que debe tener, el servicio debe ser de fácil

uso para los clientes sin grandes traumatismos que ocasionen confusiones.

Utilizaremos Apache como servidor de páginas web estáticas, y lo enlazaremos con

Tomcat, trabajando este como contenedor de servlets. De esta forma liberamos de

trabajo a Tomcat, que lo utilizamos solo cuando realmente necesitamos la potencia

de Java, y utilizaremos Apache para el resto, aprovechando su robustez.


69

Tomcat, uno de los proyectos de código abierto liderado por la Apache Software

Foundation, es una aplicación web basada en Java creada para ejecutar servlets y

páginas JSP, siendo la implementación oficial de referencia de las especificaciones

Servlet 2.3 y JSP 1.2.

Hemos decidido la utilización de Tomcat por los siguientes motivos:

ü Es “gratuito” y de “código libre”.

ü Utilizaremos JSP para la generación dinámica de páginas.

ü Nos permitirá la utilización de JavaBeans que nos facilitará implementar la

lógica de la aplicación en base a componentes, con lo que conseguimos

programar nuestra aplicación orientada a objetos.

ü Proporciona una total integración con el sistema operativo Windows

NT/2000/XP.

Además para realizar la tarea de transferir un fichero al servidor, desde nuestras

páginas JSP, hemos utilizado un módulo desarrollado en Java, totalmente gratuito y

disponible en la red, es el JspSmartUpload.

JspSmartUpload es un paquete de clases Java, que nos permitirán transferir ficheros

a nuestro servidor. En nuestro caso utilizaremos este módulo para que los usuarios

que lo deseen nos transfieran las imágenes digitalizadas de sus huellas dactilares.


70

Vamos a explicar alguna de las características de este paquete:

ü Simple y Completo

Solo se necesitan unas pocas líneas de código en nuestra aplicación JSP

para realizar la tarea de transferir ficheros. Provee todas las características

que se necesitan para transferir uno o más ficheros al servidor web usando

un navegador. De la misma forma, todos los ficheros pueden ser registrados

en una base de datos.

ü Control total sobre el proceso de subida de ficheros

Los objetos y métodos del módulo jspSmartUpload, permiten el acceso a

toda la información sobre los ficheros transferidos (tamaño, nombre, tipo,

extensión, etc.), incluso sin salvar los ficheros a disco.

ü Gestión de formularios mixtos

JspsmartUpload proporciona un control total sobre formularios mixtos,

cargando tanto campos de ficheros como campos de formularios.

ü Control total sobre los ficheros enviados

Las características restrictivas de jspSmartUpload permiten mantener un

control total sobre los ficheros transferidos al servidor. Por ejemplo, se

puede limitar la transferencia de ficheros de acuerdo al tamaño y tipo de los

mismos.


71

Para albergar nuestra base de datos tenemos una gran cantidad de sistemas gestores

de bases de datos. Barajando las distintas características de cada uno finalmente

hemos optado por el uso de MySQL.

Una característica importante es que consume muy pocos recursos, tanto de CPU

como de memoria. Se sacrificaron algunas características esenciales en sistemas más

“serios” con este fin

Ventajas

ü Buenos rendimientos. Mayor velocidad tanto al conectar con el servidor

como al servir consultas.

ü Utilidades de administración (backup, recuperación de errores, etc).

ü Control de acceso, en el sentido de qué usuarios tienen acceso a qué

tablas y con qué permisos.

JDBC (Java Data Base Connectivity) proporciona una interfaz estándar con el

servidor de base de datos. Provee una API que podemos usar sin importar qué base

de datos se esté usando.

La conectividad de la base de datos de Java es un marco de programación para los

desarrolladores de Java que escriben los programas que tienen acceso a la

información en bases de datos, hojas de calculo, y archivos "planos". JDBC se utiliza

comúnmente para conectar un programa con una base de datos, sin importar qué

software de administración o gestor de base de datos se utilice para controlarlo. De

esta manera, JDBC es una plataforma cruzada . La figura 18 muestra un esquema de

uso de la interfaz JDBC:


72

Figura 19. Interfaz JDBC

Sin importar la localización, la plataforma, o el programa piloto de la fuente de datos

(Oracle, Microsoft, etc.), el JDBC se conecta con una fuente de datos

proporcionando una colección de extensiones (class) que contienen las clases

abstractas de la interacción de la base de datos. La ingeniería del software en los

programas con JDBC también conduce a la reutilización modular.

Para poder acceder a MySQL desde nuestras aplicaciones necesitaremos un “driver”.

Utilizaremos la ultima versión disponible en su la página oficial de MySQL, el

MySQL Connector/J 3.0.1

Mysql Connector es un “driver” creado por Mysql AB que nos permitirá trabajar con

Mysql desde programas escritos en Java. A diferencia de otros “drivers”, este es de

libre distribución, y tiene un buen rendimiento.

MySQL Connector/J es un “driver” nativo de Java que convierte las llamadas

generadas por JDBC en el protocolo de red que utiliza la base de datos de Mysql.

Permite al desarrollador trabajar con el lenguaje de programación Java y de esta

Driver ODBC

Driver Sybase

Driver Oracle

Base Access

Base Sybase

Base Oracle

Interfaz JDBC


73

forma construir programas que interactuan con Mysql.

Analizando todas estas opciones hemos decidido utilizar las siguientes

tecnologías en el desarrollo del presente proyecto:

ü Sistema gestor de base bases de datos MySQL.

ü JDBC para el acceso a la base de datos utilizando SQL.

ü Apache como servidor de páginas web estáticas.

ü Generación dinámica de páginas con JSP sobre el servidor Tomcat.

ü Javabeans para implementar nuestra aplicación totalmente orientada a

objetos, utilizando clases Java.

ü El paquete Jspsmartupload para transferir los ficheros al servidor de nuestra aplicación.

Diseño e Implementación

74

4.3 Diseño y desarrollo

4.3.1 Despliegue

La figura 19 muestra el diagrama de despliegue de la aplicación.

Servidorde la

aplicación

Computadoradel Usuario

Terminaldel

Administrador

Lector dehuellas

ServidorWeb

Basede

Datos

Figura 20. Despliegue de la aplicación


75

La aplicación reside en el servidor de la aplicación, con acceso directo a la base de

datos. Tanto las tareas de los usuarios como las del administrador se podrán realizar

desde un simple navegador desde sus computadoras personales, conectándose vía

web al servidor de la aplicación.

4.3.2 Gestión

La figura 20 muestra el esquema de los distintos paquetes software desarrollados, así

como sus dependencias.

C l a s e s J a v a

C l a s e s D o m i n i o

C l a s e s

A u x i l i a r e s

C l a s e s

j s p S m a r t U p l o a d

C l a s e s I n t e r f a z

C l a s e s

m y S q l - c o n n e c t o r

C l a s e s

F i n g e r p r i n t

Figura 21. Paquetes de la aplicación


76

4.3.2.1 Clases Java

Este paquete representa las clases nativas de Java. Entre las que se encuentran las

incluidas en los paquetes estandares: java.lang., java.util., java.io., java.awt., etc.

4.3.2.2 Clases Auxiliares

Este paquete contiene las clases desarrolladas para facilitar la aplicación. La

figura 21 muestra estas clases.

t E l e m e n t o

ID

( f r o m L o g i c a l V i e w )

S u p e r c l a s e

g e n é r i c a d e

c u a l q u i e r c l a s e d e l

d o m i n i o

t P e r s o n a

i d _ p e r s o n a


t i m a g e n

i d _ i m a g e n


L i s t a r M o s t r a r

C l a s e p a r a l i s t a r

e l c o n t e n i d o d e

l a b a s e d e

d a t o s

r e c o g e r

C l a s e p a r a

m o s t r a r t o d o s l o s

d a t o s r e f e r e n t e s a

u n u s u a r i o

C l a s e q u e n o s

f a c i l i t a e l m a n e j o d e l

v a l o r d e l o s c a m p o s

d e l o s f o r m u l a r i o s

Figura 22. Clases Auxiliares.


77

4.3.2.3 Clases Dominio

Las clases del dominio son el resultado del planteamiento del problema, en la forma

de situaciones sacadas del mundo real. La figura 22 muestra el diagrama de clases

del dominio.

t P e r s o n a

i d _ p e r s o n a


U s u a r i o

n o m b r e

d i r e c c i ó n

c . p .

l o c a l i d a d

p r o v i n c i a

p a i s

e s t a d o

a l t a _ u s u ( )

a u t e n t i c a r ( )

a c t u a l i z a r ( )

r e c u p e r a r ( )

i n i c i a l i z a r ( )


H u e l l a

i d _ u s u

m a n o

d e d o

p l a n t i l l a

a l t a ( )

g e n e r a r _ p l a n t i l l a ( )

b o r r a r ( )

i n i c i a l i z a r ( )

r e c u p e r a r ( )


t E l e m e n t o

ID


t i m a g e n

i d _ i m a g e n


A d m i n i s t r a d o r

l o g i n

p a s s w o r d

a l t a _ a d m i n ( )

b a j a ( )

l o g i n ( )


Figura 23. Clases del dominio


78

4.3.2.4 Clases Interfaz

Este paquete contiene las clases propias de la interfaz de la aplicación, son clases que

se utilizan para mostrar y capturar información referente a las clases del dominio. En

el caso de nuestra aplicación se trata de páginas, tanto html como jsp. La figura 23

muestra el diagrama de clases de la interfaz.

a d _ a l t a

I n d e x

a d _ m o d i f

u s u _ a l t a a u t e n t i c a c i ó n

a d _ b o r r a r

a u t e n t i _ a d m i n

u s u _ h u e l l a s

Figura 24. Clases Interfaz

Cada clase representa una página alojada en nuestro servidor, que nos mostrará la

información que necesitemos en cada momento en función de la tarea que se vaya a

realizar.

Index: Esta clase representa la página de inicio de nuestra aplicación y desde la que

se podrá acceder a cada página en función de lo que se desee hacer.


79

PAGINAS ADMINISTRADOR

Autenti_admin: En esta página se pide al administrador que se identifique ante el

sistema, se utilizará autenticación biométrica para controlar el acceso a las páginas

desde las que realizar las tareas de administración.

Opción Alta Administrador

ad_alta: Esta clase representa la página en la que se muestran los usuarios que estén

en la base de datos, en espera de ser dados de alta, para que el administrador decida a

quien desea dar de alta.

Opción Baja Administrador

ad_borrar: Lista los usuarios dados de alta, para que el administrador decida a quien

quiere dar de baja.

Opción Modificar Administrador

ad_modif.: Clase encargada de mostrar los usuarios que están dados de alta en la

base de datos, para que el administrador elija el que desee modificar.

PAGINAS USUARIO

Opción Alta nuevo usuario

Usu_alta: Muestra el formulario que debe rellenar el usuario nuevo que quiera pasar

a formar parte de nuestra base de datos, tanto con campos para los datos personales

como para que nos envíe los ficheros con las imágenes.


80

Opción enviar huellas Usuario existente

Usu_huellas: En caso está pensado para aquel usuario que ya solicitó pasar a formar

parte de la base de datos, y que pasado un tiempo decide mandar nuevas huellas. Se

le solicita que se identifique como usuario existente y se le permite mandar nuevas

huellas.

Opción Autenticar Usuario

Autenticación: En la página de autenticación se pedirá la identificación al usuario,

la mano y el dedo sobre el que se va a realizar la validación. Una vez introducidos se

capturará la huella del usuario y se autenticará con la de la base de datos.


81

4.3.2.5 Clases jspSmartUpload

La figura 24 muestra el diagrama de clases del módulo JspSmartUpload:

Fi le

f i leToFie ld( )

ge tB inaryData ( )

g e t C o n t e n t D i s p ( )

g e t C o n t e n t S t r i n g ( )

ge tCon ten tType ( )

g e t F i e l d N a m e ( )

ge tF ie ldEx t ( )

g e t F i l e N a m e ( )

g e t f i l e P a t h N a m e ( )

getSize()

g e t S u b T y p e M I M E ( )

getTypeMIME()

i s M i s s i n g ( )

saveAs( )

F i l e s

g e t C o u n t ( )

ge tF i le ( )

ge tS ize( )

R e q u e s t

g e t P a r a m e t e r ( )

g e t P a r a m e t e r N a m e ( )

g e t P a r a m e t e r V a l u e s ( )

S m a r t U p l o a d

S m a r t U p l o a d ( )

g e t F i l e s ( )

g e t R e q u e s t ( )

ge tB inaryData ( )

getSize()

s e t A l l o w e d F i l e s L i s t ( )

s e t C o n t e n t D i s p o s i t i o n ( )

s e t D e n i e d F i l e s L i s t ( )

s e t D e n y P h y s i c a l p a t h ( )

s e t M a x F i l e S i z e ( )

se tTo ta lMaxF i leS ize ( )

d o w n l o a d F i e l d ( )

d o w n l o a d F i l e ( )

save()

up load( )

u p l o a d l n F i l e ( )

Figura 25. Clases JspSmartUpload


82

4.3.2.5. Clases mysql-connector

Estas clases conectan con el gestor de base de datos desde las páginas jsp y beans. A

esta clase pertenece por ejemplo la clase Driver.class que permite crear una

instancia del driver que nos conectará con la mysql. Otras clases también importantes

son: Connection.class, ResultSet, etc.

4.3.2.6. Clases Fingerprint

Estas clases pertenece a la API Java que permite acceder tanto al lector de huellas,

como a las funciones propias de la clase Fpr, la cual posibilita la autenticación y la

generación de una plantilla a partir de una imagen de huella.


83

Diagramas de Secuencia y Colaboración

A continuación mostraremos los diagramas de secuencia y colaboración

correspondientes a cada uno de los casos de uso de nuestro sistema:

Diagrama de Secuencia: Autenticar Administrador

: A d m i n i s t r a d o r : I n t e r f a z : A p l i c a c i ó n : A d m i n i s t r a d o r

E n t r a r

I d e n t i f i c a c i o n

A c e p t a r

P e d i r d a t o s

P e d i r d e d o

a u t e n t i c a r ( )

P o n e r d e d o

Figura 26. Secuencia de Autenticar Administrador


84

Diagrama de Colaboración: Autenticar Administrador

: ( A d m i n i s t r a d o r )

: I n t e r f a z : A p l i c a c i ó n

: A d m i n i s t r a d o r

1 : E n t r a r

4 : I d e n t i f i c a c i o n5 : A c e p t a r

2 : 6 :

3 : I n t r o d u c i r d a t o s

9 :

7 : a u t e n t i c a r ( )8 :

Figura 27. Diagrama de colaboración, caso Autenticar Administrador


85

Diagrama de Secuencia: Visualización

: A d m i n i s t r a d o r : In te r faz

P u l s a r t a r e a

S e l e c c i o n a r u s u a r i o

: A p l i c a c i ó n

L i s t a r u s u a r i o s

M o s t r a r u s u a r i o

M o s t r a r d a t o s

Figura 28. Secuencia de Visualización


86

Diagrama de Colaboración: Visualización


: I n t e r f a z


1 : T a r e a

4 : S e l e c c i o n a r u s u a r i o

7 : M o s t r a r d a t o s

2 : L i s t a r u s u a r i o s

5 : M o s t r a r u s u a r i o3 :

6 :

Figura 29. Diagrama de colaboración, caso Visualización


87

Diagrama de Secuencia: Alta Administrador

: Ap l i cac ión : A d m i n i s t r a d o r : Interfaz : A d m i n i s t r a d o r

Pu l sa r a l t a



OK

Mos t ra r da tos

C o n f i r m a r

Mos t ra r usua r i o

a l t a _ a d m i n ( )

Figura 30. Secuencia de Alta Administrador


88

Diagrama de Colaboración: Alta Administración

: I n te r faz

: A p l i c a c i ó n : U s u a r i o


2 : L i s t a r u s u a r i o s5 : M o s t r a r u s u a r i o

1 0 : 3 : 6 :

1 3 :

11 : a l t a ( )

1 2 :

1 : A l ta4 : S e l e c c i o n a r u s u a r i o

9 : O K

7 : M o s t r a r d a t o s8 : C o n f i r m a r

Figura 31. Colaboración, caso Alta Administrador


89

Diagrama de Secuencia: Baja

: A d m i n i s t r a d o r : A d m i n i s t r a d o r : In te r faz : A p l i c a c i ó n : Hue l la

P u l s a r B a j a


O K

bor ra r ( )

B o r r a r h u e l l a




C o n f i r m a r

ba ja ( )

Figura 32. Secuencia de Baja


90

Diagrama de Colaboración: Baja


: H u e l l a

B o r r a r h u e l l a


: A d m i n i s t r a d o r

2 : L i s t a r u s u a r i o s

5 : M o s t r a r u s u a r i o

1 0 :

3 : 6 :

1 5 :

1 3 : b o r r a r ( )

1 4 :

1 : B a j a

4 : S e l e c c i o n a r u s u a r i o

9 : O K


1 1 : b a j a ( )1 2 :

Figura 33. Diagrama de colaboración, caso Baja


91

Diagrama de Secuencia: Modificación

: A d m i n i s t r a d o r : A p l i c a c i ó n : U s u a r i o : I n t e r f a z

P u l s a r m o d i f .



O K

a c t u a l i z a r ( )

C o n f i r m a r



M o d i f i c a r d a t o s

Figura 34. Secuencia de Modificación


92

Diagrama de Colaboración: Modificación


: Inter faz

: A p l i c a c i ó n : U s u a r i o

1 : Mod i f4 : S e l e c c i o n a r u s u a r i o

8 : M o d i f f i c a r d a t o s1 0 : O K


2 : L i s t a r u s u a r i o s5 : M o s t r a r u s u a r i o

1 1 :

3 : 6 :

1 4 :

12 : ac tua l i za r ( )

1 3 :

Figura 35. Diagrama de colaboración, caso Modificación


93

Diagrama de secuencia: Alta Usuario nuevo


: U s u a r i o

: In ter faz : H u e l l a : U s u a r i o

P u l s a r a l t a

M o s t r a r f o r m u l a r i o

I n t r o d . d a t o s

A c e p t a r

a l t a _ u s u ( )

a l ta( )

A l t a h u e l l a

Figura 36. Secuencia de Alta usuario nuevo


94

Diagrama de Colaboración: Alta Usuario nuevo

: ( U s u a r i o )


: U s u a r i o : H u e l l a

C r e a r h u e l l a

1 : P u l s a r a l t a

4 : I n t r o d . d a t o s5 : A c e p t a r

2 : M o s t r a r f o r m u l a r i o6 :

3 :

1 1 :

7 : A l t a u s u a r i o8 :

9 : a l t a ( )

1 0 :

Figura 37. Diagrama de colaboración, caso Alta usuario nuevo.


95

Diagrama secuencia: Alta usuario existente

: U s u a r i o

: A p l i c a c i ó n : H u e l l a : U s u a r i o

P u l s a r A l t a e x i s t .

M o s t r a r f o r m u l a r i o

I n t r o d u c i r d a t o s

A c e p t a r

a l t a ( )

a l t a h u e l l a

Figura 38. Secuencia de Alta usuario existente


96

Diagrama de Colaboración: Alta Usuario existente

: ( U s u a r i o )


: H u e l l a

1 : P u l s a r a l t a

4 : I n t r o d . d a t o s

5 : A c e p t a r

2 : M o s t r a r f o r m u l a r i o

6 :

3 : 9 :

C r e a r h u e l l a7 : a l t a ( )

8 :

Figura 39. Diagrama de colaboración, caso Alta usuario existente


97

Diagrama secuencia: Autenticar Usuario

: Usua r i o : Interfaz : Ap l i cac ión : U s u a r i o

P u l s a r a u t e n t i c a r

P e d i r d a t o s

I n t r o d u c i r D a t o s

O K

P e d i r d e d o

P o n e r d e d o

A u t e n t i c a r

Figura 40. Secuencia de Autenticar


98

Diagrama de colaboración: Autenticar

: ( U s u a r i o )

: In ter faz : A p l i c a c i ó n

: U s u a r i o

1 : P u l s a r a u t e n t i c a r4 : I n t r o d u c i r d a t o s

5 : O K8 : P o n e r d e d o

2 : P e d i r d a t o s6 : P e d i r d e d o

9 :

3 : 7 :

1 2 :

1 0 : A u t e n t i c a r1 1 :

Figura 41. Diagrama de colaboración, caso Autenticar


99

4.3.3 Visualización

En este apartado se mostrarán las funciones e interfaz de la aplicación considerando

cada una de las pantallas de la misma.

Página principal

Desde la página principal, se accede tanto a las tareas de administración como a las

utilidades de usuario.

Figura 42. Pantalla página principal


100

Alta Usuario nuevo

En esta pantalla se muestra un formulario con los campos de los datos personales

requeridos a los usuarios que quieran darse de alta en el sistema. Además se incluye

un campo para cada uno de los dedos de ambas manos, gestionando el envío de las

imágenes digitalizadas de los mismos.

Figura 43. Pantalla Alta usuario nuevo


101

Alta Usuario existente

En esta pantalla se muestra un formulario con los campos de los datos personales

requeridos para identificarlo como un usuario existente. Además se incluye un

campo para cada uno de los dedos de ambas manos, gestionando el envío de las

imágenes digitalizadas de los mismos.

Figura 44. Pantalla Alta usuario existente


102

Autenticar Usuario

En esta pantalla comprobamos que un usuario que se haya dado de alta en la base de

datos con alguna imagen de huella, se autentica correctamente. Comparamos la

imagen “en vivo”, la que está sobre el lector, con la que está en la base de datos, y

mostramos el resultado.

Figura 45. Pantalla Autenticación I


103

Tras obtener los datos solicitados en la pantalla de la figura 39, se inicia el proceso

de autenticación. Si la autenticación tiene éxito se muestra la imagen del dedo del

usuario, así como diversos datos referentes a esta: calidad de la imagen, tamaño,

características adquiridas en el proceso de captura, nivel de coincidencia con la

huella en la base de datos, etc.

Figura 46. Pantalla Autenticación II.


104

Autenticar Administrador

En esta pantalla se le solicita al administrador que se autentifique para controlar el

acceso a las páginas exclusivas del administrador. Este esquema de autenticación

utiliza el propio del proyecto sobre el dispositivo lector de huellas dactilares.

Figura 47. Pantalla Autenticar Administrador


105

Alta Administrador

En esta página el administrador accede a la lista de usuarios en estado de espera para

ser dados de alta definitivamente. Seleccionando un usuario se dará de alta

definitivamente en la base de datos de la aplicación.

Figura 48. Pantalla Alta AdministradorII


106

A continuación se muestran todos los datos referentes al usuario, que constan en la

base de datos, para que el administrador si lo desea confirme el alta:

Figura 49. Pantalla Alta administrador II


107

Baja Administrador

Esta página proporciona una relación de los usuarios dados de alta en la base de

datos para que el administrador gestione posible bajas. El proceso de baja borra tanto

los datos personales como las huellas y plantillas que se hayan podido generar.

Figura 50. Pantalla Baja AdministradorI


108

A continuación se muestran todos los datos referentes al usuario, que constan en la

base de datos, para que el administrador si lo desea confirme la baja:

Figura 51. Pantalla Baja Administrador II


109

Modificar Administrador

En esta página se podrán modificar los datos personales de un usuario dado de alta en

la base de datos, al pulsar sobre la opción modificar por parte del administrador. En

primer lugar, se visualiza una página con los usuarios dados de alta (figura 49).

Figura 52. Pantalla Modificar I


110

Una vez seleccionado un usuario, se accede a una pagina (formulario) en la que se

tienen todos sus datos. En esta página se introducen los cambios que se deseen, datos

que posteriormente se actualizarán.

Figura 53. Pantalla Modificar II

Validación

111

5. Validación del sistema

En la validación de nuestro sistema usamos utilizamos base de datos que contiene 50

imágenes de huellas dactilares, pertenecientes a 5 personas distintas de las que

tendremos una imagen por cada dedo.

Cada imagen en la base de datos se compara con su propia plantilla y con las otras

49 plantillas. Si la comparación de una huella con una plantilla del mismo dedo

resulta exitosa, se considera una autenticación correcta, en caso contrario, estamos

ante un falso rechazo. Si se obtiene una autenticación correcta al comparar una

huella con otra que no pertenece al mismo dedo, estamos ante lo que se denomina

una falsa aceptación.

Utilizaremos los valores del porcentaje de autenticación y del porcentaje de rechazo

como parámetros para la estimación de la fiabilidad del sistema. Denotando al

número de falsos rechazos como num_rechazadas, num_correctas al número de

autenticaciones correctas y numero_falsas al número de falsas aceptaciones

obtenemos porcentaje de autenticación y del porcentaje de rechazo de la siguiente

forma:

100__

×+

=falsasnumerocorrectasnum

tasnum_correcicación de autentporcentaje

10050

_ ×= rechazadasnumo de rechazporcentaje

Validación

112

La tabla 2 muestra los valores obtenidos en el sistema desarrollado en el proyecto:

% Autenticación % Rechazo Usuario 1 99.9 % 13.32 % Usuario 2 99.88 % 12.82 % Usuario 3 99.65 % 12.13 % Usuario 4 99.45 % 13.72 % Usuario 5 98.94 % 10.41 %

Tabla 2. Porcentaje de autenticación y porcentaje de rechazo

Como se puede observar los valores son óptimos ( 99.5 % de media).

Conclusiones

113

6. Conclusiones

En este proyecto se incluye una pequeña introducción a la biometría y dentro de esta

al reconocimiento por huella digital. Quizás sería aventurarse demasiado asegurar

que dentro de unos años la biometría estará implantada en tantos lugares que nos será

familiar y hasta cotidiano.

Aunque parezca algo un tanto futurista, sobre todo pensando en otro tipo de

reconocimiento como los basados en sensores de calor o geometría facial, la

tecnología avanza a pasos agigantados, sobre todo en las últimas décadas, y no sería

raro que se empezara por implantar en computadoras de acceso restringido y con

información muy crítica, como en empresas, bancos, etc. Desde ese momento, el que

cualquier persona tenga un sistema biométrico en su computadora de sobremesa hay

un paso, o un abismo dependiendo por donde avance la tecnología.

En concreto, para el desarrollo de este proyecto, se adquirió un lector de huellas

digitales por menos de 200 $.

En este proyecto se ha desarrollado una aplicación cliente-servidor que permite una

gestión eficiente de huellas dactilares. Esta aplicación permitirá llevar a cabo

diversos estudios sobre esta tecnología en un futuro cercano, especialmente en el

desarrollo nuevos algoritmos de autenticación biométrica.

Manual de Administrador

114

ANEXO I: Manual de Administrador

Gestión de huellas dactilares

en formato digital


V1.0

Instalación

Base de datos

Para instalar la base de datos en el sistema sobre el que va a trabajar se tiene que:

Instalación de MySQL

Primero se debe obtener una copia de una distribución de MySQL. Para el desarrollo

del presente proyecto se utilizó la última versión disponible MySQL-3.23.49.

Para instalar la distribución, se descomprime en un directorio vacío y se ejecuta el

setup.exe. Por defecto, MySQL para Windows está configurado para instalarse en

‘C:\mysql’, si se quiere instalar en algún otro directorio, se puede instalar en

‘C:\mysql’ primero, y luego moverla al destino deseado. Si se mueve a otro destino,

se deberá indicar la localización de cada cosa añadiendo una opción --basedir en el

arranque del servidor.


115

Por ejemplo, si se ha movido la distribución MySQL a ‘D:\programas\mysql’ se

deberá arrancar mysqld de la siguiente forma:

C:\> D:\programas\mysql\bin\mysqld –basedir D:\programas\mysql

‘mysql –help’ muestra todas las opciones que se le pueden pasar a mysqld en el

arranque.

En las últimas versiones de MySQL, se puede crear un fichero ‘C:\my.cnf’ que

configura todas las opciones por defecto para el servidor MySQL. Copiar el fichero

‘\mysql\my-xxxx.cnf’ a ‘C:\my.cnf’ y editarlo para adecuarlo a la configuración.

Especificar todos los “caminos” con ‘/’ en lugar de ‘\’. Si se utiliza ‘\’ se deberá

especificar dos veces, ya que ‘\’ es el carácter escape en MySQL.

Para instalar MySQL como un servicio en Windows2000, sistema operativo sobre el

que se desarrolla la aplicación, se hará lo siguiente:

C:\> C:\mysql\bin\mysql-nt –install

Para iniciar y parar el servicio MySQL, se utilizan con los siguientes comandos

respectivamente:

C:\> NET START mysql (iniciar MYSQL)

C:\> NET STOP mysql (parar MYSQL)

Una vez instalado, se podrá “arrancar” utilizando el SMC (Services Manager

Control) que se encuentra en el panel de control; o usando el comando NET START

mysql. Si se requiere alguna opción, se deberá especificar como “Startup

parameters” en la SMC antes de iniciar el servicio MySQL. Una vez que se esté


116

ejecutando, mysqld-nt se puede parar usando Mysqladmin, desde la utilidad SMC o

por medio del comando NET STOP mysql.

Si no se quiere arrancar mysql-nt como un servicio, se arrancará de la siguiente

forma:

C:\> C:\mysql\bin\mysqld-nt --standalone

o

C:\> C:\mysql\bin\mysqld-nt –standalone --debug

Tras instalar correctamente MySQL, se deberá añadir nuestra base de datos para que

pueda ser utilizada por la aplicación. Concretamente se trata de un directorio llamado

base que situamos en el directorio data en la ubicación de instalación de MySQL:

D:\mysql\data\base

Esta base de datos contiene las tres tablas que requiere nuestra aplicación para su

funcionamiento: usuarios, huellas, administradores.

Servidor Apache

Instalación Apache

El software de Servidor Apache está disponible en el sitio web del Grupo Apache y

en decenas de sitios mirrow de todo el mundo. Se debe obtener una distribución

binaria gratuita de Apache, apache<versión>, disponible en su página web oficial

http://www.apache.org.


117

Ejecutamos el archivo binario y seguimos las pantallas típicas de instalación de una

aplicación windows, eligiendo durante este proceso el directorio de instalación que

más nos interese.

Para iniciar, detener y reiniciar el servidor teclearemos lo siguiente:

C:\<dir_apache>\Apache.exe (iniciar apache)

C:\<dir_apache>\Apache.exe - k shutdwon (detener apache)

C:\<dir_apache>\Apache.exe - k restart (reiniciar apache)

Utilizaremos la opción reiniciar para que tenga efecto cualquier cambio realizado en

los archivos de configuración de Apache, sin necesidad de detener y volver a iniciar

el servidor.

Para probar que funciona nuestro servidor escribiremos en nuestro navegador

http://localhost:[puerto]/ y comprobaremos que nos muestra la pagina de bienvenida

de Apache. El parámetro puerto será por defecto 8080, pudiéndolo modificar en el

archivo de configuración httpd.conf.

Instalación SSL

Primero se deben tener los módulos mod_ssl y OpenSSL, que podemos obtener en el

sitio http://www.modssl.org/contrib/.

Para la instalación de SSL en Apache deberemos introducir una serie de cambios en

su fichero de configuración httpd.conf que describimos a continuación:

En primer lugar se deben añadir los siguientes parámetros:


118

Port 443

Listen 80

Listen 443

ServerName www-mi-servidor.com

Para comprobar que el puerto 443 funciona correctamente se debe escribir en nuestro

navegador http://mi-servidor.com:443/.

Se debe descomprimir el archivo Apache<versión>modssl<versión>.zip en un

nuevo directorio. Copiar los archivos ssleay32.dll y libeay32.dll del directorio

Apache\openssl\bin al directorio Windows\System en caso de Win9x o

WINNT/System32 en caso de WinNT/2000.

Para la creación del certificado de prueba se deben seguir los pasos:

openssl req -config openssl.cnf -new -out mi-servidor.csr

Esto crea un certificado de requisición de firma y una llave privada. Cuando pregunte

por "Common name (p.e. tu nombre de dominio)" se debe dar exactamente el

nombre de dominio (p.e. www.mi-servidor.com). El certificado pertenece al nombre

del servidor y los navegadores emiten un aviso de inconformidad si el nombre no

coincide.

openssl rsa -in privkey.pem -out mi-servidor.key

Esto remueve la contraseña de la llave privada. Se debe entender lo que significa

esto; mi-servidor.key debe ser solamente legible por el servidor Apache y el

administrador. Se debe borrar el archivo .rnd porque contiene información entrópica

para la creación de la llave y podría usarse para ataques criptográficos contra tu clave

privada.


119

openssl x509 -in mi-servidor.csr -out mi-servidor.cert -req -signkey mi-servidor.key

Esto crea un certificado con firma propia(llamémoslo un certificado casero) que

puedes usar en tanto obtienes uno de validez oficial proveniente de una autoridad

certificada..

A continuación crear el directorio <dir-apache>\conf\ssl y mover los archivos mi-

servidor.key y mi-servidor.cert en el. Copiar todos los archivos de la distribución de

Apache_mod_ssl en el directorio de instalación original de Apache.

Localizar las directivas LoadModule en el archivo httpd.conf y añadir lo siguiente al

final de los existentes:

LoadModule ssl_module modules/mod_ssl.so

AddModule mod_ssl.c

Además se debe añadir lo siguiente al final del archivo httpd.conf:

SSLMutex sem

SSLRandomSeed startup builtin

SSLSessionCache none

SSLLog logs/SSL.log

SSLLogLevel info

<VirtualHost www.my-server.dom:443>

SSLEngine On

SSLCertificateFile conf/ssl/my-server.cert

SSLCertificateKeyFile conf/ssl/my-server.key

</VirtualHost>


120

Iniciar el servidor desde la línea de comandos con el propósito de ver los mensajes de

error que impiden iniciar Apache. Si algo no funciona, Apache escribe mensajes

significativos en la pantalla y, o en los archivos error.log y SSL.log en el directorio

Apache\logs.

Servidor Tomcat

Instalación Tomcat

La instalación de Tomcat requiere tener instalado previamente JRE (Java Runtime

Environment) conforme al JRE 1.1 o superior, incluyendo algún sistema con

plataforma Java2. Se necesita un compilador Java, como el incluido en el JDK (Java

Development Kit) 1.1 o superior.

Tras instalar este software en nuestra computadora se debe obtener el archivo binario

de versión apropiada de jakarta-tomcat<versión>. En el proyecto se utiliza

jakarta-tomcat3.3.1.

Se ejecuta el binario y se instala el servidor en el directorio deseado. A continuación

se añaden las variables de entorno java, para que Tomcat pueda utilizarlos. En

nuestro caso se hará lo siguiente:

Mi Pc-> Propiedades-> Avanzado-> Variables de entorno

en variables del sistema se añaden las variables:

JAVA_HOME - d:\jdk

TOMCAT_HOME - d:\jakarta-tomcat


121

Para iniciar y parar el servidor se abrirá una ventana DOS y se procederá de la

siguiente forma:

D:\jakarta-tomcat\bin\startup.exe (iniciar Tomcat)

D:\jakarta-tomcat\bin\shutdown.exe (parar Tomcat)

Para verificar que funciona se puede acceder a http://localhost:[puerto]/

comprobando que muestra la pagina de bienvenida de Tomcat. El parámetro puerto

será por defecto 80, pudiendose cambiar en el archivo de configuración de Tomcat

web.xml, para no tener conflictos con el servidor web Apache.

Teniendo el servidor instalado correctamente, se está en situación de alojar nuestra

aplicación. Para su despliegue, la aplicación debe situarse en un único archivo

denominado Web archive (war). En nuestro caso la aplicación está “empaquetada”

en el archivo ‘proyecto.war’.

Tomcat, permite que el archivo .war simplemente quede en el directorio

<directorio_de_inicio_tomcat>/webapps. Cuando se reinicia Tomcat, el archivo .war

se “desempaqueta” y se valida, y nuestra aplicación queda disponible. Esto es lo que

se debe hacer con proyecto.war.

El próximo paso es indicarle a nuestra aplicación el lugar donde hemos instalado

Tomcat, para ello añadiremos el contexto a nuestro archivo web.xml, que se

encuentra en el directorio WEB-INF de nuestra aplicación.

La aplicación hace uso del directorio donde tenemos instalado Tomcat, por ello

introduciendo una variable que le indique este directorio, obteniendo una aplicación

independiente del lugar donde se instale.


122

Con el parámetro ‘directorio’, indicamos el camino completo desde el directorio de

instalación de Tomcat, hasta el directorio donde se almacenarán las huellas y

plantillas (upload).

Introduciremos el parámetro ‘directorio’ en web.xml, y lo inicializaremos al

directorio de nuestra instalación, finalizando en el directorio upload, en donde se

almacenarán las huellas y plantillas, de la siguiente forma:

<context-param>

<param-name>directorio</param-name>

<param-value>D:/<dir_tomcat>t/webapps/proyecto/upload/

</param-value>

</context-param>

Enlazar Apache con Tomcat

Para enlazar el servidor web Apache con el contenedor de servlets Tomcat

necesitamos instalar el módulo mod_jk en el directorio correspondiente de Apache.

Descargamos el fichero mod_jk.dll en la dirección http://www.apache.org/dist/ y lo

copiamos al subdirectorio modules dentro del directorio de Apache .

Al ejecutar Tomcat, se crea automáticamente el fichero c:\<dir-

tomcat>\conf\tomcat-apache.conf, lo copiamos con otro nombre p.e. c:\ <dir-

tomcat>\conf\mio-tomcat-apache.conf.

Esto es necesario porque vamos a modificarlo, pero Tomcat lo sobrescribe cada vez

que arranca con lo que perderíamos las modificaciones si no lo renombramos.


123

Del nuevo fichero hay que quitar todas las referencias a JServMount y cambiarlas por

JkMount (no se pueden mezclar JServ y mod_jk). Además al principio del fichero

hay que poner las siguientes líneas:

LoadModule jk_module libexec/mod_jk.dll

AddModule mod_jk.c

JkWorkersFile c:\<dir-tomcat>\conf\workers.properties

JkLogFile c:\<dir_apache>\logs\mod_jk.log

JkLogLevel warn

JkMount /*.jsp ajp13

JkMount /servlet/* ajp13

JkMount /otherworker/*.jsp remoteworker

Por último añadimos al final del fichero de Apache conf\httpd.conf la línea:

include c:\<dir_tomcat>\conf\mio-tomcat-apache.conf

con esto indicamos a Apache las nuevas directivas para los servlets.

Ya tenemos instalado el módulo. Arrancamos en primer lugar Tomcat y a

continuación Apache; en este último al arrancar debe de salir un mensaje que indique

que estamos utilizando mod_jk.dll (algo similar a mod_jk.dll running).

Hay que tener en cuenta que Tomcat siempre se debe arrancar antes que Apache, y si

se para, hay que parar Apache y volver a arrancat Tomcat primero.

A continuación se describe lo que contiene cada directorio de nuestra aplicación:

Directorio Raíz

Contiene las páginas .html de nuestra aplicación, entre las que se encuentra la página

de inicio.


124

Directorio JSP

Como su propio nombre indica contiene las páginas .jsp, que junto con las páginas

.html forman la interfaz de nuestra aplicación.

Directorio Recursos

Aquí se mantienen los archivos (imágenes, botones, iconos, etc) que se van a usar en

las páginas de la aplicación.

Directorio Upload

Aquí es donde se transfieren las imágenes de las huellas de los usuarios. Además

mantiene las plantillas generadas por la aplicación a partir de las imágenes de huellas

digitalizadas.

Directorio Admin

Este es un subdirectorio de Upload y en el mantendremos las plantillas de los

administradores que tengan privilegios para gestionar la aplicación.

Directorio WEB-INF

Aquí está el archivo descriptor de despliegue web.xml, que se utiliza para configurar

los servlets y otros recursos que forman parte de la aplicación web.

Además incluye dos subdirectorio, el lib y classes:

Directorio lib

Contiene los archivos .jar. Las clases de cualquier archivo .jar que se encuentre en

este directorio se ponen automáticamente a disposición del cargador de clases sin

tener que estar explícitamente listadas en la ruta de clases.

Aquí es donde situaremos las librerías de clases para el acceso al lector de huellas

(FPJni.jar) y las clases que nos permitirán acceder a MySQL desde las páginas

(mysql-connector-java-3.0.1-beta-bin.jar).


125

Directorio classes

Este directorio contiene servlets y otras clases. Aquí se pueden ubicar los paquetes

que utilizados en la aplicación, en nuestro caso el paquete jspSmartUpload (com) y

las clases desarrolladas para modelar la aplicación: usuario, huella y administrador.

JspSmartUpload

Todos los ficheros jspsmartUpload vienen en un fichero comprimido

jspSmartUpload.zip. Se descarga el archivo comprimido, y se descomprime en un

directorio temporal asegurándonos de que la estructura de directorios está intacta. Si

por ejemplo, se extrae el fichero en ‘/temp’, se debería tener lo siguiente:

Para poder utilizar este paquete en las páginas JSP de nuestra aplicación, se tendrá

que ubicar en el directorio de la aplicación. Concretamente la estructura de directorio

de Tomcat nos indica que hay que situarlo en el directorio WEB-INF\classes.

Lector de huellas

Para instalar el hardware de captura de huellas que se utiliza en el proyecto se

introduce el CDROM que viene con el lector y seguimos el menú se instalación,

seleccionando la opción Development Toolkit.


126

La instalación copiará el archivo ‘FPJni.dll’ en el directorio d:\winnt\system32 de

nuestro disco duro, que se corresponde con el directorio de Windows2000. Este

archivo es el que contiene el código que implementa todo lo que se puede hacer con

el lector: capturar huella, salvar huella, comparar huella, generar plantilla, ...

La API Java que se utiliza en nuestra aplicación esta en el archivo jar ‘FPJni.jar’,

que no son más que un conjunto de clases “empaquetadas”.

Comandos de creación de tablas

127

Anexo II: Comando de creación de tablas

Para la creación de las tablas de la base de datos, se incluye a continuación una serie

de comandos SQL, utilizando los comandos SQL92 (ANSI SQL) soportados por

MySQL, se decidiera migrar la aplicación a otra base de datos estos comandos nos

facilitarían las cosas. Por otra parte MySQL soporta SQL92, aunque le añada algunas

extensiones.

En el caso de utilizar un Sistema gestor de base de datos relacional, a los comandos

de creación se les tendrá que unir los comandos de autorizaciones y vistas

pertinentes, que serán propios del entorno de trabajo.

Para garantizar la integridad referencial, se tiene en consideración que no se pueden

cambiar las claves principales.

Tabla Administradores

CREATE TABLE ADMINISTRADORES

(

ID_ADMINISTRADOR INTEGER PRIMARY KEY,

NOMBRE VARCHAR(15) NOT NULL,

PLANTILLA VARCHAR(15) NOT NULL

);

Comandos de creación de tablas

128

Tabla Usuarios

CREATE TABLE USUARIOS

(

ID_USUARIO INTEGER PRIMARY KEY,

NOMBRE VARCHAR(50) NOT NULL,

DIRECCION VARCHAR(50),

CP INTEGER,

LOCALIDAD VARCHAR(20),

PAIS VARCHAR(15),

ALTA CHAR(1)

);

Tabla Huellas

CREATE TABLE HUELLAS

(

ID_HUELLA INTEGER PRIMARY KEY,

MANO CHAR(1) NOT NULL,

DEDO CHAR(1) NOT NULL,

PLANTILLA VARCHAR(15) NOT NULL,

Id_usuario INTEGER,

CONSTRAINT FOREING KEY (Id_usuario) REFERENCES

USUARIOS(ID_USUARIO) ON DELETE CASCADE,

);

Bibliografía

129

Bibliografía

[1] Damon Hougland, Aarón Tavistock. “Guía esencial JSP”. Pearson Educación

S.A, Madrid, 2002.

[2] Phil Hanna. “JSP. Manual de referencia”. McGraw-Hill, Madrid, 2002.

[3] John Zukowski.”Programación en Java 2”. Ediciones Anaya Multimedia,

Madrid, 1999.

[4] Rich Bowen & Ken Coar, Servidor Apache al Descubierto. Pearson Educación,

S.A. Madrid, 2000.

[5] Lemay, Laura, “Aprendiendo HTML 4 para web en una semana”. Prentice Hall,

México, 1998.

[6] Juan Carlos Orós, “Diseño de páginas Web interactivas con JavaScript”. RA-MA

Editorial, Madrid, 1998.

[7] Graham Hamilton, Rick Cattell, Maydene Fisher, “JDBC Database Access with

Java - A tutorial and annotated reference”. Addison-Wesley, Massachussets,

1997.

[8] Herbert Schidt, “Java 2 - Manual de Referencia”. McGraw-Hill, Madrid, 2001

[9] Agustín Froure Quintas, “Java Server Pages – Manual de usuario y tutorial”. RA-

MA, Madrid, 2002

Bibliografía

130

[10] Jayson Falke, Ben Galbraith, Romin Irani, ... “Fundamentos Desarrollo Web con

JSP”. Anaya Multimedia, Madrid, 2002

[11] G.Booch, J. Rumbaugh, I. Jacobson, “El Lenguaje Unificado de Modelado.

Addison Wesley, Madrid, 1999.

Direcciones web

131

Direcciones web

http://desaweb.forosdelweb.com - Foros del Web

http://www.programacion.com - Java en castellano. Foros de debate

http://www.javahispano.org - Java en Castellano

http://www.programadores.com.sv - Comunidad salvadoreña de programadores

http://www.mysql.com - MySQL

http://java.sun.com - Pagina oficial sobre Java y tecnologías

http://www.jspsmart.com - JspSmartUpload para subir ficheros

http://jakarta.apache.org - Tomcat

http://www.ii.uam.es/~abie/ - Asociación de Biometría Informática Española

http://www.ictnet.es/ICTnet/cv/comunidad.jsp?area=engInf&cv=biometrica

- Comunidad de Biometría

Índice de Figuras

132

Índice de figuras

Figura 1. Diagrama Sistema Reconocimiento Biométrico .............................. 13

Figura 2. Relación entre FAR, FRR y ERR ...................................................... 14

Figura 3. Huella dactilar con minucias ............................................................ 16

Figura 4. Huella original y huella normalizada ................................................ 24

Figura 5. Huella orientada y campos realineados ............................................ 25

Figura 6. Variaciones de la huella y región importante ................................... 26

Figura 7. Imagen filtrada e imagen binaria .................................................... 27

Figura 8 . Imagen después del primer filtro perfilador e imagen

después del segundo filtro perfilador con máscara espacial ......... 28

Figura 9. Imagen después del adelgazamiento y eliminación de

imperfecciones y patrón de minucias después del proceso de

eliminación de conjuntos ................................................................... 29

Figura 10. Patrón de minucias ........................................................................... 30

Figura 11. Alineación de la cresta de entrada y la cresta plantilla ................. 32

Figura 12. Actores del sistema ........................................................................... 40

Figura 13. Casos de uso de Administrador ...................................................... 41

Figura 14. Casos de uso Usuario ....................................................................... 44

Figura 15. Modelo Entidad–Relación ............................................................... 48

Figura 16. Modelo de servidor de documentos estáticos ................................ 53

Figura 17. Contenido dinámico por secuencia de comandos CGI ................. 55

Figura 18. Aplicaciones dinámicas usando servlets, JSP y J2EE .................. 56

Figura 19. Interfaz JDBC .................................................................................. 72

Figura 20. Despliegue de la aplicación ............................................................. 74

Figura 21. Paquetes de la aplicación ................................................................. 75

Figura 22. Clases Auxiliares .............................................................................. 76

Figura 23. Clases del dominio ............................................................................ 77

Figura 24. Clases Interfaz .................................................................................. 78

Índice de Figuras

133

Figura 25. Clases JspSmartUpload ................................................................... 81

Figura 26. Secuencia de Autenticar Administrador ....................................... 83

Figura 27. Diagrama de colaboración, caso Autenticar Administrador ...... 84

Figura 28. Secuencia de Visualización ............................................................. 85

Figura 29. Diagrama de colaboración, caso Visualización ............................. 86

Figura 30. Secuencia de Alta Administrador ................................................... 87

Figura 31. Colaboración, caso Alta Administrador ....................................... 88

Figura 32. Secuencia de Baja ............................................................................ 89

Figura 33. Diagrama de colaboración, caso Baja ............................................ 90

Figura 34. Secuencia de Modificación .............................................................. 91

Figura 35. Diagrama de colaboración, caso Modificación ............................. 92

Figura 36. Secuencia de Alta usuario nuevo ................................................... 93

Figura 37. Diagrama de colaboración, caso Alta usuario nuevo .................... 94

Figura 38. Secuencia de Alta usuario existente .............................................. 95

Figura 39. Diagrama de colaboración, caso Alta usuario existente .............. 96

Figura 40. Secuencia de Autenticar .................................................................. 97

Figura 41. Diagrama de colaboración, caso Autenticar ................................. 98

Figura 42. Pantalla página principal ................................................................ 99

Figura 43. Pantalla Alta usuario nuevo ............................................................ 100

Figura 44. Pantalla Alta usuario existente ........................................................ 101

Figura 45. Pantalla Autenticación I ................................................................. 102

Figura 46. Pantalla Autenticación II ................................................................ 103

Figura 47. Pantalla Autenticar Administrador ............................................... 104

Figura 48. Pantalla Alta administrador I ......................................................... 105

Figura 49. Pantalla Alta administrador II ....................................................... 106

Figura 50. Pantalla Baja administrador I ........................................................ 107

Figura 51. Pantalla Baja Administrador II .................................................... 108

Figura 52. Pantalla Modificar I ........................................................................ 109

Figura 53. Pantalla Modificar II ....................................................................... 110

Índice de Tablas

134

Índice de Tablas

Tabla 1. Candidatos a Entidad y Relación ....................................................... 47

Tabla 2. Porcentaje de autenticación y porcentaje de rechazo ...................... 110

Proyecto Biometria

Documents