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


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


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


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


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


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


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.

http://en.wikipedia.org/wiki/Groupe_Bull


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


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.


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.


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


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


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


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


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:


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


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

http://en.wikipedia.org/wiki/Grady_Booch

http://en.wikipedia.org/wiki/Ivar_Jacobson

http://en.wikipedia.org/wiki/Ivar_Jacobson

http://en.wikipedia.org/wiki/James_Rumbaugh


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.


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


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


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


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


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


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


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


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


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


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”


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.


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


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


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


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.


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


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


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


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


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


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


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


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)


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


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


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


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


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


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.


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.


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


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.


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


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


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


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


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


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


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


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


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.


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.


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


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


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

Date post:	30-Sep-2018
Category:	Documents
Upload:	trinhnhan
View:	218 times
Download:	0 times

Aplicación lectora de datos públicos sobre...

Documents