Aplicación lectora de datos públicos sobre...
Transcript of Aplicación lectora de datos públicos sobre...
Graduado en ingeniería del Software - 2014-2015 | Javier Jiménez Moreno
APLICACIÓN LECTORA DE DATOS PÚBLICOS
SOBRE DNIE
Autor: Javier Jiménez Moreno
Tutor: Dr. José Eugenio Naranjo Hernández
Agradecimientos
Me gustaría dar mis más humildes gracias principalmente a mi familia, concretamente
a mis padres que han estado sido siempre una firme guía durante la carrera y han
evitado que perdiese el foco y el objetivo que uno se propone al entrar a una carrera
por vocación.
También a todos aquellos compañeros que de una manera u otra han hecho mella y
han dado pie a entender que el trabajo en grupo y la convivencia es importante, en
especial a Antonio quien ha sido capaz de aguantarme a mí y a mis ideas de loco
durante toda la carrera y aún lo hace.
Por último a los profesores que se han mantenido actualizados en nuevas tecnologías y
han servido de guía imprescindible para los alumnos que pasamos por el “Grupo
CETEMA”, donde se ha convivido y aprendido a formarnos de una manera diferente al
resto.
Estoy seguro de que con toda esta experiencia conseguiré enfocar bien mi futuro
profesional, por ello, gracias.
“Actúa de tal modo que puedas igualmente querer que tu máxima de acción se vuelva una ley universal”
Immanuel Kant
Resumen Con la llegada de la era de la información, viendo esta era como la necesidad de
informatizar, registrar y tratar una gran cantidad de datos mediante la tecnología, se
está dando el paso de diversos procesos burocráticos a medios tecnológicos
cambiando el papel por los datos almacenados en las computadoras. El DNI electrónico
permite a un individuo identificarse mediante un dispositivo donde se almacenan los
datos de éste para poder identificarse unívocamente ante aquellos trámites que
antaño costaban largos procesos burocráticos en papel.
Sabemos que las aplicaciones software son aquellos módulos formado por un conjunto
de programas y rutinas que permiten a los diferentes tipos de computadores realizar
tareas de manera parcial o totalmente automáticas.
Por ello este proyecto demuestra todo el proceso de creación de un módulo software,
que cómo comentamos en el primer párrafo, permitiría sobrellevar otros tantos
procesos burocráticos como sería la petición del DNI y posterior escritura a mano en
distintas situaciones. Todo ello orientado desde un estricto análisis desde el punto de
vista de la ingeniería del software.
Abstract Due to the fact that we’re in the era of information technology, and from the
perspective that this era means to computerize register and treat a big quantity of data
through technologic means, we are stepping into a process where all the bureaucracy
is being transferred from paper to digital storage models. Hence, the electronic DNI
allows the citizen to identify himself univocally against processes that back in time
where made through tedious and heavy-paper-work processes.
We know that software apps are modules conformed by a set of instructions and
programs that make possible the execution of partially or totally automated tasks.
That’s why this project shows the process of the creation of a software module (app)
that, as we stated before, would allow overcoming many other bureaucratic processes
like the request to write down the national identification number. All of it focused to a
strict analysis from software engineering’s point of view.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
1
Índice del documento Índice de figuras ............................................................................................................... 3
1. Introducción ............................................................................................................. 5
1.1. Historia ............................................................................................................... 5
1.2. Justificación tecnológica .................................................................................... 6
1.3. Justificación socio-económica ........................................................................... 7
1.4. Problemática tecnológica .................................................................................. 7
1.4.1. Uso .............................................................................................................. 8
1.4.2. Implantación ............................................................................................... 8
1.5. Aspectos éticos, sociales y ambientales ............................................................ 9
1.6. Objetivos ............................................................................................................ 9
2. Estado del Arte ....................................................................................................... 11
2.1. Smart cards y estándares ................................................................................. 11
2.1.1. ISO/IEC-7816 ............................................................................................. 11
2.2. ASN.1 ................................................................................................................ 13
2.3. X.509 ................................................................................................................ 14
2.4. Java ................................................................................................................... 15
2.4.1. Librerías usadas ........................................................................................ 16
2.5. UML 2.4 ............................................................................................................ 17
2.5.1. Tipos de diagramas ................................................................................... 17
3. Implementación de la aplicación ............................................................................ 28
3.1. Objetivo ............................................................................................................ 28
3.2. Requisitos específicos ...................................................................................... 28
3.2.1. Funcionales ............................................................................................... 28
3.2.2. No funcionales .......................................................................................... 28
3.2.3. Interfaces hardware ................................................................................. 29
3.3. Diseño .............................................................................................................. 29
3.3.1. Diagrama de Clases ................................................................................... 29
3.3.2. Diagramas de estados............................................................................... 45
3.3.3. Diagramas de Secuencia ........................................................................... 50
3.4. Validación y trazabilidad de los requisitos ...................................................... 52
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
2
3.4.1. RF-001 ....................................................................................................... 52
3.4.2. RF-002 ....................................................................................................... 53
3.4.3. RF-003 ....................................................................................................... 54
3.4.4. RF-004 ....................................................................................................... 55
3.4.5. RF-005 ....................................................................................................... 56
3.4.6. RF-006 ....................................................................................................... 56
3.4.7. RNF-001 .................................................................................................... 57
3.4.8. RNF-002 .................................................................................................... 57
3.4.9. RNF-003 y RNF-004 ................................................................................... 58
3.4.10. RNF-005 y RNF-006 ............................................................................... 58
4. Conclusiones y propuestas ..................................................................................... 59
4.1. Objetivos alcanzados ....................................................................................... 59
4.2. Propuestas para futuras implementaciones .................................................... 59
4.2.1. Uso en la administración del estado ........................................................ 59
4.2.2. Sistema de firmado de datos .................................................................... 60
4.2.3. Sistema de registro para establecimientos .............................................. 60
4.3. Impacto y reflexión sobre los aspectos sociales, ambientales y ético/legales 60
4.3.1. Aspectos sociales ...................................................................................... 60
4.3.2. Aspectos ambientales ............................................................................... 61
4.3.3. Aspectos éticos ......................................................................................... 61
4.4. Conclusión personal ......................................................................................... 61
Anexos ............................................................................................................................ 62
Bibliografía .................................................................................................................. 62
Links ............................................................................................................................ 63
https://www.iso.org/obp/ui/#iso:std:iso-iec:7816:-1:ed-2:v1:en ......................... 63
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
3
Índice de figuras
1. Figura 1. DNI de 1951 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Figura 2. DNI de 1996 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Figura 3. DNIe de 2006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Figura 4. Lector de SmartCards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Figura 5. Diferentes posicionamientos de los contactos . . . . . . . . . . . . . . . . . . 12
6. Figura 6. Logos de las entidades de estandarización de ASN.1 . . . . . . . . . . . . . 13
7. Figura 7. Rep. clase uml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Figura 8. Rep. relación de herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Figura 9. Rep. relación de implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Figura 10. Rep. relación de agregación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Figura 11. Rep. relación de composición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Figura 12. Rep. relación de asociación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Figura 13. Rep. relación de direccional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Figura 14. Diagrama de estructura compuesta . . . . . . . . . . . . . . . . . . . . . . . . . . 20
15. Figura 15. Rep. componente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
16. Figura 16. Rep. interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
17. Figura 17.Diagrama de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
18. Figura 18.Diagrama de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
19. Figura 19.Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
20. Figura 20. Rep. estado inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
21. Figura 21. Rep. acción o estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
22. Figura 22. Rep. de decisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
23. Figura 23. Rep. de inicio o fin de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
24. Figura 24. Rep. estado final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
25. Figura 25. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
26. Figura 26. Diagrama de colaboración o comunicación . . . . . . . . . . . . . . . . . . . . 25
27. Figura 27. Diagrama de visión de conjunto de interacción . . . . . . . . . . . . . . . . 26
28. Figura 28. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
29. Figura 29. Diagrama de sincronización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
30. Figura 30. Botón guardado. Fallido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
31. Figura 31. Botón guardado. Éxito. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
32. Figura 32. Diagrama de clases de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 29
33. Figura 33. Clase DNIeCard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
34. Figura 34. Clase HTMLWriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
35. Figura 35. Clase DNIPublicData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
36. Figura 36. Clase CountPeople . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
37. Figura 37. Clase DNIChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
38. Figura 38. Clase DNIPublicDataView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
4
39. Figura 39. Clase JTextFieldLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 44
40. Figura 40. Clase DNIPublicDataObserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
41. Figura 41. Diagrama de Proceso lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
42. Figura 42. Diagrama de Proceso escritura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
43. Figura 43. Diagrama de secuencia de Proceso lectura . . . . . . . . . . . . . . . . . . . 51
44. Figura 44. Diagrama de secuencia de Proceso escritura . . . . . . . . . . . . . . . . . . 52
45. Figura 45. Aplicación con introducción de datos . . . . . . . . . . . . . . . . . . . . . . . . 53
46. Figura 46. Aplicación leyendo en bloqueo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
47. Figura 47. Aplicación tabla de registros en HTML . . . . . . . . . . . . . . . . . . . . . . . 54
48. Figura 48. Aplicación limpiar datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
49. Figura 49. Aplicación información fallo terminales . . . . . . . . . . . . . . . . . . . . . . 56
50. Figura 50. Aplicación información fallo encontrar . . . . . . . . . . . . . . . . . . . . . . . 56
51. Figura 51. Aplicación información fallo lectura . . . . . . . . . . . . . . . . . . . . . . . . . 57
52. Figura 52. Aplicación información fallo conexión . . . . . . . . . . . . . . . . . . . . . . . 57
53. Figura 53. Aplicación botón cambio automático . . . . . . . . . . . . . . . . . . . . . . . . 57
54. Figura 54. Aplicación fallo letra DNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
5
1. Introducción
1.1. Historia El Documento Nacional de Identidad (DNI) o carné de identidad es, en nuestra
sociedad, un elemento burocrático esencial para el control y organización de la
ciudadanía española. Siendo así desde el reinado de Fernando VII de España, pues la
historia del carné de identidad se remonta a 1824 cuando el rey, Fernando VII creó la
Policía, otorgándola con la capacidad y potestad exclusiva de crear padrones en los
cuales figurarían datos tales como el sexo, la profesión, la edad, estado y lugar del
domicilio todo ello siendo vigente hasta la actualidad ligando así históricamente al
Cuerpo Nacional de Policía con el Carné de Identidad.
No fue hasta el 2 de Marzo de 1944 mediante decreto, cuando se asentó la idea de un
documento identificativo tal y como lo conocemos hoy. Su puesta en marcha se hizo
de manera progresiva comenzando en Zaragoza y su fin era, como a día de hoy lo sigue
siendo, un control más exhaustivo de los españoles.
Figura 1. DNI de 1951
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
6
Desde 1951, cuando se comenzaron a expedir los primeros DNI, se sometieron a
un total de 7 modificaciones de diseño, incluyendo los datos que se harían constar en
dicho documento. Dichas modificaciones en los datos pasaron desde hacer constar la
“clase” del individuo (categoría del sujeto en arreglo a su economía), el grupo
sanguíneo o la profesión. Siendo hasta marzo de 2006 donde el DNI en su diseño
constaría de un chip con datos como por ejemplo un certificado digital con el que
firmar documentos electrónicos y que estudiaremos intensivamente en este trabajo, el
cual conocemos como DNIe.
1.2. Justificación tecnológica Hoy en día tenemos un legado de tecnologías que nos permiten el procesamiento,
consulta y transmisión de información de una manera rápida y eficaz. Esto se debe a
plataformas tales como las redes de telefonía y sobre todo a la red de internet.
El Documento Nacional de Identidad Electrónico se hace necesario en esta era de la
información ya que poco a poco la línea que separa a la máquina del hombre se está
haciendo más fina, dando lugar a interacciones humanas con mecanismos de
información casi de manera integrada, como por ejemplo el posicionamiento mediante
dispositivos de telefonía móvil. Dada esta interacción crece la necesidad de un método
tecnológico y efectivo de hacer uso de nuestros datos y nuestra identidad española
Figura 2. DNI de 1996
Figura 3. DNIe de 2006
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
7
sobre dichos mecanismos de comunicación y datos de una manera efectiva y
segura, dando la confianza al receptor de la información de que el que ejerce la
comunicación es un individuo identificable inequívocamente.
1.3. Justificación socio-económica Actualmente es común escuchar el término “sociedad de la información” el cual se
refiere a cómo la sociedad más y más, hace uso de la tecnología para todo tipo de
situaciones de la vida cotidiana. Ya sea realizar una llamada, comprobar el precio de
venta de un artículo o realizar un pedido de comida a domicilio.
Dentro de estas acciones encontramos que los distintos gobiernos y organismos de
España han ido impulsando una serie de medidas que propician el uso de tecnologías
de la información para realizar distintos trámites como pueden ser, la solicitación de
prestaciones de distintos tipos, petición de documentos, consulta de historiales,
etcétera.
Ya que el DNI es un documento usado para dichos trámites y que durante esos
trámites proporciona información sensible, la eficacia y seguridad en el procesamiento
de sus datos, así como la de su comunicación, es de gran importancia puesto que
agilizaría muchos trámites burocráticos dentro del marco legal español. Por ello es
importante estudiar cómo los organismos de estado (en el caso del DNI, el ministerio
del interior y el Cuerpo Nacional de Policía) manejan y comunican estos datos al nivel
del ciudadano, qué datos e información del individuo portador del DNI son accesibles y
cómo prestan dichos servicios al ciudadano.
1.4. Problemática tecnológica Dada la época en la que vivimos actualmente, la cual, denominamos “era de la
información” tenemos que día a día se crean nuevas tecnologías, nuevas maneras de
comunicación y nuevos protocolos para el traspaso y adquisición de información.
También hemos de contar con que las tarjetas inteligentes no son un invento reciente,
si no que la patente de los microcomputadores de un solo chip (parte fundamental de
las smart cards) data de 1978 por parte de Groupe Bull (Empresa conocida entonces
como Honeywell Bull) y el uso de las primeras smart cards consta de 1992 por parte
de Carte Blue y el uso de las hoy ampliamente conocidas tarjetas de débito. Por ello un
primer paso natural para nuestros sistemas de datos del ciudadano en nuestro país es
el de integrar dichos sistemas de microchips en las tarjetas de identificación, ya que
como vemos, las tecnologías están presentes y con ello poder tratar que la
información a día de hoy requiere de un flujo constante para evitar cuellos de botella
en la gran cantidad de procesos burocráticos que acontecen.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
8
El ciudadano medio ya posee una conexión a internet y conoce el uso de las
distintas tecnologías que este medio ofrece. De hecho en España un 74.4% de la
población tiene acceso a la red y ello, junto con los nuevos métodos (en algunos casos
obligatorios) para presentar documentos legales a los organismos del estado, se crea
una necesidad intrínseca. Por un lado la necesidad de realizar un entorno con la mayor
accesibilidad y usabilidad posible para el ciudadano, puesto que, tener un acceso a red
no implica el uso efectivo o 100% de esta si no se dan las condiciones adecuadas y por
otro lado la identificación segura y sin error del individuo que hace dichas
transacciones de información. Son estas las necesidades que, de una manera quizás un
poco tardía, dan lugar a la creación de tecnologías como lo es el DNIe que de una
manera más o menos atractiva y fácil para el ciudadano pueda gestionar una gran
parte de sus trámites legales de cara al estado.
1.4.1. Uso
Desde que se comenzó la expedición en 2006, hasta la fecha, se han expedido
38.000.000 DNIe lo que supone un 81% de la población española con capacidad de
realizar uso del DNI electrónico pero, a pesar de ello, el uso de todas las capacidades
del DNI electrónico por parte de la población es escaso en vista de las características
y/o barreras tecnológicas que surgen al usuario medio, puesto que ha de comprarse un
lector de tarjetas electrónicas y ser conocedor del funcionamiento de los drivers
dentro de un sistema operativo (entre otros) para hacer uso efectivo del DNIe.
1.4.2. Implantación
Uno de los primeros problemas a los que se presentó el DNIe fue su problemática
implantación sobre los distintos sistemas operativos cuando este fue introducido en la
sociedad española. A su salida no había drivers para MAC y Linux y, el uso en sistemas
operativos Windows era tedioso pues daba muchos problemas. Dichos drivers
Figura 4. Lector de SmartCards
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
9
permanecieron cerrados por lo que desarrollar sobre DNIe era difícil y por tanto,
proporcionar servicios de terceros que ayudasen al ciudadano.
Más adelante con actualizaciones y abriendo el código a desarrolladores se propició la
llegada de drivers para MAC y Linux, lo que ligeramente abrió expectativas para
desarrollar sobre el DNIe.
1.5. Aspectos éticos, sociales y ambientales A continuación procedemos a describir los aspectos que más controversia pueden
generar conociendo ya las justificaciones sociales, económicas y tecnológicas.
A la hora de tratar con los datos que identifican a un ciudadano, y por tanto, un
usuario de nuestro software hemos de tener en cuenta las bases que se postulan en la
Ley Orgánica de Protección de Datos ya que, mediante nuestro software, podemos
acceder a la identificación unívoca mediante el número de DNI del individuo, pudiendo
así, ya que el software es ubicuo, es decir, no hay posibilidad de hacer uso en la nube
puesto que es necesario un hardware de terceros para ello, el individuo queda
registrado en hora y lugar. Bajo este aspecto, podemos comentar que la facilidad que
se proporciona de acceder a dichos datos públicos (y por tanto ser almacenados)
puede en sí, puede ser un problema de seguridad en caso de pérdida del DNI ya que
este podría ser usado para falsear la ubicación de esa persona pero, por otro lado, al
no pedir el PIN de acceso en primera instancia puede ser utilizado para gestionar
dichos datos de una manera más amena para el usuario.
Por otro lado, tenemos que nuestra aplicación se basa en el uso del DNI electrónico y
que, éste no puede ser usado por todos los residentes en España, sólo sirve para
aquellos individuos con nacionalidad Española dando lugar así a una acotación
innecesaria de la aplicación y pérdida de la posible agilización en cuanto a trámites y
gestión de datos esta aplicación podría proporcionar a dicho sector de la población
española.
Desconocemos cual es el motivo tras esta decisión pero una causa bien puede ser la
expedición de una cantidad de DNIe que a posteriori no vayan a ser usados y por tanto
creando así un excedente.
1.6. Objetivos El presente trabajo trata de exponer, mediante una aplicación de escritorio y de una
manera fácil y visual las posibilidades y el potencial que nos aporta el uso del DNIe.
Datos y funcionalidades que consideramos de gran importancia ya que, el DNIe es el
primer documento al que se accede para verificar nuestra identidad, es decir, es el
salto más pequeño que hay entre la identificación de un individuo y el individuo en sí,
físicamente.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
10
Para el desarrollo de la aplicación se utilizarán todas las herramientas que se
puedan aplicar al proceso. Estas herramientas son aquellas proporcionadas por el
estudio de la ingeniería del software, como pueden ser, lenguajes de modelado,
lenguajes de programación, paradigmas de programación y un largo etcétera que
veremos a lo largo del trabajo.
Por ello y para demostrar el potencial del DNIe se pretende desarrollar una aplicación
bajo el paradigma de programación orientada a objetos y sobre el lenguaje de
programación Java. Dicha aplicación nos permitirá obtener los datos públicos del DNIe
sin necesidad de introducción de ningún PIN por parte del usuario (dependiendo de
ciertas configuraciones del entorno). Veremos entonces que el potencial de uso del
DNIe es amplio ya que dicha aplicación puede agilizar muchos trámites.
Por último procederemos a revisar la estructura interna del DNIe con el fin de
proporcionar una idea de cómo se gestionan internamente, a un nivel de abstracción
más bajo, todos los datos presentes en el chip del documento y dar unas conclusiones
sobre su seguridad.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
11
2. Estado del Arte Tenemos que a día de hoy el DNIe se encuentra en una etapa final en la que ya se ha
anunciado el DNI 3.0 (la segunda versión del DNIe). Durante los 9 años que el DNIe ha
estado en circulación ha sufrido sólo cambios en los interfaces software que se
comunican con el DNIe.
Para su funcionamiento el DNIe utiliza una amplia variedad de mecanismos de
comunicación, estándares y medidas de seguridad como vemos a continuación.
2.1. Smart cards y estándares Las Smart cards, conocidas en español como tarjetas inteligentes o tarjetas con circuito
integrado (TCI), son tarjetas de un tamaño pequeño comúnmente conocidas como
tamaño bolsillo, que poseen circuitos integrados permitiendo así ejecutar una lógica
previamente programada por el fabricante.
Hay una amplia gama de tipos de tarjetas inteligentes que principalmente se
subdividen en dos categorías diferenciadas por el tipo de microchip o por el tipo de
contacto. Según el microchip pueden ordenarse por tener memoria de escritura,
lectura o ambas; por tener algún mecanismo de seguridad implementado previo
acceso a memoria o por ser “inteligentes”, esto es, realizar acciones condicionadas
según la entrada de información hacia el microchip (un ejemplo sería que el propio
microchip pudiese contrastar el pin introducido en algún programa con el que está
almacenado en el propio circuito del DNIe). En cambio según el contacto tenemos dos
tipos: Por contacto o sin contacto (contactless o near field communication [NFC])
2.1.1. ISO/IEC-7816
Las entidades conocidas por sus siglas ISO (International Organization for
Standardization) e IEC (International Electrotechnical Commission) son organismos que
junto con otros organismos voluntarios, trabajan para definir estándares
internacionales. En concreto el estándar ISO/IEC-7816 se centra en definir todo aquello
relacionado con la identificación electrónica mediante tarjetas de contacto, en
especial, smart cards.
Para el uso del DNIe necesitamos un lector de smart cards que cumpla como mínimo
con los requisitos que se especifican en ISO/IEC-7816-1, ISO/IEC-7816-2 y ISO/IEC-
7816-3. Estas tres partes del estándar definen los componentes físicos que ha de tener
el circuito integrado y la manera de comunicarse con ellos. La primera parte se centra
las características físicas de la tarjeta con contactos, la segunda las dimensiones y las
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
12
localizaciones físicas de los contactos y la tercera especifica las interfaces
eléctricas y los protocolos de transmisión para tarjetas asíncronas.
Figura 5. Diferentes posicionamientos de los contactos
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
13
2.2. ASN.1 ASN.1 fue una notación en principio definida por ISO/IEC en conjunto con ITU-T
(International Telecommunication Union-Standardization) y es un estándar de
notación para definir reglas y estructuras para realizar una manipulación
(codificar/decodificar, transmitir y representar) de una serie de datos ya sea, a través
de telecomunicaciones, o sobre la comunicación en redes de computadores.
Durante su creación, fue definida como una notación “parte de” un estándar, el X.409
en 1984, pero en 1988 y dada su amplia aplicabilidad, pasó a ser un estándar per se
definido en X.208 y X.209, terminando en la actualidad a conocerse como el estándar
X.680.
Todo estos cambios han dado lugar a que haya ciertas incompatibilidades a día de hoy
entre ciertos usos del estándar implementados en diferentes protocolos y programas
(recordemos que el DNIe utiliza dicho protocolo en su versión ASN.1-88-notation, es
decir, X.208) y por ello se ha decidido crear desde la IETF (Internet Engineering Task
Force) el RFC-6025 con el fin de proveer unas reglas de traducción entre las distintas
versiones de las notaciones para así asegurar un correcto uso y funcionamiento en
aquellos lugares donde se de la aplicación de este estándar.
En este capítulo, aunque sería obligatorio documentarlo, se decide no realizar el
estudio del protocolo actual puesto que será analizado cuando se mencione el uso de
este dentro del funcionamiento del
DNIe.
Figura 6. Logos de las entidades de estandarización de ASN.1
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
14
2.3. X.509 El estándar X.509 está definido por el organismo ITU-T mencionado anteriormente y su
principal objetivo es el de proporcionar unas bases para las infraestructuras de clave
pública (Public Key Infrastructure [PKI]) e infraestructuras de gestión de privilegios
(Privilege Management Infrastructure [PMI]).
Dentro de estas definiciones se encuentran las especificaciones para los estándares de
formatos, entre otros:
Certificados de clave pública
Listas de revocación de certificados
Certificados atributivos o certificados de autorización
A continuación tenemos la definición del estándar X.509 para un certificado de clave
pública escrito sobre la estructura ASN.1-88-notation:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
UniqueIdentifier ::= BIT STRING
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
15
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
Como podemos observar el certificado se forma por una secuencia de tres campos
obligatorios:
tbsCertificate: que consta de los nombres de la entidad o sujeto y la
entidad que provee el certificado, la clave pública asociada a la entidad o
sujeto, un período de validez y otra información adicional que depende del
algoritmo y la versión de la implementación X.509 (1, 2 o 3)
signatureAlgorithm: contiene la información del algoritmo criptográfico a
usar que ha de ser el mismo que se ha usado en tbsCertificate.
signatureValue: es un bit string (una cadena de caracteres formados
únicamente por los dígitos 0 y 1 que conforman un número) cuyo fin es
verificar que el contenido de la información del certificado es correcto y no
ha sufrido ninguna modificación.
2.4. Java A lo largo del tiempo, desde que Java fue concebido como una idea llamada “Oak”,
luego “Green” y hasta llegar a llamarse como lo conocemos hoy en día, Java, ha sufrido
una cantidad de cambios importantes. Además hemos de tener en cuenta que se creó
en 1991 y por ello es un lenguaje que nació cuando el concepto de internet ya estaba
vigente y por ello se desarrollo y tuvo tanto éxito gracias a una amplia comunidad de
gente que decidía el siguiente paso que daría el lenguaje y demandaba necesidades de
éste.
Java comenzó siendo un lenguaje diseñado para sistemas de televisión interactivos por
James Gosling, Mike Sheridan y Patrick Naughton. En principio fue un lenguaje de
programación con muchas similitudes a C/C++ para así ser un lenguaje fácil de
aprender para los entonces programadores y administradores de sistemas.
Sus aspectos más destacables son:
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
16
Orientado a objetos: Como su predecesor C++, es un lenguaje que trata el
paradigma de orientación a objetos y por ello permite todos los conceptos asociados a
este (encapsulación, herencia, etc.)
Interpretado: Es un lenguaje que no se compila sobre la máquina que va a ser
ejecutado si no que hace uso de una interfaz con esta que traduce las instrucciones a
la arquitectura sobre la que esté ejecutándose. Por ello en la primera implementación
pública que desplegó Sun Microsistems en 1995 se promocionó con las siglas en inglés
WORA (“Write Once, Run Anywhere”) – “Escribe una vez, ejecútalo en todas partes”.
Java sigue siendo actualizado y mantenido de manera constante. Su última
actualización data del 19 de enero de 2015 donde se deshabilita por defecto el uso de
SSLv3[4].
2.4.1. Librerías usadas
Como la gran mayoría de lenguajes de programación de hoy en día, Java permite el uso
de librerías creadas con el fin de dar un apoyo en cuanto a modularización se refiere.
Esto es, dar partes de código que se va a utilizar en una gran cantidad de ocasiones
para evitar reescribir dicho código en cada instancia.
En el caso de estudio del presente documento hemos usado las siguientes librerías con
el fin de facilitar y realizar de manera eficiente diversas tareas dentro del ámbito del
lenguaje Java:
Bouncy Castle Project Libraries: Dado que el DNIe hace uso de las
tecnologías de certificados electrónicos y por ello, uso del estándar X.509,
que a su vez usa ASN.1 para su codificación; se requiere el uso de esta
librería que funciona como interfaz entre los datos del DNIe y la aplicación
implementada puesto que da una librería para leer (y escribir, en caso de
que fuese necesario) objetos codificados en ASN.1. También proporciona
distintos generadores y procesadores sobre distintos protocolos como
pueden ser OpenPGP, S/MIME, DVCS, etcétera.
Java™ Smart Card I/O API: Esta librería es la principal para la comunicación
con las tarjetas inteligentes. Está basada en las especificaciones
determinadas por ISO/IEC 7816-4 APDUs (Application Protocol Data Unit)
que son aquellas que permiten comunicarse con los chips que almacenan
los programas y los datos en las smart cards, en nuestro caso nos permite
acceder a las componentes de la parte pública del DNIe. //TODO: Explicar
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
17
2.5. UML 2.4 Con el fin de especificar y aclarar el diseño de la estructura del DNIe y la aplicación que
se ha desarrollado se utilizará el lenguaje de modelado Unified Modelling Language
(UML).
UML tal y cómo lo conocemos hoy nació en 1996 gracias a Grady Booch, Ivar
Jacobson y James Rumbaugh cuando se encontraban trabajando en Rational Software,
y que, dicho lenguaje de modelado pasó a ser un estándar adoptado por el Object
Management Group (OMG) que desde entonces ha gestionado dicho estándar del
lenguaje. En el año 2000 fue aceptado como estándar por la organización ISO, lo que le
ayuda a ser un estándar de facto para cualquier proyecto o trabajo que trate alrededor
de Ingeniería Software.
Aunque en un principio UML fue diseñado para cubrir las necesidades de la
programación orientada a objetos, a día de hoy cubre un rango mucho más amplio de
paradigmas como tal. Por ello, UML es un lenguaje que nos permite obtener un
entendimiento abstraído de aquellos lenguajes que estén a más bajo nivel como
pueden ser los lenguajes de programación, las estructuras de base de datos y patrones
de diseño software. Gracias a esta abstracción y mediante diagramas visuales que dan
una vista general del todo o las partes de un proyecto software podemos entender y
realizar un seguimiento de las distintas actividades que se realicen en el sistema, los
componentes que lo conforman y cómo se relacionan y comunican entre sí, cómo el
sistema se ejecutará como un todo (es decir, su funcionalidad objetivo), etcétera.
Dado que UML, como hemos comentado, es de gran importancia en programación
orientada a objetos y lo utilizaremos para dar un mejor entendimiento del sistema, es
de obligado caso de estudio en este documento, por ello enumeraremos los diferentes
diagramas de los que este lenguaje de modelado hace uso y definiremos en detalle
aquellos que sean totalmente necesarios en el modelado y descripción de este trabajo
o sean de alta prioridad de aprendizaje en las recomendaciones sobre UML 2.x.
2.5.1. Tipos de diagramas
En UML existe una gran variedad de maneras de abstraer las partes o abstraer el
propio sistema de una manera visual y fácil siguiendo su estándar además de dar
pautas para el aprendizaje. En este documento mostraremos la prioridad en el
aprendizaje de cada diagrama que se recomienda, siendo un icono circular de color
verde la mayor prioridad, el amarillo media y el gris baja.
Existen tres tipos de clasificación de diagramas: De estructura, comportamiento e
interacción. En nuestro caso nos centraremos en diagramas de diseño, nunca de
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
18
análisis, para ello a continuación mostramos el desglose de estos diagramas en
su etapa de diseño.
2.5.1.1. Estructura
Este tipo de diagramas se caracteriza por describir las partes del sistema sin tener
ninguna influencia sobre el flujo de tiempo, es decir, el paso del tiempo dentro del
sistema no supone ningún cambio en los diagramas que se representan aquí.
2.5.1.1.1. Diagrama de clases
Es de todos los diagramas, uno de los más importantes y el que posiblemente se
abstraiga menos del proyecto que queremos modelar y sobretodo de la visión de
programación orientada a objetos.
Este diagrama se basa en mostrar las clases del sistema, sus relaciones internas (es
decir, entre clases) y las operaciones y atributos de cada clase. A pesar de que el uso
puede ser variado para los diagramas de clases, nos centraremos en la posibilidad de
describir con estos en detalle, el diseño en base a la programación orientada a objetos
un proyecto software específico.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
19
Las componentes gráficas de un diagrama de clases son, a groso modo y de uso
más común, las que comentamos a continuación.
Clases:
Una clase se representa mediante un cuadrado subdividido en 3 partes: El nombre
identificativo de la clase dentro del sistema, los atributos con su respectiva
encapsulación, es decir, pueden ser según su visibilidad, privados, públicos o
protegidos y han de ser de un tipo determinado (una cadena de caracteres, de tipo
numérico, de tipo fecha, etc.) y por último, en la subdivisión de más abajo las
funciones y/o métodos con su modificador de encapsulación.
Relaciones entre clases:
Herencia:
o o Representa (en el lado del triángulo) la clase padre y la o las, clases
hijas que heredan del padre.
Implementación:
o o En el caso especial de la herencia en que la clase padre sea una clase
“interfaz”, es decir, no sea instanciable en el sistema, esta
representación gráfica señala las clases hijas que implementan los
métodos y usan los atributos heredados.
Agregación
o o Simboliza que una clase puede tener objetos de otra clase, pero que
si la primera es eliminada en tiempo de ejecución no implica la
eliminación de esta segunda.
Composición
o o Este es el caso restrictivo de la agregación, puesto que si varias
clases forman parte de otra clase (es decir, la clase compuesta
posee objetos de las demás clases relacionadas por este ítem), en el
Figura 7. Rep. clase uml
Figura 8. Rep. relación de herencia
Figura 9. Rep. relación de implementación
Figura 10. Rep. relación de agregación
Figura 11. Rep. relación de composición
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
20
caso de ser eliminado el objeto de la clase compuesta los objetos
de las clases que la componen también serán eliminados, las clases
parte no pueden existir sin la compuesta.
Asociación
o o Representa el uso común entre dos clases, es decir, una clase puede
llamar los métodos de la otra. La relación temporal no se especifica
puesto que el objeto de la clase asociada puede crearse en cualquier
instante.
Asociación Direccional
o o En este caso, sólo una de las clases hace uso de la otra. La relación
temporal es muy corta puesto que el objeto de la clase asociada al
que se va a dar uso sólo se crea dentro del ámbito de un método y al
salir de este ámbito se destruye dicho objeto.
2.5.1.1.2. Diagrama de la estructura compuesta
La intención de este diagrama es mostrar con detalle la estructura interna de una
componente UML tales como una clase o un diagrama de casos de uso y las
interacciones de los componentes con otras partes del sistema.
En el ejemplo siguiente vemos una representación de las componentes Clase y
Variable definidas en detalle por el diagrama y las interacciones entre sus
componentes internos como son las funciones, variables y vistas.
2.5.1.1.3. Diagrama de componentes
El presente diagrama describe cómo los componentes de un sistema, una aplicación o
una compañía están conectados entre sí para formar otros componentes más grandes
o un sistema software.
Sus componentes gráficas son las siguientes:
Componente:
Figura 12. Rep. relación de asociación
Figura 13. Rep. relación de direccional
Figura 14. Diagrama de estructura compuesta
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
21
Esta representación gráfica representaría un componente representativo del sistema,
aplicación o compañía. Pueden estar rellenos de más componentes e interfaces o ser
en sí mismos la representación de un solo componente con el nombre de este en la
parte de fuera de arriba.
Interfaz:
Se representa con un círculo y se une a un componente mediante una línea continua
de asociación. La interfaz actúa de elemento de unión con otros componentes. El
nombre de la interfaz puede aparecer encima del círculo.
2.5.1.1.4. Diagrama de despliegue
El diagrama de despliegue nos señala en un vistazo todos los componentes hardware y
software que se encuentran en ejecución y ayudan al funcionamiento total y correcto
del sistema. Su representación se basa en mostrar componentes hardware y/o
software y la instancia que se ejecuta sobre ellos. Estos componentes se llaman nodos
y pueden referirse, por ejemplo, al componente hardware como puede ser un servidor
web y dentro de este hardware determinar la instancia del programa que se ejecuta en
éste, como puede ser una instancia de apache que hayamos instalado.
Figura 15. Rep. componente
Figura 16. Rep. interfaz
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
22
2.5.1.1.5. Diagrama de objetos
También conocidos como diagramas de instancia, describen el sistema en un punto en
concreto, típicamente un momento en concreto de las instanciaciones de objetos de
un diagrama de clases.
2.5.1.1.6. Diagrama de paquetes
Describen las dependencias que tienen los distintos paquetes que conforman un
modelo. Siendo un modelo una representación de una parte del sistema y siendo un
paquete un mecanismo general para agrupar modelos y los diagramas del sistema.
2.5.1.2. Comportamiento
Se caracterizan por representar las características de comportamiento del sistema o de
los procesos de negocio.
Figura 17.Diagrama de despliegue
Figura 18.Diagrama de objetos
Figura 19.Diagrama de paquetes
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
23
2.5.1.2.1. Diagrama de actividades/estados
Este diagrama describe las fases y decisiones por las que se puede pasar en un flujo de
trabajo ya sea dentro de un proceso software o dentro de una compañía. Con ello
muestran una vista alejada de los detalles del problema centrándose en el control del
mencionado flujo de trabajo.
Sus componentes gráficas más importantes son las que mostramos a continuación:
Estado inicial:
Es la componente gráfica que representa el inicio de un flujo de trabajo. Sólo puede
haber una en cada diagrama que modele un flujo de trabajo.
Acción/Estado:
Muestra y define la acción que se realiza en ese punto del flujo de trabajo.
Decisión:
Es una decisión condicional, dependiendo de lo que pueda pasar en la acción en la que
se encuentra el flujo en ese momento.
Inicio/fin de estados concurrentes:
Sirve para poder presentar de manera visual el comienzo o el fin de actividades
concurrentes.
Estado final:
Representa el final del flujo y, al contrario del inicio, puede haber más de un final
asociado a cualquiera de las actividades o decisiones presentes en el diagrama.
Relaciones:
Figura 20. Rep. estado inicial
Figura 21. Rep. acción o estado
Figura 22. Rep. de decisión
Figura 23. Rep. de inicio o fin de estados
Figura 24. Rep. estado final
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
24
Se utiliza una flecha unidireccional () entre todos los elementos del diagrama.
Las flechas serán únicas excepto en las situaciones de salidas de una decisión, de salida
o entrada en concurrencia y entrada en un estado final
2.5.1.2.2. Diagrama de casos de uso
El diagrama de casos de uso es la representación más abstraída del problema en
cuanto a detalles técnicos se refiere y da la visión global en cuanto a la interacción del
sistema con el usuario y las diferentes opciones que se pueden dar en cuanto a la
funcionalidad que deriva desde la interacción del usuario. Puede identificar a los
distintos tipos de usuarios del sistema y en la mayor parte de los casos van
acompañados de otros tipos de diagramas.
Figura 25. Diagrama de casos de uso
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
25
2.5.1.3. Interacción
Es un subconjunto de los de comportamiento que sitúa su énfasis en las interacciones
entre objetos
2.5.1.3.1. Diagrama de colaboración o comunicación
Es típicamente un diagrama para modelar situaciones en base a orientación a objetos
y representa las interrelaciones entre clases cuando estas se encuentran instanciadas,
enfocándose en la organización y estructura de dichos objetos, cuando estos reciben y
envían mensajes.
Figura 26. Diagrama de colaboración o comunicación
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
26
2.5.1.3.2. Diagrama de visión de conjunto de interacción
Es similar al diagrama de actividades, su diferencia consta en que puede tener
anidados otros diagramas de interacción lo cual le da a éste diagrama la competencia
de modelar flujos condicionales complejos, es decir, flujos de if-then-else anidados a
gran escala.
2.5.1.3.3. Diagrama de secuencia
Representa de manera estructurada temporalmente las interacciones entre las
llamadas de una o varias clases y el flujo de información dentro de estas llamadas.
Sirve, para modelar escenarios muy complejos de llamadas entre objetos, cuando
dichas llamadas se producen en gran número y se produce la necesidad de dar un
entendimiento detallado de la creación de relaciones entre objetos en un determinado
Figura 27. Diagrama de visión de conjunto de interacción
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
27
momento y su evolución en el tiempo.
2.5.1.3.4. Diagrama de sincronización
Describe el cambio del estado o condición de un componente a lo largo del tiempo. Se
usa para situaciones en las que es necesario modelar cómo un determinado
componente cambia en respecto a eventos del sistema externos a este.
Figura 28. Diagrama de secuencia
Figura 29. Diagrama de sincronización
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
28
3. Implementación de la aplicación
3.1. Objetivo La presente aplicación software tiene como fin último analizar los procesos software
en los que se apoya el flujo de datos de la estructura del DNIe. Para ello nos apoyamos
en demostrar que, a pesar de ciertas dificultades impuestas por las propias
tecnologías, el uso del DNIe y el desarrollo de ciertas aplicaciones facilitarían la gestión
y uso de éste mediante este software que gestiona los datos que se pueden obtener a
nivel público del DNIe del ciudadano y almacenándolos de una manera rápida y eficaz.
3.2. Requisitos específicos En este apartado definiremos todos aquellos requisitos necesarios para llevar a cabo
éste proyecto software, los cuales nos darán una visión objetiva de los puntos a
cumplir con la aplicación.
3.2.1. Funcionales
RF-001: El usuario podrá introducir por pantalla los datos de nombre y número
de identificación de un DNI cualquiera.
RF-002: Al introducir un DNIe en el periférico lector de smart cards (es decir, el
lector de DNIe) se podrán obtener una parte de sus datos públicos por pantalla,
el nombre y el número de identificación, mediante la pulsación de un botón
con el texto “Obtener datos”
RF-003: El usuario tendrá la opción de guardar en un fichero con formato
HTML, y junto con la fecha de registro, los datos públicos obtenidos a partir del
DNIe y el periférico especificados en el RF-002 mediante la pulsación de un
botón en la interfaz de usuario con el texto “Guardar datos”
RF-004: Se podrán borrar todos los datos que hubiere introducidos por pantalla
con la pulsación de un botón con el texto “Limpiar datos”
RF-005: La aplicación detectará si hay o no conectados periféricos para la
lectura de un DNIe a la hora de pulsar el botón especificado en el RF-002
RF-006: La aplicación intentará detectar si el usuario ha introducido
correctamente el DNIe en el momento de la pulsación del botón especificado
en el RF-002 y en caso de no satisfacerse dicha condición o no poder realizarse
la lectura por deterioro del material en uso, ya sea el DNIe o el periférico, se
mostrará una pantalla de aviso
3.2.2. No funcionales
RNF-001: Al introducir los datos, el foco entre las cajas de texto se cambiará
automáticamente o no mediante la selección de un “checkbox“ que activará o
desactivará dicha funcionalidad con la etiqueta de texto “Cambio automático”
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
29
RNF-002: La aplicación detectará que los datos introducidos
manualmente sean correctos detectando que la letra del número de
identificación sea la correcta.
RNF-003: No se permitirán introducir caracteres numéricos en el campo de
texto de “nombre”
RNF-004: No se permitirán introducir letras en los primeros ocho campos de
texto destinados al número de identificación
RNF-005: En caso de error al intentar grabar los datos en el fichero de registro,
el botón especificado en RF-003 se volverá rojo durante una fracción de tiempo
mostrando así el error al grabar los datos.
RNF-006: En caso de satisfacer la funcionalidad descrita en RF-003, es decir,
guardar los datos en el fichero html, el botón especificado en el RF-003 se
tornará verde durante un breve lapso de tiempo dando así a entender que los
datos se han registrado correctamente.
3.2.3. Interfaces hardware
RIIH-001: El periférico utilizado ha de tener capacidad de conexión mediante un
cable para el puerto USB (Universal Serial Bus)
RIIH-002: El hardware específico para la lectura de smart cards ha de
implementar los estándares ISO/IEC-7816-1, ISO/IEC-7816-2 y ISO/IEC-7816-3
3.3. Diseño En esta sección se describe el sistema software a desarrollar bajo las especificaciones
y estándares propuestos en UML 2.4.1 para la especificación de sistemas software bajo
el paradigma de orientación a objetos.
3.3.1. Diagrama de Clases
3.3.1.1. Visión general: Sistema
Como vemos en el siguiente diagrama de clases de visión general del sistema,
podemos observar que la aplicación consta de una estructura, Modelo-Vista-
Controlador (MVC), siendo así las clases controlador (DNIPublicData), modelo
(DNIeCard) y vista (DNIPublicDataView) cuya comunicación entre el controlador y la
vista se ha realizado mediante la implementación del patrón Observer. Se han obviado
durante el modelado las clases provenientes de librerías de terceros.
Figura 30. Botón guardado. Fallido.
Figura 31. Botón guardado. Éxito.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
30
Como hemos comentado con anterioridad, la clase que ejerce de controlador
DNIPublicData es el pivote para los datos puesto que facilita el flujo de estos entre la
vista y las demás clases. Esto es, entre los datos que pueda recoger la clase DNIeCard
de un dispositivo físico o de la entrada de datos mediante la interfaz de usuario
mediante DNIPublicDataView.
Figura 32. Diagrama de clases de la aplicación
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
31
A continuación se detallan las relaciones entre las clases y su justificación:
Relación de agregación entre DNIPublicData y HTMLWriter
o Su rol de relación es “guarda_datos” puesto que es la función principal
a desempeñar por la relación entre estas dos clases. Guardar los datos
del usuario en un archivo con formato HTML con el fin de registrar
varios usuarios.
o Su multiplicidad uno a uno como máximo pues en el sistema como está
planteado actualmente, no necesitaremos más de un controlador que
proporcione los datos de registro de usuarios para escribir a disco por
cada clase que realice dicha función. Puede darse el caso que no
necesitemos escribir a disco y por ello no instanciar ningún objeto de la
clase HTMLWriter
o La relación es de agregación por razones de escalabilidad en la
aplicación. Que se destruya la clase DNIPublicData no ha de suponer la
destrucción de memoria del objeto HTMLWriter instanciado puesto que
podremos en un futuro necesitar en otras partes del sistema dicho
objeto para poder seguir accediendo al mismo fichero ya abierto sin
necesidad de instanciar de nuevo un objeto que acceda al fichero y re-
abrir dicho fichero
Relación de asociación de uso entre DNIPublicData y DNIeCard
o Su rol de asociación es “tiene_tarjeta” puesto que en cada “uso” que
DNIPublicData realiza sobre DNIeCard (Es decir, instanciación) es
necesario para el correcto funcionamiento que haya presente un DNIe
insertado
o La multiplicidad es como máximo y mínimo, uno a uno, ya que no se ha
querido restringir al uso de un solo periférico. Siendo uno a uno,
especificamos la necesidad de no tener varios objetos de DNIeCard y así
evitar la comunicación entre diferentes puertos lo cual dificultaría el
flujo de datos dentro del sistema
o La relación es de uso ya que por un lado, tenemos que sólo
realizaremos la conexión con el periférico de una vez para obtener
todos los datos públicos que nos proporciona DNIeCard y
posteriormente “parsear” dichos datos con la ayuda de métodos de
otras clases dentro de DNIPublicData
Relación de agregación entre DNIPublicData y CountPeople
o Su rol de agregación es “gestiona_cuenta”. La relación se encarga de
mantener el número de personas registradas durante la sesión actual de
uso de la aplicación
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
32
o La multiplicidad de la relación es uno a uno dado que no se ha
pensado permitir diferenciar el tipo de registro de personas, es decir,
sólo se implementa la posibilidad de llevar la cuenta de un registro de
personas
o La relación es de agregación al existir la necesidad de no perder la
cuenta de la gente que está siendo registrada en cualquier estado o
momento a razón del tiempo de uso de la aplicación
Relación de asociación de uso entre DNIPublicData y ASN1DNIParser
o El rol de uso es “lee_asn” ya que esta relación es la que habilita la
lectura en claro de los datos públicos del DNIe. Es necesaria puesto que
el DNIe, como comentamos en el apartado del estado del arte, tiene
una estructura que sigue el estándar ASN.1 para almacenar los datos.
o La multiplicidad máxima es uno a uno, pero la mínima da lugar a que la
clase ASN1DNIParser puede darse el caso que no precise ninguna
instanciación por motivos de reducción de procesamiento de datos y se
desee guardar los datos públicos del DNIe per sé, es decir, como se
transmitieron desde el periférico
o La relación es de asociación de uso pues sólo se usa en el momento de
la lectura de los datos públicos del DNIe gracias a la clase DNIeCard por
tanto, como esta, sólo se instancia en dicho momento.
Relación de composición entre DNIPublicData y DNIPublicDataView
o El rol de composición es “interfaz_compone” y es una piedra angular
de la arquitectura MVC puesto que es la vista que muestra los datos
recibidos por el flujo de datos entre DNIeCard, DNIPublicData y
HTMLWriter, que a posteriori son recibidos y mostrados por la vista y
que, también propicia el flujo en sentido inverso: Introducción da datos
por parte del usuario hacia DNIPublicData
o La multiplicidad máxima y mínima es uno a uno puesto que no tiene
sentido que exista una vista sin su controlador.
o La relación es de composición por la misma razón que la multiplicidad,
si no hay un controlador que pueda proporcionar y asegurar un flujo de
datos dentro de la aplicación, carece de sentido la vista.
Relación de uso entre DNIPublicData y DNIChecker
o El rol de asociación de uso es “realiza_check” puesto que esta relación
sólo tiene el fin de proporcionar a la clase DNIPublicData de un objeto
que asegure que el DNI introducido es correcto
o La multiplicidad máxima es uno a uno, pero la mínima permite no
instanciar un objeto de la clase DNIChecker puesto que podemos no
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
33
haber parseado los datos o provenientes del DNIe a través periférico
y por ello no haber ninguna necesidad de uso de esta clase
o La relación es de uso pues esta clase funciona bajo el patrón “singleton”
dado que se considera que no almacenará ningún dato y por ello sólo
proporciona métodos útiles en referencia a los datos en claro del DNIe
Relación de agregación entre DNIPublicDataView y DNIPublicDataObserver
o El rol de agregación es “notifica_a” ya que la función de esta relación es
la implementación eficaz del patrón observer mediante las clases
DNIPublicDataView, DNIPublicDataObserver y DNIPublicData
o La multiplicidad máxima será uno a muchos, y esto se debe a que a
pesar de que el sistema en sí sólo instanciará una clase DNIPublicData
en este punto se desconoce cuántas instancias están esperando
cambios y datos por parte del objeto
o La relación es de agregación puesto que necesitamos un objeto al que
transmitir los datos por parte del usuario y mantener la referencia a
este para asegurar la eficacia del flujo de datos
Relación de asociación de uso entre DNIPublicDataView y JTextFieldLimit
o El rol de la asociación es “usa_instanciando” proporcionando la
funcionalidad para restringir tipos de datos dentro de los campos
TextField que forman parte de DNIPublicDataView a razón de que
hereda de la clase JFrame del paquete Swing de Java.
o Su multiplicidad máxima es uno a muchos. Es obvio pues la necesidad
de usar la funcionalidad que proporciona esta clase en un futuro puede
ser tan grande como campos TextField haya en la vista, así cómo, su
multiplicidad mínima es uno a cero ya que puede ser que no se
necesite instanciar ningún objeto pues su funcionalidad no se necesite
o Está relacionado mediante asociación de uso marcado por la única
razón de que este objeto se instancia directamente como parámetro. Es
decir la relación temporal con DNIPublicDataView es mínima, no así,
con los campos TextField pues dura tanto, como duren estos
instanciados.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
34
3.3.1.2. Clase DNIeCard
Atributos:
[privado] baCommandAPDURoot : byte[]
o Esta variable forma parte de la funcionalidad para comunicarse con el
DNIe, en concreto este comando realiza la selección de la carpeta raíz
donde se encuentran los datos del DNIe
[privado] baCommandAPDUCDF : byte[]
o El presente atributo es otro comando a enviar a la tarjeta que, al ser
enviado, realiza la selección del fichero de datos que se encuentra en
formato CDF
[privado] baCommandAPDUn : byte[]
o [Donde n es un número de 1 a 6] Realiza la petición de los datos
públicos sobre el DNIe. Han de partirse en 6 diferentes puesto que por
el bus de comunicaciones tiene un máximo de envío/recepción de datos
y por ello tenemos que recibir todos los datos en seis trozos contiguos
[global] DNI_LENGTH : int
o Este atributo da la longitud del número de dígitos con la letra del DNI a
usar en todo el programa, dado que en muchas otras aplicaciones del
mundo real existen problemas al determinar la longitud del DNI
teniendo que realizar un ajuste con ceros a la izquierda
Métodos:
[público] connect() : void
Figura 33. Clase DNIeCard
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
35
o Realiza la función de conexión con el periférico y en caso de haber
una tarjeta inicializa el atributo card. Lanzará una excepción en caso de
no encontrar el chip que ha de ser capturada por la clase que llame a
este método
[público] disconnect() : void
o Desconecta cualquier tipo de conexión que haya con los periféricos y
pone el atributo card a null
[privado] getCardTerminal(terminals : List<CardTerminal>) : CardTerminal
o Obedeciendo a las restricciones de diseño de solamente conectar con
un terminal, este método devuelve un objeto CardTerminal cuyo
terminal periférico lector de smart-cards se corresponde con el primer
terminal de la lista obtenida
[privado] getTerminals() : List<CardTerminal>
o Devuelve una lista parametrizada con objetos del tipo CardTerminal
(perteneciente a la clase smartcardio)
[privado] getCard(cardTerminal : CardTerminal) : Card
o Devuelve un objeto de la clase Card cuyo objeto representa una
conexión con la tarjeta inteligente, en nuestro caso, el DNIe
[público] readPublicData() : String
o Apoyándose sobre los comandos APDU definidos en la parte de los
atributos, éste método realiza toda la lógica necesaria de ir obteniendo
todos las partes necesarias de los datos públicos del DNIe, juntarlas y
devolverlas en un objeto String
[privado] sendRootFileFirstCommands(channel : CardChannel)
o Envía los primeros comandos a través del canal pasado por parámetro
(channel) para elegir la carpeta raíz donde se encuentran los datos del
DNIe y elige el fichero de datos de formato CDF donde están los datos,
dejando posicionado el puntero de lectura justo antes de los datos del
DNIe
[privado] sendCommandAPDU(CardChannel : channel, command : byte[])
o Envía a través de un canal de transmisión con el periférico, un comando
APDU. Ambos objetos pasados por parámetros
[privado] addFirstToSecond(first : byte[], second : ByteArrayOutputStream)
o El fin de este método es dar apoyo al méotod readPublicData(), ya que
realiza la función de añadir una cadena de bytes que son leídas en ese
momento del terminal y se agregan al segundo objeto second para así al
final tener una estructura válida de datos con formato ASN.1 y poder
parsearlos de manera que sean legibles para el usuario
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
36
3.3.1.3. Clase HTMLWriter
Atributos:
[privado] randomFile : RandomAccessFile
o Atributo que proporciona la funcionalidad de acceso a un fichero en el
disco duro gracias
[privado] dateFormat : SimpleDateFormat
o Este atributo permite definir la fecha actual en el formato que
necesitemos que en nuestro caso será, día, mes y año
[privado] path : String
o Representa la ruta del fichero en disco donde se almacenarán los datos
registrados por la aplicación en formato HTML
[privado] positiontWriteNewRow : long
o Este atributo ayuda a la funcionalidad que realiza esta clase de escribir
en un fichero, llevando en todo momento la posición en que nos
encontramos dentro del fichero
Métodos:
[público] HTMLWriter(path : String) : String
o Constructor que instancia un objeto de la clase HTMLWriter y que es
necesario un String de entrada con formato de ruta de fichero puesto
que será el que defina dónde se grabaran los datos en disco durante esa
instancia
[público] writeNewRow(dni : String, name : String) : void
o Este método posiciona el puntero de escritura entre el último nombre
añadido y el cierre del tag de HTML “</table>” y entonces escribe en
esa posición todo el formato necesario para representar otra fila en la
tabla HTML con los datos obtenidos por la aplicación
Figura 34. Clase HTMLWriter
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
37
[público] loadTemplate(filename : String) : void
o Permite retomar la escritura de registros sobre un fichero ya existente
en disco
o Lanzará, en caso de no encontrar el fichero, una excepción del tipo
IOException
[público] deleteTemplate(filename : String) : void
o Borrará de disco el fichero HTML
o Lanzará, en caso de no encontrar el fichero, una excepción del tipo
IOException
3.3.1.4. Clase DNIPublicData
Atributos:
[global] MEMBERS_FILE_NAME : String
o Representa una variable global que determina el nombre del fichero sin
la extensión, dónde se registrarán los datos de los DNIe introducidos
[global] LOGGER_FILE_NAME : String
o Define el nombre con extension del fichero donde se guardarán ciertos
estados de la aplicación con fines de realizar la depuración más fácil
[privado] dateFormat : SimpleDateFormat
o Este atributo permite definir la fecha actual en el formato que
necesitemos que en nuestro caso será, día, mes y año
[privado] dataPath : String
o Define la ruta en cuanto a la carpeta se refiere, donde se almacenará el
fichero de registros
Figura 35. Clase DNIPublicData
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
38
[privado] htmlWriter : HTMLWriter
o Instancia de la clase HTMLWriter para realizar todas las funciones de
registrar a las personas que introduzcan su DNIe en un fichero de
formato HTML
[privado] peopleCount : CountPeople
o Instancia del objeto de la clase CountPeople para llevar y mantener una
cuenta de las personas registradas en esa sesión de la aplicación
Métodos:
[público] DNIPublicData(dataPath : String, logPath : String)
o Constructor en el cual se obliga a introducir el directorio donde se
almacenará el fichero de usuarios en HTML y el fichero de LOG para
depuración
o Es importante mencionar que en este punto, como clase cuyo rol es de
“Controlador” en MVC, se realiza la conexión entre la vista y la propia
clase para así asegurar el flujo de datos entre las demás clases
[privado] initializeLogger(logPath : String) : void
o Método auxiliary para inicializar, con los datos proporcionados desde el
constructor, el objeto de la clase Logger que funciona a modo de patrón
“singleton”
[público] startView() : void
o Este método permite que la vista sea visible, recordando que las vistas
en Java son bloqueantes y por ello se inicia en un hilo a parte
[público] getPublicDataFromCard() : List<String>
o Devuelve los datos ya legibles por el usuario en una lista List
parametrizada con objetos de tipo String en cuyas posiciones de índice
0 y 1 se encuentran el número de DNI y el nombre del titular asociado a
ese número de DNI respectivamente.
[público] writeNewMember(dni : String, name : String) : void
o Este método escribe, abstrayéndose de qué tipo de registro es el
formato de destino, un nuevo registro con el DNI (dni) y el nombre
(name) pasados por parámetros
[público] appClosing() : void
o Este método es llamado en el momento en que la aplicación se está
cerrando y realiza las funciones de cerrar debidamente el archivo de
registros, escribir en otro fichero el total de personas que se han
registrado durante esa sesión de la aplicación y cerrar los ficheros
abiertos
[público] main(args : String[]) : void
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
39
o Método principal que inicia toda la lógica de la aplicación. En este
punto se inicializan las carpetas donde se almacenarán los ficheros de
registros y de logs por separado así como de hacer visible la vista
asociada
3.3.1.5. Clase CountPeople
Atributos:
[privado] peopleCount : int
o Atributo donde se almacena la cuenta de las personas registradas
durante esa sesión de la aplicación
Métodos:
[público] CountPeople()
o Constructor que inicializa peopleCount a cero
[público] CountPeople(countFrom : int)
o En este caso la sobrecarga del constructor permite comenzar la cuenta
desde un número determinado
[público] addOnePerson() : void
o Mediante este método se permite sumar sólo una unidad al contador
de personas registradas
[público] getPeople() : int
o Devuelve el número de personas registradas hasta ese momento
durante el tiempo que se ha estado ejecutando la aplicación en una
sesión
[público] addPeople(howManyMore : int) : void
o Permite añadir más de una persona a la vez al contador almacenado en
el atributo peopleCount
Figura 36. Clase CountPeople
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
40
3.3.1.6. Clase DNIChecker
Atributos:
[privado] DNI_NUMBER_COUNT : int
o Es una variable fija que da la cuenta de los dígitos que tiene un DNI
dentro de esta aplicación
[privado] DNI_COUNT : int
o Esta variable también es fija, y en su caso proporcionará el número de
caracteres totales que ha de tener un DNI
Métodos:
[público] check(dni : String) : Boolean
o Método que comprueba mediante un algoritmo si la letra introducida
en el DNI pasado por parámetro dni es la correcta o de lo contrario es
una cadena que no cumple el formato de un DNI
3.3.1.7. Clase DNIPublicDataView
Figura 37. Clase DNIChecker
Figura 38. Clase DNIPublicDataView
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
41
Atributos:
[privado] autoTab : Boolean
o Este atributo verifica que esté pulsado el CheckBox que propociona la
funcionalidad de cambiar automáticamente el foco entre cajas de texto.
En caso de estar pulsado, este atributo toma el valor booleano “true”
[privado] firstColor : Color
o El fin único de este atributo es la cualidad de proporcionar integridad y
escalabilidad a la aplicación en caso de que queramos cambiar el color
del botón de “Guardar Datos” registros puesto que almacena el primer
color que estuviese ajustado y a la hora de hacer click sobre dicho
botón, esta variable mantendría el color con el que se inicializa y lo
haría volver a su estado después de las acciones o eventos ocurridos
[privado] admitButton : JButton
o Control del tipo JButton el cual nos servirá de ayuda en cuanto al acceso
a sus propiedades
[privado] automaticChangeCheckBox : JCheckBox
o Control del tipo JCheckBox que permitirá acceder a su estado para
completar la funcionalidad de cambio automático entre cajas de texto
con el soporte en la variable anteriormente mencionada, autoTab de
tipo Boolean
[privado] clearDataButton : JButton
o Control del tipo JButton necesario a la hora de deshabilitar el
componente de interfaz de usuario asociado a él (botón) cuando se
estén obteniendo los datos desde el periférico y cambiando el texto que
se muestra en éste
[privado] getDataButton : JButton
o Control del tipo JButton cuya casuística es igual a la de clearDataButton
sólo diferenciándose en el texto que se mostrará sobre el botón
[privado] jTextFieldn : JTextField
o [Donde n es un número de 1 a 8] Son los objetos controladores de las
cajas de texto asociadas a los números de un DNI donde se podrá
introducir solamente un único dígito por caja de texto
[privado] jLabeln : JLabel
o [Donde n es un número de 1 a 4] Son los objetos que permiten dar
claridad en el manejo de la interfaz de usuario mediante etiquetas
Métodos:
[público] DNIPublicDataView(observer : DNIPublicDataObserver)
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
42
o Constructor que asocia a la presente vista un objeto del tipo
DNIPublicDataObserver, que, como queda documentado con
anterioridad, sus instancias son del tipo DNIPublicData y que sustenta el
flujo de los datos entre la vista, el controlador, modelo y dem
[privado] admitButtonActionPerformed(evt : KeyEvent) : void
o Método que se ejecuta en el momento en que se hace click sobre el
botón de guardar un registro cuya funcionalidad se basa en hacer las
llamadas necesarias (notificar al observer) para escribir un nuevo
registro en el archivo de DNI y mostrar al usuario mediante el cambio de
la interfaz de que la operación se ha realizado correctamente (destello
del botón en color verde) o no (destello en color rojo)
[privado] getDataButtonActionPerformed(evt : KeyEvent) : void
o Este método realiza las llamadas pertinentes al objeto Observer de la
clase DNIPublicDataObserver con el fin de obtener los datos desde el
periférico conectado mediante el puerto USB.
[privado] clearDataButtonActionPerformed(evt : ActionEvent) : void
o Método que se ejecuta a la hora de pulsar el botón de interfaz de
usuario “Limpiar Datos” cuya funcionalidad es realizar la llamada a
borrar todos los datos que hubiere en las cajas de texto y posicionar el
foco sobre la caja de texto de interfaz de usuario donde se introduce el
nombre
[privado] letterFieldKeyTyped(evt : KeyEvent) : void
o Este método se ejecuta cuando se inserta un carácter en la caja de texto
perteneciente a la representación de la letra del DNI. Su funcionalidad
reside en comprobar si efectivamente el carácter introducido es una
letra y no un dígito
[privado] automaticChangeCheckBoxActionPerformed(evt : KeyEvent) : void
o Este método se ejecuta cuando hacemos click sobre el CheckBox de
interfaz de usuario “Cambio Automático” y en dicho caso, cambiará el
valor de la variable autoTab al valor booleano que corresponda
[privado] nameSurnameFieldKeyReleased(evt : KeyEvent) : void
o Este método se ejecuta cada vez que soltamos una tecla al escribir
sobre la caja de interfaz de usuario donde escribimos el nombre del
individuo a registrar, y su funcionalidad es comprobar si la tecla soltada
ha sido la correspondiente al código de retorno de carro y en este caso,
saltar al primer dígito de inserción de DNI
[privado] formWindowClosing(evt : WindowEvent) : void
o Este método realiza las llamadas necesarias al objeto observer de la
clase DNIPublicData para realizar un cierre correcto de la aplicación
[privado] showCardException(ex : Exception) : void
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
43
o Método que muestra el mensaje de una excepción pasada por
parámetro en una ventana nueva de alerta
[privado] showError(message : String) : void
o Método que muestra el mensaje pasado por parámetro en una ventana
de error
[privado] setDNIText(dniText : String) : void
o Este método realiza la funcionalidad de poner cada carácter del número
de DNI obtenido desde el periférico lector de DNIe en su
correspondiente caja de texto
[privado] cleanDataFromTextFields() : void
o El presente método queda documentado en
clearDataButtonActionPerformed(…) puesto que es llamado desde
dicho contexto
[privado] getJTextArray() : JTextField[]
o Método privado y auxiliar que proporciona a la aplicación el array con
las referencias a los objetos controladores de las cajas de texto de la
interfaz de usuario
[privado] getDNIText() : String
o El método devuelve una referencia a un objeto de tipo String en el cual
se encuentran los datos del número del DNI que en ese momento se
visualizan en pantalla introducidos en sus respectivas cajas de text
[privado] admitButtonGlitter(b : Boolean) : void
o Este método realiza el cambio de color del botón “Guardar Datos” de
interfaz de usuario que registra un individuo asociado a un DNI según el
parámetro de entrada booleano. En caso que resuelva a “True” el
parámetro, se realizará el cambio a verde dando información de que la
operación ha sido correcta, en caso “False” se verá en color rojo dando
información de error y pasado un tiempo volverá a su color inicial
gracias a la variable firstColor
[público] disableGetData() : void
o Método que deshabilita las componentes de interfaz de usuario que
pudiesen intervenir en el correcto funcionamiento de la funcionalidad
deseada. Actualmente deshabilita los botones de getDataButton
admitButton y clearDataButton
[público] enableGetData() : void
o Realiza el caso contrario a disableGetData() puesto que revierte todos
los cambios y devuelve a las componentes de interfaz de usuario a su
estado inicial
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
44
3.3.1.8. Clase JTextFieldLimit
Atributos:
[privado] limit : int
o El presente atributo define el límite de caracteres a insertar en un
campo de tipo JTextField sobre el que se inicializará esta clase para
proveer dicha funcionalidad
[privado] toUppercase : Boolean
o Booleano que define si el campo de texto ha de estar en mayúsculas o
minúsculas
[privado] isNumber : Boolean
o Booleano que define si el campo de texto ha de ser de tipo número o
no, es decir, sólo se pueden introducir dígitos
Métodos:
[público] JTextFieldLimit(limit : int)
o Constructor que permite definir el límite de caracteres a insertar en una
caja de texto JTextField
[público] JTextFieldLimit(limit : int, upper : boolean)
o Como en el caso anterior del constructor, pero se añade la posibilidad
de especificar si se quiere en mayúsculas o minúsculas
[público] JTextFieldLimit(limit : int, upper : boolean, number : boolean)
o Idem al anterior más en este caso se especifica si el campo es numérico
[público] insertString(offset : int, str : String, attr : AttributeSet) : void
o Método que prove la funcionalidad de insertar un objeto String pasado
por parámetro con un desplazamiento o posición (offset) y una serie de
atributos como puede ser la fuente del texto definidos en la variable por
parámetro attr
[privado] isInt(text : String) : Boolean
Figura 39. Clase JTextFieldLimit
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
45
o Método que realiza la comprobación de si un String pasado por
parámetro es un número entero
3.3.1.9. Clase DNIPublicDataObserver
Métodos: (Dado que es una interfaz, estos métodos quedan documentados en su
implementación en DNIPublicData)
[público] getPublicDataFromCard() : List<String>
[público] writeNewMember(dni : int, name : String) : void
[público] appClosing() : void
3.3.2. Diagramas de estados
3.3.2.1. Proceso de lectura de los datos del DNIe desde el periférico
Se ha decidido modelar este proceso por ser uno de los principales cometidos de la
aplicación a desarrollar y por contener partes que no dependen enteramente de la
aplicación sino, de los proceso de negociado de claves y datos internos al driver del
DNIe.
Este proceso tiene su inicio en el momento en el que se decide realizar la acción de
leer los datos públicos del DNIe, en nuestro caso, en el mismo momento que se pulsa
el botón “Obtener Datos”.
Figura 40. Clase DNIPublicDataObserver
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
46
Comprobación Driver
En este estado, más del sistema operativo y los drivers del DNIe que de la aplicación
pero aún así, afecta de manera indirecta a la aplicación bajo un entorno con la
configuración por defecto.
En primera instancia y si es la primera vez que se introduce el DNIe éste intentará
realizar una serie de comprobaciones e intentará, sin ningún tipo de aviso al usuario, la
instalación de los drivers y certificados necesarios para el correcto funcionamiento y
uso del DNIe.
Posteriormente y en las siguientes veces que el driver del DNIe se encuentre en el
sistema se comprueban datos tales como que los certificados no estén caducados, se
Figura 41. Diagrama de Proceso lectura
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
47
verifican los certificados que contiene el DNIe (el que provee el cuerpo nacional
de policía y el certificado del ciudadano)
(Condicional) Introducción Pin Correcto
Posteriormente a realizar las comprobaciones para el funcionamiento del driver, se
pedirá por pantalla el código PIN que se otorga al ciudadano junto con el DNIe en su
expedición. Bajo una configuración por defecto y con todos los servicios que soportan
el uso del DNIe activados, este diagrama obedece a la realidad, esto es: si se introduce
el PIN correctamente dejará funcionar al programa correctamente, de lo contrario
saldremos del flujo de la obtención de datos puesto que al no introducir el pin
correctamente no será posible la obtención de los datos públicos del DNIe, a pesar de
ser públicos.
Comprueba Periféricos
Durante el intento de obtención de datos, se comprueba que hayan periféricos
conectados y en caso de no haberlos se sale del flujo de actividades. En caso que lo
hubiere, se selecciona el correspondiente al que esté conectado a la posición 0 dentro
de todos los posibles periféricos conectados a los puertos USB (esto es dependiente de
cada máquina y cómo reconozca la placa base las posiciones de los USB, por tanto no
se ha considerado implementar a nivel de la aplicación).
Comprueba DNIe
Al igual que se realizan comprobaciones a nivel de drivers y periféricos, en este estado
se realizan las comprobaciones pertinentes a que haya un DNIe introducido en el
periférico lector de tarjetas inteligentes y en el caso de no haberlo se terminaría el
flujo de proceso de la actividad.
Lectura Datos en ASN.1
Llegados a este estado, se puede leer con seguridad del chip contenido en el DNIe. En
este estado se realizan en primer lugar el envío de comandos, byte a byte dados en la
especificación para posicionarse sobre las carpetas y ficheros sobre los que se quiere
realizar la lectura de los datos.
Posteriormente, la cadena de bytes, se pasará al parser de ASN.1 que formateará los
datos leídos en un formato de caracteres alfanuméricos legibles para ser,
posteriormente leído, aún bajo formato ASN.1 por el parser de ASN.1 al formato que
mostraremos por pantalla.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
48
Por tanto, tenemos dos procesos de intercambio de formatos en este estado: De
binario ASN.1 a alfanumérico ASN.1 y de alfanumérico ASN.1 a cadenas de caracteres
donde encontraremos el código del DNI y el nombre del ciudadano.
Mostrar datos en cliente
En este estado previo a finalizar el flujo se muestran los datos obtenidos en el estado
anterior, sobre la interfaz de usuario en sus correspondientes posiciones dando así
información de que la operación se ha ejecutado correctamente
3.3.2.2. Proceso de registro en disco de los datos públicos de un DNI
Al igual que decidimos realizar el modelado del proceso de lectura desde el periférico
se ha decidido modelar el que se ha considerado el segundo proceso más importante
de la aplicación que engloba la mayor parte del sistema y que es la escritura a disco de
los datos introducidos u obtenido.
El inicio de este proceso se da en el momento en que quedan escritos en pantalla
todos los datos necesarios para crear un nuevo registro en el fichero creado en disco.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
49
Introducción de datos
Este estado engloba el primer proceso modelado como diagrama de
actividades/estados, por tanto es una abstracción de este unido también al estado en
que se permite introducir al usuario los datos por pantalla.
Por tanto en este estado se introducen los datos en la pantalla de interfaz de usuario
ya sea por parte de la lectura desde el periférico o por método de entrada manual.
Comprobación de datos DNI
Figura 42. Diagrama de Proceso escritura
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
50
Se comprueba que todas las cajas de texto de la interfaz de usuario estén
rellenas y en caso contrario se mostraría un aviso por pantalla obligando a rellenar
todos los campos de texto. En este mismo estado se comprueba con el algoritmo de
comprobación de letra del DNI, si la letra coincide con los números introducidos en
cuyo caso se informa al usuario mediante una ventana de alerta que la letra no
coincide con los datos introducidos
Incrementar cuenta registros
En este estado se realizan las llamadas necesarias a las distintas clases para
incrementar el contador de registros de DNI a uno.
Acceso a disco
Se comprueba que haya acceso a disco y que el fichero sobre el que se va a escribir
exista de lo contrario se mostrará un error y se saldrá del flujo de ejecución.
Leer fichero
Previa escritura, y con el fin de escribir los registros de una manera ordenada se lee el
fichero sobre el que se va a escribir y se comprueba si tiene ya datos, escribiendo así
otro campo fila de tabla con sintaxis HTML.
Escritura del registro
Se procede a insertar en sintaxis HTML todos los datos introducidos así como la hora
del registro.
Informar al usuario
En este estado se borrarán todos los datos por pantalla, se pasará el foco de escritura a
la primera caja de texto de la interfaz de usuario y se hará brillar el botón pulsado en
verde dando a entender que la ejecución ha sido la correcta.
3.3.3. Diagramas de Secuencia
A continuación, y como últimos diagramas UML que representaremos de la aplicación,
se modelan los diagramas de secuencia de los dos procesos que se han considerado
más importantes de la aplicación, dejando declarado así, unívocamente cuales son
todos los elementos dentro de la aplicación que dependen y se inmiscuyen en la
ejecución de ambos.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
51
3.3.3.1. Proceso de lectura de los datos del DNIe desde el periférico
En el siguiente diagrama se muestra el proceso de ejecución y llamadas entre clases
que dan lugar a la obtención de los datos desde el periférico lector de smart-cards y
posteriormente el muestreo de dicha información al usuario.
Todo ello emana desde el usuario puesto que es la interacción de este con la interfaz
de usuario al pulsar el botón “Obtener Datos” la que inicia todo el proceso de
obtención de los datos públicos del DNIe.
Figura 43. Diagrama de secuencia de Proceso lectura
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
52
3.3.3.2. Proceso de registro en disco de los datos públicos de un DNI
El diagrama modelado a continuación, representa segundo proceso elegido, el de
escritura de unos datos introducidos correspondientes a un DNI a disco en formato
HTML.
Al igual que el otro proceso, este surge gracias a la interacción del usuario con la
interfaz gráfica de la aplicación en el momento en que éste hace click sobre el botón
de “Guardar Datos”
3.4. Validación y trazabilidad de los requisitos En esta sección procederemos a mostrar toda la trazabilidad que hay entre requisitos y
los diagramas modelados y expuestos verificando así que se han cumplido todos los
requisitos que inicialmente se definieron para la aplicación
3.4.1. RF-001
Para este requisito se contempla la clase DNIPublicDataView que como vemos en el
proceso de escritura de datos a disco, en el diagrama de actividades/estados se
contempla la posibilidad de que los datos vengan desde la interfaz de usuario.
Los componentes de la clase JTextField satisfacen este requisito y aseguran el flujo y
manipulación de dichos datos en estados intermedios.
En la siguiente imagen podemos comprobar cómo se hará la introducción de datos
manualmente por parte del usuario.
Figura 44. Diagrama de secuencia de Proceso escritura
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
53
3.4.2. RF-002
Este requisito, el cual especifica que se realice una correcta lectura de los datos del
DNIe, es satisfecho mediante la interacción y flujo de datos entre las clases
DNIPublicDataView, DNIeCard, DNIPublicData y ASN1DNIParser como clases creadas
durante el desarrollo de la aplicación.
Podemos observar que en el momento que se pulsa el botón de “Obtener Datos”,
observamos en el diagrama de secuencia 1 que se realiza una llamada a
disableGetData() que deshabilita todos los componentes que realizan funcionalidad en
la vista como vemos a continuación
Figura 45. Aplicación con introducción de datos
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
54
3.4.3. RF-003
El cumplimiento de este requisito se da gracias a las clases DNIPublicDataView,
DNIPublicData y HTMLWriter ya que desde la vista de usuario se cogerán los datos
para al final insertarlos en un fichero HTML cuya representación podemos ver en la
siguiente imagen.
Figura 46. Aplicación leyendo en bloqueo
Figura 47. Aplicación tabla de registros en HTML
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
55
3.4.4. RF-004
Este proceso es interno a la clase DNIPublicDataView el cual hace referencia a todos
los objetos que figuran como entrada de texto por parte del usuario y los vacía de
datos dejando en última instancia el foco en el nombre para que el usuario comience a
introducir datos si lo desea.
En el diseño, el botón que cumple este requisito se encuentra en la parte inferior
izquierda y adjunta un texto que lee “Limpiar Datos” como podemos observar en la
siguiente imagen:
Figura 48. Aplicación limpiar datos
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
56
3.4.5. RF-005
Al pulsar el botón de “Obtener Datos” y comenzar la secuencia del proceso de lectura
de datos públicos visto en el diagrama de secuencia del punto 3.3.3.1 podemos
observar que se realiza una llamada al método connect() de la clase DNIeCard el cual
internamente realiza otra llamada a la función getCardTerminals() el cual comprueba
que haya periféricos lectores conectados al equipo.
Como se especifica en el requisito y en caso que no se satisfaga la condición de haber
un periférico conectado se mostrará una pantalla de información como se dibuja a
continuación:
3.4.6. RF-006
Como en el caso de trazabilidad anterior, al pulsar el botón “Obtener Datos” y dentro
de la llamada al método connect() (3.3.3.1) se realiza la comprobación de obtención de
una tarjeta a través de los periféricos mediante la llamada a la función getCard().
En este caso se ha tenido que cumplir con una casuística un tanto amplia puesto que
puede haber un DNIe insertado de diferentes maneras, como por ejemplo puede ser
del revés o al inverso (girado en horizontal o vertical) y en este caso el periférico lo
detecta pero no detectaría el chip, por ello y para satisfacer el requisito mostraremos
dependiendo de la casuística las siguientes pantallas de información:
Figura 49. Aplicación información fallo terminales
Figura 50. Aplicación información fallo encontrar
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
57
3.4.7. RNF-001
Gracias a los métodos implementados por los objetos la clase JTextField contenidos en
la clase DNIPublicDataView se hace posible la posibilidad de dar el foco a un
componente determinado, y así, poder ir pasando de caja de texto a otra según se
inserten los datos. Esta capacidad se activa mediante el checkbox cuyo texto es
“Cambio automático” que podemos observar en la siguiente imagen
3.4.8. RNF-002
Este requisito se ha implementado gracias al algoritmo de comprobación de la letra del
código DNI dado por la clase DNIChecker cuyo único método global es check() y que
devuelve si el código es correcto.
Figura 51. Aplicación información fallo lectura
Figura 52. Aplicación información fallo conexión
Figura 53. Aplicación botón cambio automático
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
58
3.4.9. RNF-003 y RNF-004
Esta salvedad en los campos de texto viene dado por la capacidad que nos proporciona
la clase JTextFieldLimit la cual nos permite dar límites a los campos creados bajo los
objetos JTextField, dónde podemos estipular el número de caracteres a insertar, si es
todo en mayúsculas o si el campo es numérico o de texto, siendo estas dos últimas
cualidades exclusivas, es decir, si un campo es de texto no se permiten introducir
números y viceversa.
3.4.10. RNF-005 y RNF-006
Estos requisitos se han decidido cumplir de una manera puntual dentro del sistema, es
decir, ya que sólo se pide que cambien del color original a rojo o a verde, se ha
implementado en la clase un método que mediante la entrada de un parámetro
cambiará el botón dado al color pedido independientemente desde dónde se llame.
En nuestro sistema estas llamadas, como especifica el requisito, se realizan en los
puntos de llamada a admitButtonActionPerformed() pues, en caso de ser la ejecución
satisfactoria se lanzará la llamada a admitButtonGlitter(), con parámetro boolean True
parpadeando así en verde y en caso de ser una ejecución fallida, es decir, ha ocurrido
alguna excepción se ejecutará con parámetro boolean True que dará lugar al parpadeo
rojo.
Figura 54. Aplicación fallo letra DNI
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
59
4. Conclusiones y propuestas En este apartado realizaremos una puesta a punto sobre los objetivos que se
definieron en el punto 1.6. dando lugar así a una breve explicación de los mecanismos
encontrados y abordados durante el desarrollo y análisis de la aplicación. También
daremos una serie de propuestas para posibles implementaciones, usos y proyectos
futuros que pudieran ser de utilidad sobre este DNIe o la próxima versión por llegar
DNIe 3.0. Finalizaremos con unas reflexiones sobre el impacto del DNIe y el impacto
proyectado de esta aplicación con unas conclusiones a título personal como colofón
final.
4.1. Objetivos alcanzados Se ha conseguido obtener un sistema que facilite la obtención y lectura de los datos
públicos del DNIe gracias al desarrollo de la aplicación “Aplicación lectora de datos
públicos sobre DNIe” así como un entendimiento más profundo de los procesos
realizados a diario para la identificación de los usuarios.
Durante el desarrollo se han ido estableciendo y definiendo las diferentes partes del
proceso software, desde su fase de requisitos hasta la fase de implementación
pasando por las distintas etapas que validan y verifican dicho proceso.
El desarrollo de dicha aplicación ha supuesto la creación y uso de librerías que
permiten el acceso a dichos datos de diferentes maneras. A nivel de byte, a nivel de
formato ASN.1 y a nivel de texto.
4.2. Propuestas para futuras implementaciones Se observa que a día de hoy la implementación y uso del DNI electrónico es cercana a
ser nula o inexistente, y esto, como hemos estudiado en este trabajo, se debe a las
dificultades que de una manera u otra resultan por dejar en manos del usuario final y
poseedor del DNIe toda la responsabilidad en cuanto a trámites.
Por ello se consideran los siguientes puntos a los cuales podría darse la aplicación del
DNIe bajo nuevas implementaciones siguiendo la base que da la aplicación
desarrollada aquí.
4.2.1. Uso en la administración del estado
Durante la realización de este trabajo se han acudido a oficinas de administración
pública, concretamente del INEM y se ha podido observar que a la hora de registrar a
ciudadanos españoles poseedores del DNIe se sigue realizando la introducción de
datos manualmente.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
60
Una implementación que agilizaría dichos trámites sería la implementación de
una interfaz que se comunicase con dichos programas orientados a la burocracia
estatal para ganar tiempo y reducir errores en la inserción de ciertos datos de control
del ciudadano a la hora de realizar gestiones.
4.2.2. Sistema de firmado de datos
En internet existen infinidad de sistemas de comunicación de datos, y por esto, existe
la necesidad de que ciertos datos puedan ser verificados por el receptor en ciertas
ocasiones de envío de datos críticos.
Por ello se inventaron los sistemas de cifrado y firma presentes hoy en gran cantidad
de páginas web y correos que viajan firmados e incluso cifrados gracias a, por ejemplo,
PGP (Pretty Good Privacy).
Como hemos visto en este documento, el DNIe carece de prestaciones para el cifrado
de mensajes pero sí posee certificados que son unívocos a cada ciudadano, es decir,
mediante estos certificados se podría obtener la validez de que un ciudadano es quien
dice ser y por tanto generar otros tipos de claves y o certificados únicos asociados a
este DNIe para poder así cifrar y/o firmar cualquier tipo de datos que se envíen a
través de la red verificando así que quien envía los datos es el ciudadano identificado.
4.2.3. Sistema de registro para establecimientos
Un uso próximo y que no requeriría de mucha ampliación sobre la implementación
sería el uso de un sistema para el registro de asistentes a cualquier tipo de evento
dónde haya que llevar un recuento de personas e identificarlas unívocamente
pudiendo así manejar un registro fiable de todos los asistentes.
4.3. Impacto y reflexión sobre los aspectos sociales,
ambientales y ético/legales
4.3.1. Aspectos sociales
El impacto social que el DNIe tiene a día de hoy es realmente amplio puesto que es una
herramienta, un documento y un dato intransferible para cada individuo que lo declara
como ciudadano español ante el sistema estatal.
Por ello tenemos que el DNIe es una pasarela, si no la principal, que facilita a cualquier
ciudadano al acceso de cualquier servicio de primera necesidad, como lo pueden ser,
el acceso a la salud pública, vivienda, servicios de agua y saneamiento, educación, etc.
También cubre los derechos humanos puesto que la participación en la sociedad deriva
intrínsecamente de formar parte de esta, la sociedad como un ente de aporte.
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
61
Cabe destacar que la aplicación desarrollada podría ejercer un impacto sobre la
accesibilidad y usabilidad para el ciudadano medio puesto que, podría facilitar trámites
dando una capa de abstracción al usuario.
Como un punto final sobre el impacto social que el DNIe posee, y que si bien no ha
calado como estaba proyectado, ha sido la mejora de productividad en tanto a que
muchos trámites se realizan de manera más rápida y ágil a través de internet y gracias
al DNIe.
4.3.2. Aspectos ambientales
Sobre los aspectos ambientales cabe poco que decir puesto que el único impacto que
por el que quizá se vería afectado el DNIe es por la fabricación de periféricos
necesarios para la lectura de éste y por ello el impacto ambiental es aquel que se
genere en la fabricación de dichos periféricos, no obstante, el impacto es mínimo
puesto que dichos periféricos no sólo se usan para el DNIe, por lo que estamos ante un
caso de reutilización de materiales y de baja contaminación ambiental.
4.3.3. Aspectos éticos
Están estipulados como aspectos éticos la posibilidad de causar daños o riesgos, los
derechos inalienables, la justicia en su vertiente distributiva y el bienestar o bien
común.
Como podemos intuir, el uso del DNIe se encasilla básicamente en dos de estos
aspectos éticos: los derechos inalienables y la justicia.
El DNI como tal, forma parte de un flujo de información entre el ciudadano y el estado,
y como se produce dicho flujo de información es de esperar que los aspectos de
libertad, privacidad, autonomía y propiedad se vean afectados por ello.
Por otro lado pero, no separado de estos aspectos, está el uso de la identificación bajo
la justicia. Es de vital importancia la identificación y por ello, se trabaja en proveer a
todos los ciudadanos con el DNIe (en 2016 todo ciudadano español habrá de poseer el
DNI electrónico) para promulgar así una correcta integración social.
Pues, un ejemplo que engloba todos estos aspectos es el del derecho a voto, sólo
realizable mediante previa identificación dónde juega un papel importantísimo el DNI
para cualquier ciudadano español haciéndolo constar de manera legal y pudiendo
ejercer todos sus derechos constitucionales dentro del estado español.
4.4. Conclusión personal Mediante la realización de este Proyecto de Fin de Grado se han realizado y afianzado
una amplia sección de los recursos aprendidos durante la carrera y es que, la ingeniería
del software, es algo necesario que está aún a día de hoy muy dejado de lado durante
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
62
el proceso de vida de proyectos software. He logrado comprender el concepto
que durante toda la carrera se hace hincapié pero por falta de tiempo o de concepto
no se aprende hasta que se realiza un proyecto software desde su inicio hasta su
implementación.
He comprendido y cambiado la visión del desarrollador software, de la visión de un
programador que genera soluciones a problemas establecidos, a la visión de un
desarrollador software que genera servicios, interfaces, proyectos de manera escalable
que facilitan los procesos ya sean tecnológicos o no, a un determinado ámbito de la
vida real.
Con la creación de una aplicación como la desarrollada durante este trabajo todo ello
ha quedado claro que la comunicación, a la hora de realizar un proyecto software de
esta magnitud como lo es la del DNIe es primordial. Por otro lado un estudio de
accesibilidad y uso para el usuario final puesto que, como hemos destacado en las
primeras secciones de éste trabajo y reiterado en tantas otras, a pesar de ser una
herramienta eficaz, a día de hoy el DNIe no llega al 1% de su uso por parte de la
ciudadanía, por ello siempre es importante estudiar los hábitos del usuario final.
Por último destacar que a día de hoy, el ingeniero de software reúne unas cualidades
muy diversas y prometedoras, lo que augura buen futuro para todo aquel que decida
emprender su trayectoria por este camino. Los campos son muy amplios y hay muchas
áreas que todavía están en proceso de estudiar y definir, como lo es el DNIe.
En mi caso personal, la experiencia de poder trabajar sobre un elemento tan
importante de la sociedad española como es el DNI en su parte más tecnológica, es
decir DNIe, sin estar atado a excesivas restricciones de desarrollo puesto que se provee
código para diversas plataformas a todos los niveles de detalle, ha sido una experiencia
gratificante a la par de creativa y que me ha permitido obtener una experiencia bajo
un entorno de realización de un proyecto software.
Anexos
Bibliografía
Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agile Software
Delivery in the Enterprise by Scott W. Ambler and Mark Lines, IBM Press
eEspaña 2014 informe anual sobre el desarrollo de la sociedad de la
información en España, Fundación Orange
OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1
Smart Card Handbook: W. Rankl & W. Effing
Smart Card Security and Applications: Mike Hendry
Smart Cards Case Study: IBM Redbook
UNIVERSIDAD POLITÉCNICA DE MADRID – DNIe
63
EMV 2000 Specifications
Links
http://www.huffingtonpost.es/2015/01/12/nuevo-dni-
30_n_6455338.html?ncid=fcbklnkeshpmg00000001
http://www.eldiario.es/turing/dni-electronico-dnie_0_179182675.html
http://rebelion.org/noticia.php?id=122859
http://www.proyectosfundacionorange.es/docs/eE2014/Informe_eE2014.pdf
https://github.com/OpenSC/OpenSC/wiki
http://blog.48bits.com/2010/03/16/analisis-de-la-estructura-interna-del-dni-e/
http://www.redbooks.ibm.com/redbooks/pdfs/sg245239.pdf
http://www.cl.cam.ac.uk/~sjm217/talks/ccc08tamper.pdf
http://www.smartcardbasics.com/pdf/7100030_BKL_Smart-Card-Security-
Basics.pdf
http://users.dcc.uchile.cl/~rbaeza/cursos/proyarq/hlopez/index.html
http://www.alvestrand.no/x400/standards.html
http://www.agilemodeling.com/essays/umlDiagrams.htm
http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/
https://www.iso.org/obp/ui/#iso:std:iso-iec:7816:-1:ed-2:v1:en