Sistemas de Control de Accesos

UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)

INGENIERO EN INFORMTICA
PROYECTO FIN DE CARRERA
SISTEMAS DE CONTROL DE ACCESOS

A EDIFICIOS MEDIANTE TARJETAS
CRIPTOGRFICAS Y TARJETAS RFID
AUTOR: MARTA VELAYOS SARDIA
MADRID, JUNIO 2007
Proyecto Fin de Carrera

Ingeniera Tcnica Superior de Informtica
Sistema de Control de Accesos a Edificios
Resumen
I

1. Descripcin general del Sistema

El proyecto Sistema de Control de Accesos a Edificios tiene como objetivo estudiar y
desarrollar dos tecnologas de control de acceso, basadas en la utilizacin de tarjetas
inteligentes y tarjetas de radiofrecuencia (RFID). Se ha desarrollado un sistema
destinado al Instituto de Investigacin Tecnolgico (IIT) de la Universidad Pontificia
Comillas, capaz de realizar dos tipos de controles de seguridad: por un lado, un control
de acceso del personal de dicho departamento y por otro lado, un control de inventario.
2. Aplicacin de Control de Visitas

La primera aplicacin que constituye el sistema final es Control de Visitas, destinada a
registrar las visitas que se realicen en el centro. Este subsisema utiliza la tecnologa de
tarjetas inteligentes, de manera que se comunica con un lector LTCX conectado al
ordenador del usuario final a travs de un puerto USB. Control de Visitas tiene como
finalidad proporcionar una aplicacin que permita al responsable del punto de control
llevar a cabo la gestin de las visitas que tengan lugar. Esta gestin consiste en:
Identificar al visitante: A partir de la lectura del carnet de alumno de la

Universidad.
II

Determinar la persona que se quiere

visitar: Consiste en seleccionar el
nombre del empleado a visitar de una
lista obtenida de la base de datos del
personal del departamento. En esta lista
se proporcionan los campos de la
extensin y el despacho donde se puede
localizar el empleado en cuestin, y as
facilitar su localizacin.
Confirmar el registro de la visita tratada en la base de datos correspondiente.
3. Aplicacin Control de Inventario

Se ha desarrollado la aplicacin de Control de Inventario, destinada a llevar a cabo un
seguimiento del estado de los recursos prestables (ordenadores porttiles, cmaras
digitales) que proporciona el departamento a sus empleados. La gestin de los
prstamos y devoluciones de los recursos se ha implantado con la tecnologa de
radiofrecuencia, de manera que para realizar este control el sistema se comunica con un
lector RFID, conectado al ordenador donde se ejecuta la aplicacin a travs de un puerto
USB. La identificacin de los recursos se consigue a partir de las tarjetas RFID que se
han asignado a cada uno de los equipos. Cuando se desee registrar un movimiento, se
proceder a leer el TAG designado al recurso, y el lector RFID transmitir los datos de
la lectura al sistema, el cual es el responsable de llevar a cabo la gestin correspondiente
del movimiento asociado. El sistema se encuentra integrado con la aplicacin de
Reservas Online donde cada empleado puede realizar la reserva del equipo que
necesite durante un periodo determinado.
III

4. Conclusin
Se han desarrollado dos aplicaciones de control de acceso, las cuales se han implantado
utilizando dos tecnologas de identificacin diferentes. Las ventajas ms importantes
que se han conseguido son:
Control de Visitas: Tecnologa de tarjetas inteligentes
Agilizar el proceso de registro de las visitas, minimizando considerablemente el

tiempo de cmputo que supone, al realizar la lectura de las tarjetas con esta
tecnologa, incluyendo el caso de que no se disponga del carnet de alumno.
Almacenamiento automtico de toda la informacin relativa a la visita: visitante,

visitado, hora
Ayudar al usuario final proporcionando informacin relativa a los empleados del

departamento: extensin, despacho
Control de Inventario: Tecnologa RFID
Llevar a cabo un seguimiento detallado del estado de los recursos del IIT.
Rpida identificacin de los recursos a partir de la lectura RFID de los TAGs.
Optimizar las tareas manuales y los procesos de negocio reduciendo los errores
de gestin, y sincronizacin del sistema con la base de datos de reservas.
IV

Abstract
V

1. General description of the system

The main aim of Buildings Access Control Systems project is to study and develop two
different control access technologies which are based on the use of Smart cards and
radiofrecuency ID cards. This system has been developed for the Institute for Research
in Technology (IIT) of Pontificia Comillas University, and it is able to perform two
types of security access: an access control of the departments visits, and an inventory
control.
2. Access Control Application

The first application, that forms the final system, is Access Control Application, used to
register visits to the building. This subsystem uses the intelligent cards technology, so it
has to communicate with a LTCX reader connected to the final users computer through
a USB port. The purpose of Visits Control is to provide an application that allows the
person is in charge of security control point for management. This management consists
of: identifying the visitor and registering his/her name.
This is done by:
Reading of the University student card
VI

Determining the person which is

visited: It consist of selecting the
employs name from a list
generated
form
database
of
personnel. In this list, the phone

and room number of the employ
are also shown to facilitate
contacting with the person to
announce the visit.
Confirmation the storage of the visit data into database.
3. Inventory Control
It has been developed the application Inventory Control which is responsible of
monitoring the status of shared resources (portable computers, digital cameras) provided
by the IIT department to its employees. The loans and returns management has been
implemented with the radiofrecuency technology, so to do this kind of control the
system has to communicate with a RFID reader, which is connected through a USB port
to the computer where the application is running. The resources identification is
performed with RFID cards attached to each equipment. To register good movements,
the RFID reader will read the resources TAG, and it will send the information to the
system which is responsible for managing that movement. The system is synchronized
with a database of reservations where the employees can define which equipment they
need and which dates.
VII

4. Conclusion
Two access control applications have been developed and implemented using two
different identification technologies. The main features attained are:
Visit Control: Smart Card Technology
Acceleration the registration process reducing typing to a minimum (only in case

the visit doesnt have an ID card) since ID cards is read using this technology.
Automatically storing in a database all the information related to each visit:

visitors name, employ visited, date-time.
Help the user during the registration process by providing information about the
employees: extension and room number.
Inventory Control: RFID Technology
To carry out a detailed and automated monitoring of the departments shared

resources.
Faster and accurate identification of the resource by applying RFID technology.
To optimize the manual tasks and business process to reduce the management
mistakes. Equipments are identified automatically and the system is
synchronized (query and update) with the database of reservations.
VIII

ndice
IX

Captulo
Pgina
1. Plan de Gestin del Proyecto
1.1. Introduccin
1.2. Definicin del proyecto
1.3. Diagrama de Actividades
1.4. Descripcin detallada de las Actividades
1.5. Organigrama del equipo de trabajo
12
1.6. Funcionalidad de los integrantes del equipo de trabajo
13
1.7. Estimacin y presupuesto
16
1.8. Planificacin de alto nivel
23
2. Documento de Conceptos del Sistema
24
2.1. Objetivos del sistema
25
2.2. Alcance del sistema
25
2.3. Tipologa de los usuarios finales
28
2.4. Restricciones
28
2.5. Antecedentes
30
3. Anlisis de Requisitos
31
3.1. mbito del proyecto
32
3.2. Contexto general del sistema
35
3.3. Evaluacin y anlisis
36
3.4. Modelo Fsico
47
3.5. Modelo Lgico
63
3.6. Modelo Conceptual de datos
67
4. Estudio de la Arquitectura
74
4.1. Especificacin de la tecnologa hardware

4.1.1.
Tarjetas Inteligentes
75
75

Captulo
Pgina
4.1.1.1. ISO 7816
75
4.1.1.2. Tipos de Tarjetas Inteligentes
79
4.1.1.3. Sistema de Ficheros
82
4.1.1.4. Mtodos de Acceso a la TI
82
4.1.1.5. Lector LTCX
85
4.1.2.
Tecnologa RFID
86
4.1.2.1. Funcionamiento
88
4.1.2.2. Protocolos y Opciones
89
4.1.2.3. Etiquetas RFID: TAGS
90
4.1.2.4. Estndar Mifare
92
4.1.3.
Plataforma donde reside el sistema
93
4.2. Especificacin de la tecnologa software y de comunicaciones
93
4.3. Arquitectura final del sistema
94
4.4. Evaluacin Econmica
95
4.5. Elaboracin del Plan de Proyecto
99
5. Diseo Externo
102
5.1. Requisitos fsicos del nuevo sistema
103
5.1.1. Entono operativo del sistema
103
5.1.2. Configuracin hardware/software
108
5.2. Desarrollo del Modelo Fsico Final
111
5.2.1. Fronteras de Mecanizacin
113
5.2.2. Especificacin de Procesos
116
5.2.3. Diseo de Entradas
121
5.2.4. Diseo de Salidas
123
5.2.5. Estimacin de Volmenes de Informacin
124
5.2.6. Procesos de Control y de Seguridad
128
XI

Captulo
6. Diseo Interno
Pgina
132
6.1. Tcnicas a utilizar
134
6.2. Subsistema online
135
6.2.1. El Diagrama de Cuadros Estructurado (STC)
136
6.2.2. Derivacin del DFD al STC
139
6.2.3. Consideraciones de diseo
148
6.3. Diagrama del Sistema
149
6.4. Cuaderno de Carga
150
7. Programacin
7.1. Anlisis y diseo orientado a objetos
159
161
7.1.1. Introduccin
161
7.1.2. Ciclo de desarrollo orientado a objetos
162
7.1.3. Tcnicas OO en las fases de la metodologa
163
7.2. Manual de Usuario
180
7.2.1. Manual de Usuario de Control de Visitas
182
7.2.2. Manual de Usuario de Control de Inventario
182
8. Pruebas
183
9. Implantacin
188
10. Conclusiones
190
11. Glosario de Trminos
193
12. Bibliografa
199
XII

Captulo
Pgina
Anexo 1
202
Anexo 2
212
Anexo 3
234
XIII

1. Plan de
Gestin
1

1.1. Introduccin
El presente documento define el Plan de Gestin del proyecto Sistema de Control de
Accesos, PSCA, contemplando los objetivos y alcance del proyecto, la estructura
jerrquica de las actividades principales describiendo una de ellas, la organizacin del
equipo de trabajo especificando la funcionalidad de uno de los perfiles, la estimacin y
presupuesto, y la planificacin determinada para la realizacin de dicho proyecto.
1.2. Definicin del Proyecto

Se desea desarrollar un sistema, destinado al Instituto de Investigacin Tecnolgico
(IIT) de la Universidad Pontificia Comillas (UPCO), capaz de realizar dos tipos de
controles de seguridad: por un lado, un control de acceso de visitas de dicho
departamento, de manera que facilite la gestin y el registro de las vistas que reciben
cada uno de los empleados, tanto de alumnos, como de personas ajenas a la
Universidad; y por otro lado, un control de inventario que permita llevar a cabo un
seguimiento de los ordenadores porttiles que proporciona el IIT a sus empleados, con
el objetivo de que stos puedan utilizarlos en lugares o contextos externos al dominio de
la universidad.
El control de visitas se implantar utilizando la tecnologa de tarjetas inteligentes, de

forma que cuando se atienda la llegada de una persona en el departamento, se solicitar
su carnet de identificacin personal para proceder a realizar el registro correspondiente.
Por ltimo, el Control de Inventario se realizar a partir de la utilizacin de un lector

de radiofrecuencia (RFID), de manera que cuando se desee registrar un prstamo o una
devolucin de alguno de los ordenadores porttiles, proporcionados por el IIT, se deber
mostrar al lector el TAG RFID que posee el recurso, para realizar el proceso de
identificacin del mismo.

1.3. Diagrama de Actividades

En este apartado se muestran las actividades principales que constituyen el desarrollo
del proyecto PSCA, clasificadas por nivel de detalle:

A continuacin, se completa el diagrama de Actividades del proyecto Sistema de

Control de Accesos a Edificios, desglosando cada uno de los paquetes en las tareas que
se han de llevar a cabo durante su estudio y desarrollo.
Actividad PSCA02
Actividad PSCA03.1

Actividad PSCA03.2
Actividad PSCA03.3

Actividad PSCA03.4
Actividad PSCA03.5

Actividad PSCA03.6
Actividad PSCA03.7

1.4. Descripcin detallada de las Actividades

En este punto del plan de gestin se proporciona una breve descripcin de los paquetes
de trabajo de primer y segundo nivel, segn corresponda, que constituyen el desarrollo
completo del presente proyecto.
PSCA01.1
REUNIN DE LANZAMIENTO
Primera reunin del proyecto entre el alumno y el director. Tiene como objetivo
determinar el alcance del proyecto inicial y las pautas que se van a seguir para el
desarrollo del mismo.
PSCA01.2
PLAN DE GESTIN DEL PROYECTO
Se corresponde con la elaboracin del Plan de Gestin del proyecto que se va a llevar a
cabo. Dicho plan supone una primera aproximacin a los objetivos y alcance del
proyecto, y proporciona los diferentes paquetes de trabajo que se han de estudiar y
analizar para afrontar el proceso de desarrollo del sistema que se quiere obtener.
PSCA02
GESTIN DEL PROYECTO
Paquete de trabajo que tiene como principal finalidad la de realizar un seguimiento

continuo del proceso de desarrollo, garantizando que se satisfacen los requisitos
establecidos y las restricciones impuestas.
Esta Actividad engloba tambin la elaboracin de la documentacin correspondiente a

cada una de las etapas que se vayan finalizando, y que en conjunto constituyen el
documento final.

PSCA03.1
INDETIFICACIN DE NECESIDADES
Tarea que se comporta como soporte a la peticin que el director del proyecto realiza
para determinar las pautas generales de las necesidades determinadas y del contexto del
sistema. La informacin recogida durante esta etapa se especifica en un Documento de
Conceptos del Sistema.
PSCA03.2
ANLISIS DE REQUISITOS
El objetivo de este paquete de trabajo es alcanzar un conocimiento suficiente del

sistema, definiendo las necesidades, los problemas y requisitos del usuario. Todo ello
debe ser expresado mediante dos modelos: de procesos y de datos.
Se obtiene un modelo de procesos fsico del sistema, y a partir de l se deduce el

modelo de procesos lgico el cual recoge las funciones esenciales del negocio
PSCA03.3
ESTUDIO DE LA ARQUITECTURA
El objetivo de esta Actividad es definir la solucin de arquitectura tcnica que satisface

tanto los requisitos como las restricciones del diseo. La arquitectura debe indicar qu
componentes software, hardware y de comunicaciones han de adquirirse o
desarrollarse.
La solucin deber dar una visin externa del sistema, los requisitos fsicos que se
tienen que tener en cuenta, as como los aspectos organizativos, operativos, tcnicos y
econmicos asociados.

PSCA03.4
DISEO EXTERNO
En esta etapa se completa la definicin de las especificaciones del sistema a mecanizar,

obtenindose el modelo fsico final de procesos y el modelo lgico de datos, de
acuerdo a la plataforma hardware y software definida en la tarea anterior.
Adems, esta Actividad elabora la estrategia que se ha de llevar a cabo en las etapas de
Pruebas e Implantacin, la formacin de los usuarios y las conversiones necesarias de
hardware y software del sistema actual al nuevo.
PSCA03.5
DISEO INTERNO
Esta tarea identifica y disea los diversos componentes software del sistema,
describiendo detalladamente sus caractersticas fsicas. Dependiendo de la arquitectura
escogida para el desarrollo, estos componentes pueden ser muy diversos. Debido a esta
heterogeneidad, el sistema se puede dividir en diversos subsistemas dependiendo de la
tipologa de los procesos, y as especificar y disear sus componentes.
PSCA03.6
PROGRAMACIN
El objetivo de este paquete de trabajo es alcanzar la transformacin del sistema en un

conjunto de programas que puedan ser ejecutados satisfactoriamente bajo unos criterios
de calidad. La dificultad se encuentra en cmo realizar la transformacin de la mejor
manera posible ya que depende en gran medida del lenguaje de programacin y de las
herramientas software disponibles.
10

PSCA03.7
PRUEBAS
Desarrollados y probados cada uno de los programas y componentes que constituyen el

software, deben realizarse una serie de pruebas para conseguir integrar todo el sistema,
de acuerdo al Plan de Pruebas establecido en la etapa de Diseo Interno.
El objetivo global de esta tarea es someter al sistema desarrollado y a sus componentes

a una serie de verificaciones encaminadas a garantizar un nivel de fiabilidad aceptable.
PSCA03.8
IMPLANTACIN
Despus de probar la integridad del software del sistema y especificada su instalacin y

configuracin, se debe instalar el software producido en el entorno de trabajo o Centro
de Produccin para llevar a cabo la explotacin del sistema final. De forma que su
objetivo es el de implementar el nuevo sistema en la produccin real.
PSCA04
CIERRE DEL PROYECTO
Esta actividad engloba tanto la reunin de aceptacin con el director y con el

coordinador del proyecto, como l elaboracin de una copia tanto de la documentacin
final como del software que se ha producido. A su vez, se debe proporcionar un
resumen de todo el proyecto que se almacenar en el sistema de documentacin de la
universidad.
11

1.5. Organigrama del equipo de trabajo

El equipo de trabajo del proyecto que se va a realizar, est formado por cuatro
participantes claramente diferenciados. Por un lado, se han definido las entidades del
director y del coordinador del proyecto, los cuales son las personas responsables de
controlar y verificar el correcto desarrollo del proyecto, siendo la figura del director
mucho ms importante debido a su mayor grado de implicacin en el mismo.
La figura del alumno se corresponde con la persona destinada a estudiar, disear y

desarrollar el proyecto propuesto por el director. Durante todo el proceso de desarrollo,
el alumno deber reunirse con el director, ya sea para las reuniones iniciales, como para
verificar todo el trabajo que se haya realizado hasta ese momento, relacin muy
diferente a la existente con el coordinador, ya que slo se realizarn dos o tres reuniones
a lo largo del ciclo de vida del proyecto.
Por ltimo, el alumno deber relacionarse con el usuario final de la aplicacin para
consolidar aspectos de diseo o mejoras del mismo, as como otros aspectos no
funcionales.
12

1.6. Funcionalidad de los integrantes del equipo de trabajo

En el siguiente punto se recoge la funcionalidad que desempea el perfil del
coordinador en el equipo de trabajo definido en el apartado anterior.
Director del Proyecto: DPFC

La labor del Director del proyecto consiste principalmente en conseguir que el alumno
desarrolle un PFC de calidad, ayudndole desde el punto de vista tcnico y funcional y
motivndole para que cumpla los plazos establecidos. El Director podr ser un Profesor
de la Escuela de Ingeniera o un ingeniero (o titulado superior) normalmente en
ejercicio de la profesin que haya mostrado inters por un proyecto determinado.
El Director es responsable de:
Proponer un proyecto con calidad suficiente y establecer los objetivos y el

alcance del mismo.
Facilitar al alumno las orientaciones adecuadas ante los problemas que puedan ir
surgiendo en el desarrollo del proyecto. Esto no implica que el director o tutor
del proyecto resuelva los problemas ya que se est examinando la capacidad del
alumno para hacerles frente.
Supervisar la realizacin del proyecto, la calidad de sus contenidos, y verificar

que se desarrolla de acuerdo con las normas establecidas, consultando con el
Coordinador de Proyectos las posibles dudas que le puedan surgir.
Dar su opinin sobre el alumno y el trabajo realizado rellenando el formulario

elaborado al efecto y entregndoselo al correspondiente Coordinador.
13

En general ningn director podr dirigir ms de 8 proyectos distintos en el mismo curso

acadmico, las excepciones a esta regla debern ser autorizadas por el Coordinador
General.
Coordinador del Proyecto: CPFC
Cada Coordinador ser responsable de la calificacin de los proyectos que coordina. A

principio de curso cada Coordinador deber pasar a su correspondiente Jefatura de
Estudios, informando al Coordinador General, la lista de los alumnos coordinados por
l, para que desde Jefatura se soliciten las correspondientes actas. Cada Coordinador
tendr asignada una hora semanal en el horario para realizar el seguimiento de los
alumnos y proyectos.
Las tareas asignadas a cada Coordinador son:
Buscar proyecto-director a los alumnos que no tengan ningn proyecto asignado.
Concretar la definicin del proyecto.
Recoger solicitudes de alumnos para cada proyecto.
Asignar a cada alumno su proyecto.
Presentar alumno/a al director del proyecto.
Controlar/supervisar el trabajo de cada alumno, con el director del proyecto (al

menos 2 veces por proyecto).
Comunicarse con el alumno para supervisar ritmo e incidencias (al menos 2

veces por proyecto).
14

Recoger y evaluar el proyecto finalizado, rechazando los que no alcancen un

determinado nivel o presenten defectos de forma. Finalizado el proyecto, el
alumno entregar al Coordinador un ejemplar visado por su director de proyecto,
junto con un resumen. (En las titulaciones de informtica, para el examen de
Revlida, el alumno llevar, junto con el material que considere necesario para
realizar la exposicin de su proyecto, otros DOS ejemplares de su Proyecto).
Calificar a los alumnos y firmar las actas, como profesor de esta asignatura. Una
vez calificado cada proyecto ser devuelto al alumno con el visado del
Coordinador y el alumno lo deber entregar junto con una copia del resumen en
Secretara General en el momento de realizar la matrcula de Revlida.
Alumno del Proyecto: APFC
El alumno ha de realizar las siguientes tareas propuestas y evaluadas por el Coordinador

de Proyectos:
El Coordinador de proyectos debe dar el visto bueno a cada proyecto, incluso

cuando sean proyectos propuestos por profesores u otros coordinadores de la
Escuela. Con el visto bueno del Coordinador el alumno puede comenzar su
proyecto oficialmente y debe proceder a realizar las tareas que le corresponden.
Todos los proyectos debern tener el visto bueno del correspondiente
Coordinador, a ms tardar en la ltima semana del mes de Octubre.
Cada alumno deber preparar de comn acuerdo con su director de proyecto un

documento que describa el Proyecto a realizar siguiendo el formato que se
adjunta en el Anexo B. La memoria descriptiva se entregar antes de hacer la
primera presentacin. El Coordinador fijar una fecha para la entrega de la
memoria, siendo en la ltima semana del mes de Noviembre la ms tarda.
15

El seguimiento del proyecto se realizar a travs de la clase semanal planificada.

Durante estas sesiones el alumno de acuerdo con la programacin establecida
por el coordinador deber presentar los objetivos, el plan de trabajo y los
avances realizados en su proyecto.
Durante el segundo y tercer trimestre del curso el alumno har dos exposiciones
pblicas de avance de su proyecto. En general, se realizarn una exposicin de
avance y otra a la finalizacin del trabajo.
El alumno debe asistir al menos al 50% de las clases de la asignatura.
1.7. Estimacin y Presupuesto

A partir de la jerarqua de Actividades diseada en el punto 1.3 se va a realizar un
estudio de la asignacin de recursos para el desarrollo del proyecto. Dicha asignacin
permitir estimar el presupuesto correspondiente al proceso de diseo del sistema final.
Estimacin de recursos
La estimacin realizada slo tiene en cuenta los paquetes de trabajo descritos en el

apartado 1.4 ya que permiten tener una perspectiva lo suficientemente detallada como
para poder estudiar la evolucin del proceso de desarrollo y asignar las horas/hombre
que se consideren necesarias para cada Actividad.
Antes de realizar la red Pert correspondiente a los niveles considerados de la EDT, se

lleva a cabo un estudio de la relacin temporal entre las Actividades. Dicha relacin
permitir entender la evolucin del progreso de desarrollo de los paquetes de trabajo, al
igual que la definicin de las duraciones de cada uno de ellos.
16

La relacin temporal muestra los requerimientos de inicio de una Actividad, en el

sentido de determinar qu Actividad ha de estar finalizada antes de comenzar el
desarrollo de la siguiente.
Los requisitos temporales existentes para llevar a cabo las Actividades que constituyen
el nivel 1 y 2 de la EDT son los siguientes:
Paquete de Trabajo
Actividad Predecesora
Duracin
PSCA01.1
No tiene
1 da (0033 meses)
PSCA01.2
PSCA01.1
5 das (02 meses)
PSCA02
PSCA01.2
270 das (9 meses)
PSCA03.1
PSCA01.2
15 das (05 meses)
PSCA03.2
PSCA03.1
15 das (05 meses)
PSCA03.3
PSCA03.2
30 das (1 mes)
PSCA03.4
PSCA03.3
15 das (05 meses)
PSCA03.5
PSCA03.4
30 das (1 mes)
PSCA03.6
PSCA03.5
75 das (25 meses)
PSCA03.7
PSCA03.6
15 das (05 meses)
PSCA03.8
PSCA03.7
15 das (05 meses)
PSCA04
PSCA02 , PSCA03.8
2 das (0067 meses)
Se ha considerado que cada semana tiene 7 das laborables, valorndose la duracin de

cada Actividad tanto en das como en meses.
Con el objetivo de realizar un estudio detallado de la asignacin de recursos, se ha

diseado primeramente la Red Pert correspondiente a la EDT del proyecto de gestin,
de forma que se pueda calcular cual es el camino crtico y los mrgenes de las
Actividades que presenten una cierta flexibilidad entre las fechas de inicio y fin del
proyecto.
17

La Red Pert a su vez permitir definir las fechas de inicio y finalizacin de cada uno de
los paquetes de trabajo, satisfaciendo la relacin temporal entre ellas y la fecha de
entrega del proyecto final.
La flexibilidad que presenten determinadas Actividades proporcionar la posibilidad de

cambiar su organizacin inicial de tal forma que se garantice un desarrollo del proyecto
uniforme desde el punto de vista de la asignacin de recursos, en este caso de las
horas/hombre que se han de dedicar en cada una de dichas Actividades.
La Red Pert correspondiente a este proyecto de gestin, valorando la duracin en das,

es la siguiente:
El camino crtico del proyecto lo constituyen las actividades de gestin: las dos
primeras etapas de inicio y elaboracin del Plan de Gestin, la propia Actividad de
Gestin global del proceso de desarrollo y la tarea de Cierre del Proyecto.
18

La asignacin del nmero de horas/hombre que se van a trabajar en cada uno de los
paquetes de trabajo es la que se adjunta en la siguiente tabla:
TOT
PSCA01.1
CPFC
DPFC
APFC
DPFC
APFC
20
20
PSCA01.2
CPFC
PSCA02
CPFC
DPFC
APFC
10
10
10
20
10
10
10
10
10
10
10
90
30
20
20
20
20
20
10
10
160
PSCA03.1
CPFC
DPFC
10
10
APFC
30
30
30
30
PSCA03.2
CPFC
DPFC
APFC
PSCA03.3
CPFC
DPFC
10
10
APFC
80
80
TOTAL
109
140
30
30
30
30
30
20
30
449
19

TOT
PSCA03.4
CPFC
DPFC
10
10
APFC
80
80
PSCA03.5
CPFC
DPFC
10
APFC
20
60
80
PSCA03.6
CPFC
DPFC
30
APFC
50
30
80
80
210
PSCA03.7
CPFC
DPFC
10
10
APFC
30
30
DPFC
10
10
APFC
30
30
PSCA03.8
CPFC
PSCA04
CPFC
25
25
DPFC
25
25
APFC
20
20
TOTAL1
109
140
30
30
30
30
30
20
30
449
TOTAL
109
140
146
95
110
110
110
100
100
1020
El nmero total de horas/hombre que se ha estimado dedicar en todo el proyecto es de

1020 horas, teniendo en cuenta el trabajo realizado por el director y por el coordinador
adems del que ha llevado a cabo el alumno.
20

Para tener una visin general de la evolucin de la dedicacin a lo largo del proyecto, se
han representado las horas/hombre que se han estimado trabajar por cada uno de los
meses que constituyen la duracin completa del proyecto:
Se puede observar que entre el primer mes y el tercero hay un incremento constante del
nmero de horas a trabajar debido a que se pretenden finalizar cinco etapas del
desarrollo ms la documentacin correspondiente de cada una de ellas.
Tras el primer trimestre se produce un descenso considerable de la dedicacin debido a

que se corresponde con el momento de preparacin de los exmenes de febrero y de
dedicacin para terminar las prcticas finales del primer periodo del curso.
La etapa final del proyecto, correspondiente a los ltimos cuatro meses, se caracteriza
por ser mucho ms uniforme el esfuerzo que hay que emplear para realizar las tres
ltimas etapas del desarrollo.
21

Calculadas las horas de trabajo a emplear, a continuacin se realiza el estudio del

presupuesto inicial que se asigna al proyecto.
Estudio del Presupuesto

El coste total del trabajo realizado por los integrantes del equipo de trabajo del proyecto
es el que se muestra en la siguiente tabla:
INTEGRANTE
HORAS/HOMBRE
/HORA
TOTAL
CPFC
37
60
2220
DPFC
210
60
12600
APFC
773
30
23190
TOTAL
38010
Por tanto, si consideramos el coste de los recursos software o hardware que se han
adquirido para realiza el proyecto adems del coste total del equipo de trabajo,
obtenemos el presupuesto inicial estimado para el desarrollo del proyecto:
Recurso
Subtotal Equipo de trabajo:
Total
38010
Lector Inteligente
200
Lector RFID
300
Tags RFID
50
Desplazamiento
300
Comunicaciones
200
Subtotal recursos:
1050
Total Final
39060
22

1.8. Planificacin de alto nivel

La planificacin que determina el desarrollo y evolucin del proyecto Sistema de
Control de Accesos, se muestra a continuacin:
23

2. Documento
de Conceptos
del Sistema
24

2.1. Objetivos del sistema

Se desea desarrollar un sistema, destinado al Instituto de Investigacin Tecnolgico
(IIT) de la Universidad Pontificia Comillas (UPCO), capaz de realizar dos tipos de
controles de seguridad: por un lado, un control de acceso del personal de dicho
departamento, de manera que facilite la gestin y el registro de las vistas que reciben
cada uno de los empleados, tanto de alumnos, como de personas ajenas a la
Universidad; y por otro lado, un control de inventario que permita llevar a cabo un
seguimiento de los ordenadores porttiles que proporciona el IIT a sus empleados, con
el objetivo de que stos puedan utilizarlos en lugares o contextos externos al dominio de
la universidad.
2.2. Alcance del sistema

El Sistema Control de Accesos a Edificios requiere la definicin de dos funciones de
negocio claramente diferenciadas entre s:
Control de Visitas
Se requiere de un Control de Visitas que permita consultar en cualquier momento el
listado de qu empleados se encuentran en el edificio, y a su vez, identificar a las
personas que solicitan ser atendidas por un miembro particular del departamento del
IIT.
Todas las visitas debern ser recogidas en la correspondiente base de datos, facilitando
el registro, adems de los alumnos que desean ser atendidos por un profesor de dicho
departamento, el de aquellas personas que no disponen de la identificacin de la
Universidad, y que por tanto, son ajenas a la misma.
El Sistema Control de Visitas deber proporcionar, si es posible, las ltimas visitas que
haya realizado en otros momentos la persona identificada, de forma que facilite la
gestin de la visita actual.
25

Control de Inventario
Paralelamente, se desea realizar un control de los ordenadores porttiles y de otro tipo
de recursos, como por ejemplo cmaras fotogrficas, que el IIT proporciona a sus
empleados para que stos puedan utilizarlos en mbitos externos a la Universidad.
Dicho control se realizar a partir de la gestin de las entradas y salidas del material
suministrado, as como de la identificacin y registro de las personas que deseen utilizar
o recoger dicho recurso.
Adems, el sistema de Control de Inventario debe estar integrado con un sistema de

reservas previamente existente: Reservas Online.
Recopilacin y carga de datos

El sistema debe tener acceso a las BBDD que recogen todos los datos sobre el personal
que trabaja en el departamento IIT, informacin referente a las visitas que han sido
registradas con anterioridad, as como de los recursos informticos que se encuentran
disponibles y la informacin de reservas para el Control de Inventario.
Cada visitante y personal del IIT quedarn perfectamente definidos mediante una serie
de datos personales que definen su perfil, de acuerdo al diseo de las tablas que
constituyen las BBDD creadas para la gestin deseada.
Del mismo modo, el control que se realizar sobre los ordenadores porttiles permitir
conocer en cada momento qu recurso est disponible o cundo ha de ser devuelto y por
quin, de manera que todos los movimientos sobre dicho material quede recogido en la
base de datos para conseguir un seguimiento eficiente de los mismos.
26

Acceso a la informacin
Su misin es, la de dotar al sistema de las herramientas necesarias para proporcionar las
diferentes funcionalidades que requiere el usuario final, el vigilante, a la hora de realizar
los controles de seguridad. El papel que desempea el usuario solo adopta especial
importancia cuando se realiza el control de acceso de los visitantes. El vigilante es la
persona encargada de introducir la tarjeta en el lector y de seleccionar el empleado del
departamento a visitar, y cuando se gestiona un movimiento asociado a un recurso que
implica la lectura del TAG RFID y su confirmacin para poder registrarlo en la
correspondiente base de datos para poder actualizar el estado del recurso.
Administracin y control del entorno

Tiene como objetivo la gestin de los datos y de los procesos tratados por el sistema.
Para ello, se contar con la figura de un administrador que se corresponde con el usuario
final, el cual es el responsable de llevar a cabo los controles de acceso a travs de la
ejecucin de las aplicaciones correspondientes y de la manipulacin de los lectores
utilizados para la lectura de las tarjetas de identificacin. Sin embargo, la informacin
almacenada que maneja el sistema no requiere de un control como tal ya que no puede
ser manipulada directamente por el usuario final ni por otra persona ajena a la
utilizacin del sistema. Es la propia aplicacin la que lleva a cabo las operaciones contra
las bases de datos correspondientes y porque stas residen en un servidor al que slo se
puede acceder, en principio, como administrador del mismo.
El perfil del usuario final se corresponde con una persona que trabaja en la universidad
Comillas, y que se encuentra en la recepcin del edificio, controlando las llegadas, tanto
de personas como de documentos.
La aplicacin residir en un PC restringido, al cual slo tienen acceso las personas cuyo
perfil se corresponda con el que se ha comentado anteriormente.
27

2.3. Tipologa de los usuarios finales

Los usuarios del sistema, sern exclusivamente las personas que trabajan en Comillas,
encargadas de controlar y gestionar los acontecimientos diarios que se produzcan en la
universidad, as como de afrontar y comunicar cualquier problema o incidencia que
tenga lugar.
En cada uno de los edificios que constituyen la universidad Comillas, se encuentran

varias personas que se corresponden con este perfil, y que gracias a ellas se puede llevar
a cabo una importante administracin y gestin de todo lo que ocurre en cada uno de los
edificios referenciados. Sin embargo, slo vamos a tener en cuenta el edificio donde se
encuentra el departamento del IIT, el cual es el destino del sistema que se va a
desarrollar, y por tanto, los usuarios de mismo, sern las personas que se adecuen al
perfil indicado que tengan que trabajar en el IIT.
2.4. Restricciones
El sistema que se ha de disear debe ser capaz de controlar dos tipos de accesos: el de
visitas y el de recursos prestables. Para ello, se ha decidido desarrollar dos aplicaciones,
bajo el lenguaje de programacin Java, que se encarguen de gestionar y registrar los
accesos que se realicen en un momento dado en cada uno de los dos contextos
determinados.
Ambas aplicaciones deben estar sincronizadas en tiempo real con el servidor de bases
de datos, de manera que sea coherente la informacin del personal que pertenece al
departamento con la almacenada en la base de datos, as como la referente al material
que se proporciona.
Para llevar a cabo el control de acceso de las visitas es necesario que el sistema este
conectado con un lector de tarjetas inteligentes del tipo LTCX, de forma que ser
necesario implantar las libreras y funciones adecuadas para que la aplicacin Java sea
capaz de realizar la lectura de las tarjetas, y manipular los datos ledos de las mismas.
28

Al mismo tiempo, la aplicacin deber proporcionar dos funciones adicionales:
Por un lado, la posibilidad de Introducir datos a mano, situacin que se

corresponde con la llegada de un visitante que no posee su tarjeta en el momento
de la gestin del acceso, o con una persona que no es un alumno de la
universidad. En este caso, el administrador deber introducir el nombre y los
apellidos del visitante por teclado, e indicar a que persona de la plantilla del IIT
viene a visitar. El registro de este tipo de visitas se realizar de la misma forma
que si se hubiese registrado con una tarjeta inteligente.
Opcin de Consulta. Se ofrece la posibilidad de generar un informes de

visitas a partir de un volcado de la base de datos a un archivo excel.
El control de inventario se realizar bajo la tecnologa RFID, de manera que se asignar

un tag RFID a cada uno de los recursos que constituyen el inmovilizado prestable que
proporciona el IIT.
Cuando una persona de dicho departamento desee llevarse un recurso, deber

identificarse, y si cumple las condiciones de autentificacin, se proceder a determinar
el tipo de movimiento que se va a. Si se confirma el prstamo o la devolucin, se
registrar la entrada o salida del recurso, segn corresponda, y se actualizar su estado
de disponibilidad.
Adicionalmente, se contempla la escritura en el TAG de incidencias que alteren la

utilizacin de un recurso, bien porque este daado fsicamente, o las condiciones con
que se realiza un prstamo del mismo.
Al mismo tiempo, se ha de tener en cuenta una restriccin de tipo econmico, ya que los
recursos del proyecto necesarios para implantar el sistema en el IIT estn financiados
por la universidad.
29

2.5. Antecedentes
El departamento del IIT dispone de un proyecto base que contempla la realizacin del
control de acceso del personal al edificio, de forma que se utilizar como punto de
partida para el diseo del Control de Visitas, con el objetivo de optimizar y refinar su
comportamiento.
Por otro lado, dicho departamento dispone de un lector de tarjetas situado a la entrada
del edificio, pero su funcionalidad se limita exclusivamente a la apertura de la puerta
principal tras introducir la tarjeta de empleado. Dicho control de acceso no permite
llevar a cabo un seguimiento de la presencia del personal en el edificio, ni de los
horarios que se cumplen cada da, de manera que no facilita la gestin de las visitas, y
mucho menos, el control de las personas que entran y salen del edificio.
30

3. Anlisis
de Requisitos
31

3.1. mbito del proyecto

Lectura de tarjetas inteligentes
El primer objetivo consiste en conseguir leer informacin de tarjetas inteligentes para
poder implantar una aplicacin de ayuda a los vigilantes de un edificio para realizar el
registro de las visitas (descrita ms adelante). Se trata de una aplicacin Java capaz de
leer tarjetas inteligentes, de manera que pueda manipular y almacenar los datos
recogidos de cada una de ellas.
Se utilizar un lector estndar de tarjetas inteligentes que se corresponden con las

tarjetas de identificacin que tiene la Universidad. Para alcanzar este objetivo se parte
del cdigo desarrollado en un proyecto fin de carrera del ao anterior.
Lectura de tarjetas RFID

Debido a la gran aceptacin que esta experimentando la tecnologa RFID, cada vez es
ms frecuente la utilizacin de lectores y tarjetas RFID para realizar diferentes tareas,
como por ejemplo la implantacin de los controles de acceso.
Las tarjetas RFID se consideran como una alternativa que sustituir el empleo de
cdigos de barras debido a las ventajas que proporciona la tecnologa RFID, destacando
entre ellas la mayor longitud de los cdigos de identificacin, los cuales permiten que a
cada etiqueta se le pueda asignar uno nico, mientras que los cdigos UPC actuales, se
limitan a un cdigo para identificar a todas la unidades de un producto en particular.
En este sentido los cdigos RFID equivalen ms al nmero de serie de un equipo que al
nmero de referencia del producto, pero un nmero de serie que sigue un formato
compatible entre todos los fabricantes.
32

El proyecto Sistema Control de Accesos contempla el diseo de una aplicacin, en

principio en Java, destinada a interactuar con tarjetas RFID, de manera que por un lado
se realice una lectura de las mismas para poder efectuar un seguimiento de los objetos
controlados, y por otro su escritura, permitiendo la asignacin de identificadores
unvocos, as como la introduccin de informacin descriptiva del objeto al cual va a
identificar.
Comunicar el sistema con las bases de datos

Se han de disear las bases de datos necesarias para realizar el almacenamiento de la
informacin recogida en las lecturas de las tarjetas de identificacin. As mismo, las
bases de datos complementarn la funcionalidad de la aplicaciones que se van a disear.
Para ello, se dispone de un servidor Solaris/MySQL donde residirn las bases de datos
que requiere el sistema. Debido a que cada aplicacin maneja un tipo de informacin,
ser necesario crear diferentes bases de datos, de manera que se pueda facilitar el
mantenimiento de las mismas, as como garantizar la coherencia de los datos
almacenados.
De la misma forma, se han de disear y crear las tablas que constituyen cada base de
datos, estudiando los campos que van a contener cada una de ellas, como las
restricciones respecto a los valores que pueden tomar, incluidos los valores por defecto,
para as conseguir la coherencia tanto en el diseo como en el significado de cada uno
de los registros recogidos.
Desarrollo de las aplicaciones de control de acceso

La primera parte del proyecto consiste en terminar de programar y poner en
funcionamiento una aplicacin base de control de acceso denominada Control de
Visitas.
33

Un prototipo de dicha aplicacin fue desarrollado en otro proyecto fin de carrera, sin
embargo requiere la incorporacin de nuevos servicios y la mejora de los ya existentes
para proporcionar de forma eficiente su funcionalidad, as como el perfeccionamiento
del diseo inicial para proporcionar un interfaz lo suficientemente explicativo e
intuitivo. La aplicacin se desarrollar bajo el lenguaje de programacin Java, y se
encargar de gestionar las visitas que recibe el personal del departamento de la
universidad IIT.
En el caso de visitas de alumnos, el registro de la visita requiere los datos personales del
alumno en particular, los cuales se consiguen mediante la lectura de la tarjeta de la
universidad, y los de la persona a la que viene a visitar. De esta forma, los registros de
visitas antiguos de un alumno en particular, permitirn agilizar el trmite de la nueva
visita que realice ya que lo ms probable es que solicite ver a las mismas personas que
en ocasiones anteriores.
En la segunda parte del proyecto, se ha optado por el diseo de una aplicacin que
permita obtener el mximo rendimiento de las diferentes ventajas que proporciona la
tecnologa RFID. Por ello, se contempla la realizacin de un Control de Inventario
destinado a llevar a cabo un seguimiento de los recursos que proporciona el
departamento, as como la gestin de los movimientos asociados que se produzcan.
Para ello, se asignar a cada uno de los recursos del departamento un TAG RFID, de
manera que cuando tenga lugar su entrada o salida se podr llevar a cabo su
identificacin y la gestin de su movimiento asociado. Cuando se confirme un
determinado movimiento se registrar en la bases de datos correspondiente, y se
actualizar el estado del recurso con el objetivo de conocer en todo momento su
disponibilidad. Los movimientos pueden ser de dos tipos: prstamos y devoluciones. El
tratamiento de los prstamos determina la necesidad de que esta aplicacin RFID se
integre con otro sistema destinado a realizar reservas de recursos con antelacin, de
manera que se gestionan tanto prstamos reservados con anterioridad como en un
momento dado.
34

3.2. Contexto general del sistema

El contexto general del sistema debe contemplar la interaccin del sistema con el
usuario, con otros sistemas mecanizados o manuales, o con las posibles bases de datos
existentes. El contexto general correspondiente al Sistema de Control de Accesos a
Edificios se recoge en el siguiente diagrama:
El sistema recibir la informacin de entrada a travs de los lectores que se encontrarn

conectados en la estacin de trabajo del usuario final, en este caso el bedel del
departamento del IIT.
Seguidamente, el sistema determinar la operacin a realizar, en funcin de los

parmetros de entrada, y si se requiere, solicitar al servidor los datos de gestin,
almacenados con anterioridad, que se proporcionarn como informacin de salida en el
punto de atencin. El sistema tambin interaccionar con el servidor donde residen las
BBDD, cuando tenga que realizar un registro, ya sea de una visita como del estado un
recurso, generando como flujo de salida la correcta finalizacin de la operacin o lo que
se considere ms conveniente.
35

3.3. Evaluacin y anlisis

Ante la descripcin del problema que se ha realizado en los apartados anteriores, el
siguiente punto que se ha de abordar es el de evaluar la informacin recogida y
sintetizarla para obtener el modelo de la situacin del sistema que se desea alcanzar.
Para ello, se han de estudiar tres aspectos claves:
3.3.1. Flujo de la informacin

En este apartado se definen las entradas y salidas del sistema. Como flujo de entrada, el
sistema recibir los datos correspondientes a las lecturas que se lleven a cabo a travs
tanto del lector de tarjetas inteligentes, como del lector RFID. Tambin, el sistema
recoger informacin del servidor de base de datos cuando deba mostrar datos
relevantes para continuar con la operacin del control de acceso, como por ejemplo
proporcionar los datos de toda la plantilla del IIT, o las descripciones y el estado actual
de cada uno de los recursos.
Como flujo de salida el sistema proporcionar un cdigo de retorno que informar sobre
el resultado de la operacin que se haya realizado. Slo se generar flujo de informacin
de salida como tal, cuando en Control de Inventario se almacenan cada uno de los
movimientos que se gestionan tras su confirmacin, o cuando se desea escribir en el
TAG RFID asociado una breve descripcin de algn aspecto que haya que recordar del
recurso en futuros prstamos, por ejemplo un deterioro fsico de alguno de sus
componentes, o si en un prstamo no se han llevado un elemento que forma parte del
recurso entregado, por ejemplo un perifrico como un ratn
3.3.2. Estructura de la informacin

Se entiende por estructura al contenido de los flujos de informacin, con el detalle
suficiente como para comprender la actuacin del proceso que transforma un flujo en
otro u otros.
36

Estructura de la Informacin de Control de Visitas
Los flujos de informacin que se generan durante un proceso de lectura son los
siguientes:
Nombre: FLUJO-ENTRADA-LECTOR
Identificador: PSCAFD.CV1
* CADENA: String de bits enviados por el lector cuando se introduce una tarjeta
inteligente en el mismo. A partir de dicha cadena de caracteres se determinan el cdigo
de identificacin, el nombre y los apellidos del alumno.
Nombre: FLUJO-LECTURA
Identificador: PSCAFD. CV 2
* ID-ALUMNO: Cdigo asignado a cada alumno cuando comienza sus estudios en

la Universidad UPCO.
* NOMBRE: Nombre del alumno identificado.
* APELLIDOS: Apellidos del alumno identificado.
37

Nombre: FLUJO-PERSONAL
ID-EMPLEADO: Identificador asignado a cada uno de los empleados del IIT.
NOMBRE: Nombre del empleado.
APELLIDOS: Apellidos del empleado.
EXTENSIN: Extensin telefnica del personal en cuestin.
PLANTA: Planta del edificio del departamento donde se encuentra el despacho
del empleado.
* PUESTO: Nmero de despacho del personal al que se hace referencia.
Nombre: FLUJO-VISITAS
ID-EMPLEADO: Identificador asignado a cada uno de los empleados del IIT.
38

Nombre: FLUJO-REGISTRO-VISITANTE
FECHA-ACTUAL: Fecha de registro de la visita realizada por ID-ALUMNO a
ID-EMPLEADO.
Estructura de la Informacin de Control de Inventario
Los flujos de informacin que se generan durante el proceso de gestin de los recursos
del departamento son los que se describen a continuacin:
Nombre: FLUJO-RFID
Identificador: PSCAFD.CI1
TRAMA: String de bits enviados por el lector al sistema cuando detecta,
identifica y lee una tarjeta RFID. La trama queda definida por el identificador RFID del
TAG y por el mensaje que se encuentra almacenado en uno de los bloques de la
memoria interna de la tarjeta identificada.
39

Nombre: FLUJO-RECURSO
ID-ITEM: Identificador asignado a cada uno de los recursos del departamento
disponibles para ser utilizados por cualquier empleado del mismo.
* CARACTERISTICAS: Descripcin explcita de los atributos ms relevantes que

definen el recurso.
* DISPOSICIN: Estado actual en que se encuentra el recurso, P prestable, o D

pendiente de devolucin.
* ID-RFID: Identificador de la tarjeta asignada de manera nica a cada uno de los

recursos que se van a gestionar.
Nombre: FLUJO-RESERVA
* ID: Identificador de la reserva.
* ID-ITEM: Identificador del recurso sobre el que se realiza la reserva.
40

Nombre: FLUJO-RESERVA (Cont)
* DESDE-DIA: Da para el cual est previsto realizar la entrega del recurso

reservado, es decir, da en que se lleva a cabo el prstamo.
* DESDE-HORA: Representa la hora del da DESDE-DIA en que el usuario

recoger el recurso.
* HASTA-DIA: Da para el cual est previsto realizar la devolucin del recurso que
se ha prestado.
* HASTA-HORA: Representa la hora del da HASTA-DIA en que el usuario

devolver el recurso.
* COM: Comentario que describe el motivo de la reserva.
* WHO: Identifica al empleado que realiza la reserva.
* DIA-RESERVA: Representa el da junto con la hora en que el usuario confirm la

reserva del recurso.
41

Nombre: FLUJO-EMPLEADO
* ID-EMPLEADO: Identificador asignado a cada una de las personas que trabajan

en el IIT.
* NOMBRE: Nombre del empleado.
* APELLIDOS: Apellidos del empleado.
Nombre: FLUJO-PRESTAMO
* ID-ITEM: Identificador del recurso sobre el que se esta realizando el prstamo.
* ID-EMPLEADO: Identificador de la persona que realiza el prstamo.
* ESTADO: Identifica el tipo de movimiento del prstamo, si es una entrega o una

devolucin de un recurso.
42

Nombre: FLUJO-INST
Flujo generado cuando una persona solicita un recurso no habiendo reservado con
anterioridad, de forma que se registra el prstamo en el momento que se realiza la
entrega.
3.3.3. Todas las funciones

Las funciones necesarias para llevar a cabo el Control de Visitas son las siguientes:
Configurar la comunicacin con el lector: Cuando se ejecute por primera vez la

aplicacin, se proceder a asignar un terminal de comunicacin con el lector a
partir de la asignacin de un slot particular del mismo.
Esperar lectura: La aplicacin ha de permanecer en espera activa hasta que se

introduzca una tarjeta en el lector para proceder a su identificacin.
Leer tarjetas: Cuando el usuario introduzca una tarjeta en el lector LTCX, ste
enviar una cadena de caracteres al sistema, el cual tendr que realizar la lectura
para obtener el identificador del alumno propietario de la tarjeta, as como su
nombre y apellidos.
43

Identificar personal ajeno a la universidad Comillas: Cuando se presente en el

departamento una persona que no dispone de carnet de alumno, se le asignar un
identificador especial, de forma que tras haber facilitado sus datos personales, se
pueda llevar a cabo el registro de la visita que desea realizar.
Consultar personal del departamento: Se proporcionan los datos de todas las

personas que forman parte del departamento del IIT de Comillas: nombre,
despacho y telfono.
Consultar visitas anteriores: Tras la identificacin del visitante, se proporcionan

las ltimas diez visitas que han sido registradas y protagonizadas por el mismo.
Esto permite obtener una lista de personal reducida que resulta muy til ya que
suelen repetirse las visitas de los alumnos a los mismos profesores.
Registrar visitante: Se almacena en la tabla LOG_VISITAS el identificador del

visitante junto con sus datos personales.
Registrar visita: Se realiza un registro de la visita en la tabla VISITANTES,

definida dicha visita por el identificador del visitante y del empleado, junto con
la fecha actual.
Proporcionar ayuda: En tiempo real, la aplicacin proporcionar una opcin de

ayuda sobre la funcionalidad de la misma.
Finalizar la aplicacin: se suministrarn dos formas de cerrar la aplicacin, bien

a travs de la opcin de ArchivoSalir, o pulsando sobre el icono de cierre de la
ventana de la misma.
44

Registrar visitas adicional: Opcin que se activar cuando, por motivos externos,
no se puede ejecutar la aplicacin, de manera que se pueda llevar a cabo el
seguimiento de las visitas que se vayan a realizar durante el tiempo que perdure
el problema.
Los diferentes servicios que definen detalladamente la funcionalidad y finalidad del

Control de Inventario son los siguientes:
Mostrar el estado actual de los recursos del departamento: Se proporciona para

cada uno de los recursos informacin sobre su disponibilidad para ser prestado,
o en caso contrario, para ser devuelto, indicando en este caso el usuario del
mismo.
Esperar el registro de un movimiento: La aplicacin deber permanecer en

espera hasta que se aproxime un TAG al lector cuando se desee gestionar un
movimiento de entrada o de salida del departamento.
Identificar un recurso: Cuando el lector RFID detecte un TAG le enviar a la

aplicacin el identificador del mismo, determinando sta el recurso al que se est
haciendo referencia.
Integrar la aplicacin con el sistema de Reservas Online para que Control de

Inventario pueda gestionar correctamente, con la informacin necesaria, aquellos
prstamos que hayan sido reservados con antelacin.
Proporcionar la informacin de las reservas asociadas a un recurso: Cuando un

recurso sea identificado se mostrar la reserva ms prxima al momento actual
del mismo, de forma que si el equipo est libre en ese momento, se podr
realizar una reserva instantnea teniendo en cuenta la fecha del prstamo de la
siguiente reserva ms cercana.
45

Registrar el prstamo de un recurso con reserva: La aplicacin permitir el

registro de una entrega tras mostrar la reserva asociada al recurso. En ese caso,
el usuario escoger la opcin de registrar el prstamo proporcionando toda la
informacin relativa al mismo, sin posibilidad de cambios, finalizando el
movimiento en el momento en que el usuario lo confirme.
Registrar el prstamo de un recurso sin reserva: Cuando un recurso est

disponible para ser prestado en un momento dado, se podr realizar la entrega
siempre que se respete la fecha del prstamo de la siguiente reserva, como se ha
comentado con anterioridad. Por ello, cuando el recurso sea identificado se
mostrar su reserva ms cercana, si existe, en cuyo caso se determinar la fecha
mas tarda de devolucin de dicho recurso a travs de una ventana de dilogo,
donde el usuario deber de confirmar adems otros campos que definen el
prstamo.
Registrar la devolucin de un recurso: El usuario de un recurso puede devolverlo

en la fecha acordada o antes. En el caso de que el recurso se devuelve con
antelacin, se debern actualizar los datos de la reserva para marcar el recurso
como libre y que puede ser reservado por otro usuario.
Recoger informacin adicional sobe el estado del prstamo: Se ofrece la

posibilidad de recoger informacin acerca de las condiciones en que se entrega
el recurso, por ejemplo sin ratn, sin maletnEsta informacin se registrar en
el TAG RFID de forma que cuando se devuelva el recurso se conozcan las
condiciones en que se llev a cabo la entrega.
Finalizar la aplicacin: La terminacin de la aplicacin requiere la intervencin

del usuario, de manera que se le ofrece la posibilidad de finalizarla cuando desee
o cuando lo considere necesario.
46

3.4. Modelo Fsico

3.4.1 Modelo Fsico de Control de Visitas
Contexto del subsistema
El sistema Control de Visitas se encuentra conectado con un lector de tarjetas

inteligentes, con el que se comunica inicialmente para realizar la configuracin del
lector, y a travs del cual recibe la informacin de la tarjeta leda en forma de una
cadena de caracteres. El usuario interacta con el sistema arrancando y cerrando la
aplicacin, as como confirmando el registro de las visitas. A su vez, el usuario es el
responsable de introducir la tarjeta en el lector.
47

Diagrama de Contexto
El Contexto del sistema se determina mediante un grfico de presentacin, donde

aparece el Sistema de Control de Visitas, el usuario y la entidad externa correspondiente
al lector de tarjetas inteligentes.
A continuacin se proporciona una descripcin de cada uno de los objetos presentes en

el diagrama anterior (diccionario de datos), de manera que facilite la comprensin del
contexto del sistema.
Diagrama de Contexto: PSCADFD0

Objeto: Entidad Lector LTCX
Identificador: PSCADFD0.E1
El lector de tarjetas inteligentes se comunicar con el sistema en dos situaciones

claramente diferenciadas: por un lado para el envo de informacin de configuracin, ya
sea para establecer el terminal como para apagarlo; y el segundo contexto es para la
transmisin de la informacin leda de las tarjetas
48


Objeto: Entidad Usuario
El usuario es el responsable de introducir la tarjeta de la persona que realiza la visita, y

de manipular la funcionalidad de la aplicacin de control, ya sea para iniciarla y
apagarla, como para confirmar el registro de una visita determinada.

Objeto: Orden SHUTDOWN
Identificador: PSCAO.1
Orden para apagar el lector, iniciada por el sistema cuando ste recibe la orden de EXIT
generada por la entidad USUARIO.

Objeto: Orden START
Orden para arrancar la aplicacin de Control de Visitas. Es generada por la entidad

USUARIO desde su puesto de trabajo.

Objeto: Orden EXIT
Orden para finalizar la aplicacin, iniciada por el usuario de la misma y no por motivos
de error durante el proceso de registro o de lectura.
49

Diagrama Conceptual de Nivel 1: PSCADFD1

Objeto: Orden FIN-LECTURA
Orden generada por el sistema cuando la entidad USUARIO quiere finalizar la

aplicacin (recepcin de un EXIT).

Objeto: Orden AVISO-LECTOR-NO-
ENCONTRADO
Orden que se enva al sistema cuando durante la configuracin no se detecta o reconoce
ningn lector de tipo LTCX, probablemente motivado por la falta de instalacin de los
drivers del mismo.

Objeto: Orden ERROR-LECTURA
La orden ERROR-LECTURA se genera cuando se produce un error de lectura, bien

porque no se puede leer la tarjeta debido a que se trata de otra tecnologa, o porque ha
fallado la comunicacin con el lector. Se informar al usuario de la existencia de este
error a travs de un mensaje por pantalla, de forma que sea l mismo quien se encargue
de finalizar la aplicacin.
50

Diagrama Conceptual de Nivel 1
El diagrama conceptual recoge los procesos de primer nivel que realizan la

funcionalidad descrita con anterioridad del Control de Visitas. En este caso, slo se ha
diseado un primer nivel debido a que los procesos no requieren explosionarse en otros
de mayor detalle.
La descripcin de cada uno de los elementos que constituyen el Diagrama Conceptual

se proporciona a continuacin:
Objeto: Proceso 1, Iniciar Servicio TI
Identificador: PSCAP.1
Procedimiento destinado a configurar la comunicacin con el lector LTCX. Dicha

configuracin consiste en determinar un terminal a partir de un slot del mismo, que se
mantendrn durante todo el tiempo de ejecucin de la aplicacin de control de acceso.
51

Objeto: Proceso 2, Esperar Lectura
Segundo estado de la ejecucin del control de acceso, en la que la aplicacin se

encuentra en espera activa de procesar una lectura y realizar su correspondiente registro
en la base de datos. En este estado de la ejecucin del control de acceso, el usuario
puede proceder a finalizar la aplicacin, bien porque lo desea, o porque se produjo un
error durante la lectura
Objeto: Proceso 3, Mostrar Informacin
Estado del control de acceso en que se proporciona la informacin sobre la

identificacin de la persona que realiza la visita, a quin ha visitado las ultimas veces
que se ha encontrado en el departamento, y todo el personal que constituye la plantilla
del IIT de la UPCO. Por ello, la primera vez que se accede a este estado es cuando se ha
realizado la lectura de la tarjeta, etapa de identificacin. El segundo y tercer acceso a
este estado tienen lugar tras proporcionar las visitas que ha realizado la persona
identificada en anteriores ocasiones, y todo el personal del departamento.
Objeto: Proceso 4, Consultar Visitante
Proporciona el personal del departamento que aparece en los registros de las ltimas
diez visitas que ha realizado la persona que se est atendiendo, y que se acaba de
identificar a travs de su tarjeta de alumno.
52

Objeto: Proceso 5, Consultar Personal
Proporciona informacin de toda la plantilla del personal del IIT, con el objetivo de que
el usuario, cuando lo necesite, seleccione la persona que se desea visitar.
Objeto: Proceso 6, Obtener Visita Actual
Etapa durante la fase de ejecucin en la que se configuran los datos que definen la visita
que se desea registrar. Cuando el usuario confirme los datos proporcionados a travs del
interfaz de la aplicacin, se proceder a realizar un registro del visitante y de la visita
asociada al mismo.
Objeto: Proceso 7, Apagar Lector
Finalizar la comunicacin con el lector LTCX, procediendo a su apagado.
3.4.2. Modelo Fsico de Control de Inventario

Contexto del subsistema
El Sistema Control de Inventario se encuentra ubicado en el ordenador del usuario final,

y conectado al lector RFID. La comunicacin entre ambos se caracteriza por no ser
constante, es decir, slo intercambian informacin entre s cuando se desea identificar
un recurso o cuando se escriben las condiciones del prstamo en el TAG RFID.
53

El usuario adems de arrancar y cerrar la aplicacin, es responsable de iniciar el registro

de los movimientos de recursos que tengan lugar. Dicho inicio se realiza con la
identificacin del recurso seguido de asignacin de la reserva correspondiente
determinando si se trata de una entrega o de una devolucin.
Si se va a efectuar una entrega o devolucin, segn corresponda, el usuario deber

indicrselo a aplicacin pulsando el botn que se haya habilitado para tal fin, siendo la
propia aplicacin quien se encargue de verificar las condiciones del prstamo y de
registrar el movimiento que se ha gestionado.
Diagrama de Contexto
El grfico de presentacin del Sistema Control de Inventario queda definido por el

propio sistema, junto con el usuario y el lector RFID.
54

Con el objetivo de facilitar la comprensin del contexto del sistema se realiza a

continuacin una breve descripcin de los objetos que intervienen en el Diagrama de
Contexto anterior, y que forman parte del diccionario de datos del sistema final.

Objeto: Entidad Lector RFID
El lector de RFID se encuentra conectado al sistema a travs de un cable USB. La

comunicacin entre ambos slo se establecer cuando el sistema permanezca en estado
de espera o cuando se desee registrar las condiciones del prstamo en el TAG RFID.
Cuando el sistema se encuentre en estado de espera, bien al inicio de la aplicacin o

porque se haya solicitado una nueva lectura, se enviar la orden de SOLICITUD, ms
concretamente de lectura, de manera que en un nivel ms bajo, el lector permanecer a
la espera de detectar un TAG, y proceder a su identificacin y lectura.
La SOLICITUD de escritura se enviar al lector cuando se hayan confirmado los datos

del movimiento a registrar, de forma que se mostrar un aviso al usuario para que
aproxime de nuevo el TAG sobre el lector y as llevar a cabo la escritura.
55


Objeto: Entidad Usuario
El usuario es el elemento del sistema que interacta constantemente con l. Es el

responsable de aproximar el TAG RFID al lector, de realizar la gestin del movimiento
definiendo los parmetros del mismo, y de confirmarlo para llevar a cabo su registro en
la base de datos correspondiente.

Objeto: Orden START
Orden para arrancar la aplicacin de Control de Inventario. Es generada por la entidad

USUARIO desde su puesto de trabajo.

Objeto: Orden EXIT
Orden para finalizar la aplicacin, iniciada por el usuario de la misma y no por motivos
de error durante el proceso de registro o de lectura.

Objeto: Orden SOLICITUD
Orden que permite al sistema comunicarse con el lector RFID, bien para realizar una
lectura, o para llevar a cabo una escritura de un TAG determinado.
56


Objeto: Orden SOLICITUD (cont) Identificador: PSCAO.3
Por ello, esta orden puede tomar dos valores:
LEER: Se solicita al lector que permanezca en estado de espera hasta que detecte
un TAG RFID. Tras identificar y leer los datos de la tarjeta, se los enva el
sistema constituyendo el flujo de datos TRAMA.
ESCRIBIR: El sistema enva esta orden cuando desee escribir en la memoria

interna de la tarjeta.

Objeto: Orden OPERACION
Orden generada por la entidad USUARIO para determinar el siguiente estado del
sistema. Esta orden tiene tres posibles valores:
REGISTRAR: Opcin elegida por el USUARIO cuando se desea gestionar la

entrega de un recurso previamente identificado de acuerdo a la reserva asociada
del mismo.
DEVOLVER: Se corresponde con la devolucin de un recurso, de manera que

cuando la aplicacin informe de dicho estado, se habilita la opcin
correspondiente para que confirme el movimiento, y as poder actualizar la base
de datos de acuerdo a la gestin realizada.
LEER: El USUARIO solicita una nueva lectura, de forma que el sistema cambia
al estado de espera para identificar un nuevo recurso
57

El Diagrama Conceptual correspondiente al Sistema Control de Inventario se define en

ms de un nivel debido a la complejidad del sistema. Dicha complejidad viene dada por
las diferentes operaciones que puede llevar a cabo el sistema, las cuales definen
paralelamente el estado del mismo.
La definicin del diagrama se determina en dos niveles, siendo el nivel 2 el

correspondiente a la explosin del proceso de Registrar Movimiento.
En el nivel de detalle 1 se puede observar el ciclo de vida de la gestin de un

determinado recurso. Dicho nivel se muestra a continuacin:
Las descripciones de los procesos de nivel 1 de detalle que completan el diccionario de

datos son las siguientes:
58

Objeto: Proceso 1, Mostrar estado actual
de los recursos
Cada vez que se inicia por primera vez la aplicacin, o se finaliza la gestin de un
movimiento, se muestra la disposicin actual de los recursos del departamento para ser
prestados. Si un recurso no se encuentra disponible, se indicar a su vez el nombre de la
persona que lo tiene en ese momento.
Estado lgico en el que se encuentra el sistema cuando no gestiona ningn movimiento.

Dicho estado permite atender una nueva peticin ya que se encuentra esperando la
lectura del TAG de un nuevo recurso.
Siempre que el sistema cambia a este estado le cede el control de la aplicacin al lector
RFID, responsable de detectar una nueva tarjeta, que tras su identificacin y lectura se la
transmite al sistema en forma de TRAMA, recuperando de nuevo el control de la
aplicacin.
Objeto: Proceso 3, Identificar Recurso
Despus que el lector haya realizado la correspondiente lectura del TAG detectado,
enva al sistema el identificador y los datos ledos del mismo. Cuando el sistema recibe
la TRAMA, lo primero que realiza es la identificacin del cdigo recibido. Si ste se
corresponde con alguno de los recursos del departamento se proceder a registrar el
movimiento en cuestin, pero si no se corresponde con ninguno el sistema solicitar una
nueva lectura cambiando de nuevo al estado de Esperar Lectura.
59

Objeto: Proceso 4, Mostrar reserva
asociada
Seguidamente a la identificacin del recurso, se determina el tipo de movimiento que se
va a gestionar, si entrega o devolucin de un recurso, y tras ello se proporciona la
reserva correspondiente ms prxima a la fecha actual.
Si el recurso est disponible, se mostrar la reserva ms cercana a la fecha actual,

considerando para ello la fecha de realizacin del prstamo.
Si el recurso no est disponible, se proporcionar la reserva asociada al prstamo que se

va a gestionar como devolucin del recurso.
Objeto: Proceso 5, Registrar movimiento
Realiza el registro en la base de datos del movimiento que se ha gestionado, de manera

que la informacin almacenada sea coherente con el estado actual de los recursos y de
sus correspondientes reservas.
El proceso 5, Registrar Movimiento, esta constituido por otros subprocesos que

permiten llevar a cabo su principal objetivo, de forma que presenta mayor complejidad
que el resto de procesos del primer nivel de detalle.
Por este motivo, se ha considerado necesario un nivel de detalle mayor, que permita
comprender la finalidad del mismo.
60

Las descripciones de cada uno de los procesos que constituyen el diagrama anterior y
que completan el diccionario de datos del diseo del sistema, se proporcionan a
continuacin:
Objeto: Proceso 1, Confirmar movimiento Identificador: PSCAP.5.1

Estado en el que se encuentra el sistema despus de mostrar la informacin de la reserva
asociada al correspondiente movimiento de un recurso en particular.
En este momento, el sistema se encuentra en espera de que el USUARIO indique si

desea registrar el movimiento o no, en cuyo caso confirmara que la reserva que se ha
mostrado corresponde con el tipo de movimiento que se est gestionando.
61

Objeto: Proceso 2, Registrar prstamo
Identificador: PSCAP.5.2
El movimiento se corresponde con la entrega de un prstamo, de forma que cuando el

USUARIO confirme que desea registrarlo se deber de mostrar una ventana de dilogo
con los datos necesarios que definen el prstamo.
Objeto: Proceso 3, Registrar prstamo
instantneo
El registro del prstamo se corresponde con la entrega de un recurso no reservada. Por
ello, la ventana de dilogo deber de mostrar la fecha de devolucin ms tarda respecto
de la fecha de realizacin del prximo prstamo, as como otros datos que permiten
definir la reserva. A su vez, se requiere que el usuario introduzca ciertos campos.
En el momento que el USUARIO confirme los datos, se insertar la reserva asociada al

prstamo y se actualizar toda la informacin correspondiente al estado de los recursos y
del movimiento que se acaba de gestionar.
Objeto: Proceso 4, Registrar prstamo con Identificador: PSCAP.5.4

reserva
El registro del prstamo a realizar tiene una reserva asociada. Cuando el USUARIO
confirme el movimiento se mostrar una ventana de dilogo que informa sobre los datos
de la reserva que se est llevando a cabo, sin proporcionar posibilidad a cambios.
Tras la confirmacin del USUARIO se registrar el movimiento en la base de datos,

actualizando el estado del recurso prestado.
62

Objeto: Proceso 5, Registrar devolucin
El movimiento a gestionar se corresponde con la devolucin de un recurso. La

aplicacin internamente verificar si dicha devolucin se realiza en el da acordado o se
corresponde con una fecha ms temprana a la registrada, en cuyo caso deber de
actualizarse la duracin de su reserva para permitir el prstamo del recurso a otra
persona a partir del momento en que se recoge la entrega en la base de datos del sistema.
Objeto: Proceso 6, Finalizar movimiento
Estado en el que se encuentra el sistema tras la gestin de un recurso. Se espera que el

USUARIO seleccione una nueva lectura, o en caso contrario, finalice la aplicacin
saliendo del sistema.
3.5. Modelo Lgico

El objetivo del modelo lgico es identificar las funciones o procesos y datos esenciales,
eliminando o sustituyendo lo considerado como no importante para el funcionamiento
del negocio, as como los aspectos fsicos, que aparecen en el modelo fsico.
3.5.1. Modelo Lgico de Control de Visitas

En el modelo fsico se han definido siete procesos, considerando los aspectos fsicos
como por ejemplo el encendido y apagado del lector, as como los errores de introducir
la tarjeta para proceder a la lectura de la misma. Tambin contempla de manera
independiente la obtencin de los dos flujos de informacin sobre el personal del
departamento, ya que por un lado se desea obtener los empleados visitados las ltimas
veces, y por otro lado, se proporcionan los datos de todos los empleados del IIT.
63

Como se ha comentado con anterioridad, el diseo del modelo lgico requiere la

seleccin de los procesos ms importantes, desde el punto de vista del funcionamiento
del negocio, y la eliminacin de los aspectos fsicos. Por ello, el modelo lgico
correspondiente al subsistema de Control de Visitas slo consta de dos procesos.
El proceso 1, Procesar Lectura, recoge como punto inicial importante para realizar el
control la lectura de una tarjeta, dejando a un lado cmo se realiza la lectura, si es
necesario realizar una configuracin de la comunicacin, o si se encuentra en espera
activa de lecturas.
El proceso Obtener Informacin Visita contempla la informacin que es necesaria

proporcionar al usuario para que pueda determinar los datos correspondientes a la visita
que se va a registrar.
En el modelo fsico se desglos en tres puntos claramente diferenciados, mientras que

en el modelo lgico se divide en dos: la identificacin del visitante procedente del
proceso 1, y el resto se proporciona en el segundo proceso ya que se considera como
homognea, en el sentido de que se requiere de un acceso a base de datos ya que se
encuentra registrada en el servidor, de forma que el tratamiento de la informacin es el
mismo.
A su vez, Obtener Informacin Visitas es responsable de recibir la confirmacin de la

visita tratada, y de registrarla en la correspondiente base de datos.
El diagrama que representa el Modelo Lgico de Control de Visitas, descrito con

anterioridad, se muestra a continuacin:
64

3.5.2. Modelo Lgico de Control de Inventario

El modelo lgico de un sistema no debe representar la forma (el cmo) en que ste
realiza los servicios que se ofrecen al usuario final. Por este motivo, se han definido los
procesos ms importantes del Modelo Fsico de Control de Inventario que permiten
representar qu hace el sistema, eliminando aquellos procesos que pertenecen ms al
mbito fsico.
El diagrama lgico final del Sistema de Control de Inventario consta de 5 procesos que
en conjunto explican el proceso de gestin de un movimiento de un determinado
recurso.
En primer lugar se ha de determinar el estado actual del inventario del departamento con
el objetivo de conocer qu recursos se encuentran en el edificio disponibles para ser
prestados y as poder llevar a cabo un control de los mismos.
65

Siempre que el sistema no este procesando una determinada tarea, se encontrar en un

estado de espera, el cual implica la comunicacin con el lector para solicitar la lectura
de un TAG RFID. Lgicamente, a pesar de que el lector opere en un nivel inferior al de
la aplicacin, tambin permanece esperando a realizar la lectura de una tarjeta. El
cambio de estado del sistema es motivado por la identificacin y lectura de un TAG,
informacin que enviar el lector RFID al sistema si todo el proceso se ha realizado
correctamente.
En el momento en que el sistema recibe el identificador de la tarjeta, la operatividad es

sistemtica: se identifica el recurso, se determina el tipo de movimiento y se obtiene la
reserva asociada al recurso, notificando el resultado de todas ellas al usuario.
El proceso de gestin finaliza cuando el usuario confirma el movimiento, hecho que

determina la actualizacin del estado del recurso que se ha prestado o devuelto, y el
correspondiente registro del movimiento. Tras ello, el sistema deber obtener de nuevo
el estado actual del inventario debido a que se ha producido un cambio en el mismo,
repitindose de nuevo todo el proceso anterior.
66

3.6. Modelo Conceptual de datos

La informacin de los flujos de datos, almacenes, registros, y atributos del modelo
lgico permiten identificar las entidades de datos del sistema. El modelo conceptual de
datos determina cules son las familias o entidades de datos del negocio, sus relaciones
y atributos ms importantes.
El modelo conceptual de datos debe ser independiente del hardware y del software
utilizado para el manejo de los datos, y de las aplicaciones actuales o futuras que
utilicen dichos datos. El modelo conceptual de datos puede tener un mayor o menos
grado de precisin, dependiendo de la etapa de estudio en que se encuentre el sistema a
representar.
3.6.1. Modelo Conceptual de datos de Control de Visitas

Modelo entidad-relacin
En el subsistema Control de Visitas se definen dos entidades sobre las que se almacena
informacin relevante, y a las que se puede identificar de manera unvoca: Visitante y
Empleado, cuya asociacin da lugar a la relacin Visita. Por lo que el modelo de
entidad-relacin correspondiente a Control de Visitas es el siguiente:
Un visitante puede realizar una o ms visitas a la misma persona del departamento, o a

otra diferente, dependiendo de los motivos por los que el visitante desea realizar dicha
visita.
Ambas entidades se clasifican como fsicas, ya que son entidades que se
corresponden con entes externos en la realidad.
67

ENTIDAD: VISITANTE
IDENTIFICADOR: PSCAMCD.CVE1
Descripcin:
Se identifica a la persona que desea reunirse con uno de los empleados que pertenecen al
departamento del IIT. Dicha persona puede pertenecer a la UPCO, o puede tratarse de
alguien ajeno al contexto de dicha universidad. En ambos casos, se realiza una
identificacin del mismo para definir la visita que se va a realizar, y as poder
registrarla.
Composicin:
ENTIDAD: EMPLEADO
IDENTIFICADOR: PSCAMCD.CVE2
Descripcin:
Se corresponde con cada una de las personas que trabajan en el IIT, y que constituyen la
plantilla de dicho departamento. Cada uno de los empleados pueden recibir visitas de
diferentes personas a lo largo del da.
Composicin:
68

RELACIN: VISITA
IDENTIFICADOR: PSCAMCDCV.R1
Descripcin:
Una visita queda representada a partir de las entidades de Visitante y Empleado, los
cuales son los objetos fsicos que llevan a cabo el encuentro. Para poder registrar una
visita, y que se caracterice de tener un significado coherente y entendible, debe estar
definida a partir de los identificadores de las dos personas que la constituyen, y de la
fecha actual en que se va a realizar.
Composicin:
Diseo de Tablas
Con el objetivo de garantizar que los datos estn organizados con la menor redundancia
posible y minimizando la probabilidad de anomalas en la actualizacin de los datos, se
han definido tres tablas:
USUARIOS: Recoge los datos de cada uno de los empleados del departamento.
VISITANTES: Alberga la informacin que define a cada persona que realiza

una visita.
LOG_VISITAS: Almacena todas las visitas que se registran en el departamento.
69

3.6.2. Modelo Conceptual de datos de Control de Inventario

Modelo entidad-relacin
El modelo entidad-relacin correspondiente al Sistema Control de Inventario est

formado por dos entidades: recurso y empleado, ya que responde a la situacin real de
que un empleado es el que utiliza un determinado recurso del departamento. A su vez,
se representan dos relaciones como resultado de la interaccin directa entre las dos
entidades.
La relacin Reserva surge de la necesidad que tiene un empleado de reservar un

recurso para un determinado da, una serie de horas o de das. Esta relacin permite
controlar los prstamos que se han de realizar a lo largo de cada jornada laboral.
Adems, es la responsable de contextualizar las condiciones del prstamo: duracin,
motivo
La segunda relacin, Prstamo, representa bsicamente el movimiento: un empleado

recibe o devuelve un determinado recurso. No existe ninguna relacin entre Reserva y
Prstamo ya que un recurso se puede prestar si estar reservado.
70

A continuacin se realiza una descripcin del conjunto de objetos que constituyen el

modelo conceptual de datos, y que completan el diccionario de datos del diseo del
sistema.
ENTIDAD: EMPLEADO
IDENTIFICADOR: PSCAMCDCI.E1
Descripcin:
Se corresponde con cada una de las personas que trabajan en el IIT, y que constituyen la
plantilla de dicho departamento. Cada uno de los empleados pueden recibir visitas de
diferentes personas a lo largo del da.
Composicin:
ENTIDAD: RECURSO
IDENTIFICADOR: PSCAMCDCI.E2
Descripcin:
Representa a cada uno de lo bienes materiales que constituyen el inventario que el

departamento del IIT deja a disposicin de sus empleados.
Composicin:
71

RELACIN: RESERVA
IDENTIFICADOR: PSCAMCDCI.R1
Descripcin:
Una reserva se define a partir de la necesidad que tiene un empleado de utilizar un

determinado recurso. Por este motivo, le reserva permite conocer qu movimientos se
van a realizar a lo largo de cada da, adems de gestionar adecuadamente cada prstamo
o devolucin, garantizando la coherencia con la realidad.
Composicin:
RELACIN: PRSTAMO
IDENTIFICADOR: PSCAMCDCI.R2
Descripcin:
Un prstamo representa el tipo de movimiento que se gestiona: bien la entrega de un

recurso, o una devolucin. Esta relacin permitir llevar a cabo un control de los
movimientos que realmente se realicen cada da.
Composicin:
72

Diseo de Tablas
La base de datos contra la cual el Sistema Control de Inventario va a realizar las

operaciones necesarias para llevar a cabo la gestin de inventario, est constituida por
tres tablas:
ITEMS: Recoge todos los recursos que forman el inventario del departamento.
RESERVAS: Almacena las reservas de los recursos que se han prestado, o se

van a entregar en un futuro.
Prstamos: Registra todos los movimientos que se llevan a cabo sobre un

determinado recurso.
73

4. Estudio de la
Arquitectura
74

4.1. Especificacin de la tecnologa hardware

Los principales requisitos hardware del Sistema de Control de Accesos son dos lectores
de tarjetas de reconocimiento: uno de tarjetas inteligentes y otro de radiofrecuencia. En
este punto se realiza un estudio de cada una de las tecnologas, as como de las
caractersticas de cada uno de los lectores.
4.1.1. Tarjetas Inteligentes
4.1.1.1. ISO 7816
La Organizacin Internacional de estndares (ISO) dictamina en su estndar nmero

7816 toda la informacin de regulacin y control de normas acerca de las Tarjetas
Inteligentes de contacto.
El estndar ISO7816 est dividido en cuatro apartados diferentes:
1. ISO7816-1: Caractersticas fsicas del circuito integrado.
En este apartado se estudian las caractersticas fsicas de las tarjetas inteligentes de

contacto. A continuacin, se describen las ms importantes:
Luz Ultra Violeta: Cualquier proteccin contra cualquier nivel de rayos UV, ser
responsabilidad del fabricante de la tarjeta.
Rayos X: La exposicin de cualquiera de los dos lados de la tarjeta a una dosis

de 0.1 Gy relativo a una radiacin de energa media de rayos X de 70 a 140 KV
(dosis acumulativa por ao) no deber causar mal funcionamiento de la tarjeta.
75

Perfil de la superficie de los contactos: La diferencia de los niveles entre los

contactos y la superficie de la tarjeta adyacente deber ser menor de 0.1mm.
Fuerza Mecnica: La tarjeta deber resistir daos sobre su superficie, por presin
causada por una bola de acero de 1.5mm de dimetro en la cul se aplica una
fuerza de 1.5 N.
Resistencia elctrica: Toda la resistencia elctrica medida entre dos puntos

cualquiera de los pines, no deber sobrepasar los 0.5 Ohm, con cualquier valor
comn de 50 uA a 300 mA.
Campo magntico: El chip de la tarjeta no deber ser daada por campos de

esttica magntica de 79500 A.tr/m.
Electricidad esttica: El chip de la tarjeta no deber ser daado por descargas

elctricas de 1500 V y de 100 pF y tendr 1500 Ohms.
Tambin se contemplan aspectos como la inflexin mxima de la tarjeta o los distintos

tamaos permitidos:
Inflexin mxima de la tarjeta:
Largo de la tarjeta
Deformacin (f): 2 cm
Periodicidad: 30 Inflexiones por minuto
Ancho de la tarjeta
Deformacin (f): 1 cm.

Periodicidad: 30 Inflexiones por minuto
76

Tamaos:
2. ISO7816-2 define las dimensiones y la posicin de los contactos.
Esta parte define el nmero, funcin y posicin de los contactos elctricos. El circuito
integrado (ICC) tiene 8 contactos elctricos.
A continuacin se adjunta una tabla que contiene la definicin de los 8 contactos acorde
con la ISO 7816-2:
77

3. ISO7816-3 define las seales elctricas y los protocolos de transmisin.
Como protocolos de transmisin se contemplan hasta 16, pero slo se utilizan dos:
T=0: Protocolo asncrono orientado a carcter. Es el ms usado (por ejemplo

GSM), aunque se requieren dos transacciones para recibir datos.
T=1: Protocolo asncrono orientado a bloque de datos. En este caso solo se

requiere de una transaccin para recibir datos.
4. ISO7816-4 define comandos de intercambio industriales.
En este documento de la ISO se definen:
Sistema de ficheros y estructura de datos.
Arquitectura de seguridad.
Lista de instrucciones especficas y/o adicionales de la ISO.
Lenguaje de comunicacin con la tarjeta JavaCard, PCSC10 ...
78

4.1.1.2. Tipos de Tarjetas Inteligentes
Existen diversos tipos de Tarjetas Inteligentes, todas ellas pueden clasificarse bajo dos
criterios. El primero es el tipo de circuito integrado que lleva en su interior y la forma de
procesar la informacin. El segundo es el tipo de contacto que tiene la tarjeta para
entrada y salida.
1. Clasificacin por el tipo de circuito integrado
En lo referente al tipo de circuito integrado, las Tarjetas Inteligentes se clasifican en tres

tipos, dependiendo de sus capacidades de procesamiento y de la lgica con que
modifican internamente los datos que pueden almacenar, aunque se podran dividir en
slo dos grupos: tarjetas de memoria, que son el modelo ms simple y ms econmico
de implementar y, tarjetas que contienen en su interior una Unidad Central de
Procesamiento o CPU.
Tarjetas de memoria
Este tipo de tarjetas son las ms comunes de hallar en aplicaciones comerciales como
tarjetas de prepago. Solo pueden almacenar datos y no cuentan con la capacidad de
modificarlos, por ello son el modelo ms simple y ms econmico de implementar.
Un ejemplo de uso de estas tarjetas son las tarjetas de cabinas telefnicas, estas vienen
con un importe grabado de fbrica y al realizar la llamada, la cabina va disminuyendo el
importe por cada minuto de uso.
Tarjetas de memoria con lgica de seguridad
Son similares a las tarjetas de memoria pero con la capacidad de controlar el acceso a
los datos. Emplean memorias EEPROM para implementar esta funcionalidad.
79

Tarjetas con procesador y memoria
Este tipo de tarjetas tienen un chip microprocesador que puede contener un microcdigo
que define una estructura de comando, una estructura de archivos y una estructura de
seguridad. Estas tarjetas pueden aadir, borrar y, de alguna manera, manipular
informacin en su memoria. Pueden ser vistas como un computador en miniatura con un
puerto de entrada/salida, sistema operativo y disco duro.
2. Clasificacin por el tipo de contacto
Existen fundamentalmente dos tipos de tarjetas en funcin de cmo se realice la

comunicacin entre el lector y la tarjeta, tarjetas de contacto y tarjetas sin contacto,
aunque tambin se pueden encontrar tarjetas hbridas que pueden comunicarse de las
dos formas, por contacto y sin l.
Tarjetas con contacto
Estas tarjetas necesitan ser insertadas en un lector inteligente para que por medio de
contactos elctricos pueda ser leda. En la primera imagen puede observarse los 8
contactos con los que est formada una Tarjeta Inteligente definidos en la ISO 7816-2.
80

Tarjetas sin contacto
Son similares a las de contacto con respecto a lo que pueden hacer y a sus funciones
pero utilizan diferentes protocolos de transmisin en la capa lgica y fsica. La
comunicacin entre el lector y la tarjeta se realiza a travs de seales electromagnticas
sin necesidad de ningn tipo de contacto.
Una de las ventajas que presenta este tipo de tarjetas es que no existen contactos
externos, por lo que es ms resistente a los elementos externos como la suciedad, y se
con el uso.
Una Tarjeta Inteligente sin contacto requiere solamente aproximarse al lector. Ambos,
el lector y la tarjeta tienen una antena y la comunicacin se establece por ondas de
radio. Muchas tarjetas sin contacto tambin obtienen la energa para su microchip
interno a travs del campo electromagntico creado por el lector.
Este tipo de tarjetas se estudiarn con ms detalla en el punto correspondiente a la

Tecnologa RFID.
Tarjetas hbridas
Como una categora derivada estn las tarjetas que envuelven las dos categoras que
emplean contacto y las que no. Una tarjeta hbrida tiene dos microchips, cada uno con
su respectiva interfaz para contacto y transmisin por radio.
Los dos chips no estn conectados, pero para muchas aplicaciones, este hbrido suple las
necesidades de los usuarios y los distribuidores. De esta manera est emergiendo este
tipo de tarjeta que une en su interior los dos tipos de interfaces en los contactos de
lectores, aumentando as las posibles funcionalidades que pueda tener una sola tarjeta.
81

4.1.1.3. Sistema de Ficheros
El sistema de ficheros de las Tarjetas Inteligentes est definido, como ya se ha indicado

en un apartado anterior, en la ISO 7816-4. Todas las tarjetas deben soportar los
siguientes tipos de ficheros:
Fichero Maestro (MF): Este fichero representa la raz de toda la estructura

interna de ficheros (EF) contenidos en la memoria de la tarjeta, as como
contener ficheros dedicados (DF). Solo puede haber un fichero maestro por
tarjeta y su ruta siempre debe ser la misma segn la normativa ISO, la
0x3F00.
Fichero Dedicado (DF): Estos ficheros podramos considerarlos como

directorios similares a una estructura tipo UNIX, por lo que puede contener
ficheros elementales (EF), as como otros ficheros dedicados. Por lo general se
encuentra un fichero dedicado por cada aplicacin diferente que se encuentre en
la tarjeta.
Fichero Elemental (EF): En estos ficheros se almacenan los datos. Una de las
limitaciones mas molestas es que su tamao debe ser fijado cuando este es
creado, por lo que un estudio previo de la estructura de ficheros es esencial.
4.1.1.4. Mtodos de Acceso a la Tarjeta Inteligente
Las libreras de OpenCard permiten la comunicacin, por medio de un lector, entre una
Tarjeta Inteligente y una aplicacin Java. Estas libreras nos ofrecen dos mtodos para
acceder a la tarjeta, uno de ellos nos permite interactuar con la tarjeta en un bajo nivel
por medio de paquetes de comunicaciones llamados Application Protocol Data Units
Unidades de datos segn el protocolo de la aplicacin (APDU), y el otro mtodo es ms
abstracto ya que se realiza por medio de unas clases de Java.
82

Este ltimo conjunto de clases(CardTerminal, CardFile, etc) permite interactuar con

el lector a partir de la utilizacin de los mtodos que las constituyen proporcionndole
los parmetros necesarios para obtener la informacin de la tarjeta leda. Para poder
utilizar este forma de comunicacin hay que asegurarse de que la Tarjeta Inteligente que
se va a utilizar soporta este acceso. Para llevar a la prctica el Control de Visitas se
utilizar el primer mtodo, debido a que la tarjeta de Comillas no soporta el segundo
mtodo de acceso.
Application Protocol Data Units
Estos paquetes tienen una estructura claramente definida y se dividen en dos tipos como
se puede observar en la siguiente tabla:
El campo CLA presente en los paquetes de solicitud, se corresponde con un byte que se
utiliza para indicar la clase de instruccin, por ejemplo si esta es conforme a la ISO
7816 es una instruccin en propiedad. Tambin sirve para indicar si se est utilizando
privacidad a la hora de enviar el mensaje.
83

El valor correspondiente a INS, de un byte indica el comando a emplear:
Los bytes P1 y P2 indican parmetros especficos del comando, y su presencia en el

comando es obligatoria.
El campo LC indica la longitud del comando, del tamao de un byte. Tambin puede
espesar en bytes la longitud del campo de datos opcional.
La referencia de Datos Opcionales se utilizara para recoger el texto que se desea

insertar en la tarjeta cuando el comando a ejecutar es el de escritura.
El ltimo campo que aparecen en las solicitudes es el de LE que indica en bytes la

cantidad de datos esperados a recibir en el APDU de respuesta. Si no se sabe la cantidad
de datos o simplemente queremos obtener todo lo posible, se indicar con un cero.
En las APDU de respuesta aparecen siempre dos campos, SW1 y SW2, que recogen la
informacin de estado, y adicionalmente un campo opcional.
Tanto en los APDU de comando como en las de respuesta, los parmetros que se enven
siempre se encontrarn expresados en cantidades basadas en el sistema hexadecimal.
84

4.1.1.5. Lector de tarjetas inteligentes: LTCX

Aspectos tcnicos y funcionamiento
Para llevar a cabo el Control de Visitas es necesario un lector de tarjetas inteligentes,

que permita identificar a cada una de las personas que se acercan al centro. Adems
debe ser compatible con las tarjetas de alumno que reparte la universidad.
El lector LTCX USB se conecta al ordenador mediante puerto USB y

est preparado para cumplir con el estndar USB CCID, de manera
que el lector no requiere de software aadido (drivers) en sistemas
operativos Linux, Mac OS y Windows, que ya contemplan este estndar en sus
distribuciones.
Otra caracterstica relevante es que se garantiza la compatibilidad y funcionalidad futura

del lector, ya que su tecnologa permitir actualizaciones de forma remota. Es
importante sealar que esta actualizacin del lector se ha desarrollado teniendo
especialmente en cuenta el futuro uso del DNI electrnico, optimizndolo para ello.
Tambin se encuentra disponible en versin serie (RS232).
Las caractersticas tcnicas del lector son las siguientes:
Dispositivo lector y grabador de tarjeta chip conectado al ordenador.
Instalacin en modo Plug and Play para el sistema operativo Windows.
Diseo de reducidas dimensiones y de poco peso, que facilita su portabilidad y

ubicacin.
Base plana para su posible sujecin a otros dispositivos externos, como por
ejemplo el teclado, el ordenador, etc.
85

Carcasa de PVC ligero y resistente a golpes.
Diseado especialmente para su utilizacin en entornos de certificacin con

firma digital.
Provisto de una CPU CMOS de 8 bits.
Consta de dos LEDS sealizadotes: uno verde y otro rojo.
Alimentacin 5V DC del propio ordenador.
Soporta velocidades de comunicacin entre 9600bps y 115200bps
Tarjetas soportadas
Soporta las tarjetas ms utilizadas actualmente en el mercado:
Tarjetas asncronas protocolo T=0 (GSM, VisaCash, Euro6000, Tarjeta

Criptogrfica, etc.)
Tarjetas asncronas protocolo T=1 (German Geldkarte)
Tarjetas de memoria del tipo SLE4442 (referencia C3P2K)
Cualquier otro tipo de tarjeta bajo demanda.
4.1.2. Tecnologa RFID

Para realizar un seguimiento de los recursos prestables que proporciona el departamento
del IIT de Comillas a todos sus empleados, se ha elegido la tecnologa RFID.
86

Un sistema RFID consiste en un tag RFID incorporado en cada objeto que se desea
controlar, por ejemplo un ordenador porttil, y en un aparato lector fijo o porttil que lee
dichos TAGS. Estos componentes utilizan ondas de radio frecuencia para intercambiar
informacin, lecturas o escrituras. Una vez ledo el TAG, los datos puede transmitirse
por las redes estndares a las base de datos, o pueden requerirse para notificar a un
controlador programable para que ejecute alguna accin, como por ejemplo registrar la
entrada o salida de un recurso del edificio donde se encuentra instalado el sistema.
Bsicamente un SISTEMA RFID los constituyen los siguientes elementos:
Uno o ms Tags (transponder) que incluye un chip semiconductor y una antena.
Uno o ms dispositivos de Lectura/escritura (interrogadores o lectores).
Dos a ms antenas, una en el tag y otra en el dispositivo de Lectura/Escritura
Un software de Aplicacin y una estacin de trabajo (Host).
Para poder llevar a cabo la transmisin de datos entre la tarjeta y el lector RFID se
deben encontrar prximos y trabajar en el mismo rango de frecuencia.
87

4.1.2.1. Funcionamiento
Todo sistema RFID se compone de un interrogador o sistema de base que es

responsable de leer y escribir datos en los dispositivos, y un transmisor que responde al
interrogador.
Existen dos tipos de TAGs: los TAGs activos que incorporan una batera para su
alimentacin (por ejemplo el control de autopistas), y los pasivos, que se alimentan por
el campo magntico que induce el propio lector.
El proceso de lectura de TAGs pasivos es el siguiente:
1. El interrogador genera un campo de radiofrecuencia, normalmente

conmutando una bobina a alta frecuencia. Las frecuencias usuales van desde 125 KHz
hasta la banda ISM de 2.4GHz, incluso ms.
2.
El campo de radiofrecuencia genera una corriente elctrica sobre la bobina
de recepcin del dispositivo. Esta seal es rectificada y de esta manera se alimenta el

circuito.
3. Cuando la alimentacin llega a ser suficiente el circuito transmite sus datos.
88

4. El interrogador detecta los datos transmitidos por la tarjeta como una

perturbacin del propio nivel de la seal.
La seal recibida por el interrogador desde la tarjeta est a un nivel de -60 db por debajo
de la portadora de transmisin. El rango de lectura para la mayora de los casos est
entre los 30 y 60 centmetros de distancia entre interrogador y tarjeta.
Las variables crticas en un sistema RFID son las siguientes: el rango de frecuencia de
la comunicacin, el tamao de la informacin contenida en el tarjeta, la velocidad a la
que se establece la comunicacin con el TAG, la forma fsica del TAG, la capacidad del
sistema para comunicarse simultneamente con mltiples TAGS, y la robustez de la
comunicacin respecto a las posibles interferencias existentes entre el lector y la tarjeta.
Los factores a tener en cuenta para implantar la tecnologa RFID consideran los niveles
legales y regulados de emisin permitida en el pas de uso, si se incluye o no una batera
en el propio TAG para mejorar su comunicacin con el lector, y la frecuencia de
portadora de RF utilizada para transportar la informacin entre el TAG y el lector.
4.1.2.2. Protocolos y opciones

Normalmente el sistema de modulacin utilizado es modulacin de amplitud (AM) con
codificacin tipo Manchester NRZ. Para conseguir mayor alcance y ms inmunidad al
ruido elctrico, se utilizan sistemas ms sofisticados: en algunos casos se divide la
frecuencia del reloj de recepcin.
La mayor parte de los TAGS tienen una memoria EEPROM donde se almacenan datos.
En algunos casos llevan datos grabados de fbrica y en otros tambin hay datos que
puede grabar el usuario. Cada vez es ms habitual, implantar sistemas que utilizan
encriptacin de clave pblica para conseguir mayor seguridad ante posibles escuchas
maliciosas.
89

Por otro lado podemos encontrar sistemas anticolisin que permiten leer varias tarjetas
al mismo tiempo. En caso de que varias tarjetas estn en el rango de alcance del
interrogador y empiecen a transmitir al mismo tiempo, se produce una colisin.
El interrogador detecta la colisin y manda parar la transmisin de las tarjetas durante

un tiempo. Despus irn respondiendo cada una por separado despus de un tiempo de
espera aleatorio.
4.1.2.3. Etiquetas RFID: TAGS

Las etiquetas RFID se clasifican en tres tipos, desde el punto de vista de si poseen una
fuente de alimentacin o no:
Pasivas: Caracterizadas por no tener fuente de alimentacin propia. La mnima corriente

elctrica, inducida en la antena por la seal de escaneo de radiofrecuencia, proporciona
suficiente energa al circuito integrado CMOS de la etiqueta para poder transmitir una
respuesta. Debido a las limitaciones de energa, la respuesta de una etiqueta pasiva
RFID es necesariamente breve, normalmente apenas un nmero de identificacin. La
falta de una fuente de alimentacin propia hace que el dispositivo pueda ser bastante
pequeo. Las etiquetas pasivas, en la prctica tienen distancias de lectura que varan
entre unos 10 milmetros hasta cerca de 6 metros dependiendo del tamao de la antena
del tag, y de la potencia y frecuencia en la que opera el lector. Por ejemplo etiquetas de
productos de consumo.
Semi-pasivas: Similares a las pasivas, salvo que incorporan adems una pequea
batera. Esta batera permite al circuito integrado de la etiqueta estar constantemente
alimentado. Adems, elimina la necesidad de disear una antena para recoger potencia
de una seal entrante. Por ello, las antenas pueden ser optimizadas para la seal de
backscattering. Las etiquetas RFID semi-pasivas responden ms rpidamente dado que
su razn de lectura es mayor que las con las etiquetas pasivas.
90

Activas: Tienen una fuente de energa, lo que le permite alcanzar rangos mayores,
albergar memorias ms grandes que las etiquetas pasivas, e incrementar la capacidad de
poder almacenar informacin adicional enviada por el transmisor-receptor. Muchas
etiquetas activas tienen rangos prcticos de diez metros, y una duracin de batera de
hasta varios aos. Por ejemplo los TAGs de las autopistas.
Por otro lado, las etiquetas RFID tambin se clasifican segn su rango de frecuencia:
Las etiquetas de frecuencia baja: entre 125 134,2 kilohertz.
las etiquetas de alta frecuencia: 13,56 megahertz.
las etiquetas UHF o frecuencia ultraelevada: 868 a 956 megahertz. Estas

etiquetas no pueden ser utilizadas de manera global porque no existe una
regulacin estndar para su utilizacin.
Las etiquetas de microondas (2,45 gigahertz). Las etiquetas de microondas

tampoco pueden ser utilizadas de forma global porque no existen regulaciones
globales para su uso.
Las etiquetas pueden ser de lectura solamente, lectura y escritura, o combinaciones de

ambas, donde algunos datos son permanentes, como por ejemplo el nmero de serie de
la tarjeta, y por otro lado se cuenta con una memoria adicional, que est disponible para
otros datos que pueden ser aadidos o actualizados en otras ocasiones.
Lectura de las Etiquetas
Los lectores de RFID o interrogadores, utilizan ondas de radio para leer la

informacin almacenada en la etiqueta. El lector puede ordenar a la etiqueta transmitir
la informacin que tiene almacenada, o bien la etiqueta puede transmitir la informacin
que contiene de manera peridica.
91

Los lectores pueden ser porttiles o fijos, aunque tambin pueden estar integrados en
otros equipos, como por ejemplo en terminales handheld. Con el objetivo de mantener
cierta privacidad, la informacin que fluye entre la etiqueta y el lector puede estar
encriptada.
El lector de RFID, a su vez transmite los datos obtenidos desde la etiqueta a un

ordenador, donde se ejecuta la aplicacin que utilizar los datos del tag identificado,
para llevar a cabo las funciones del sistema implantado dicha aplicacin recibe el
nombre de Object Name Service (ONS)
4.1.2.4. Estndar Mifare

Los TAGS RFID que se utilizarn en el Control de Inventario son tarjetas inteligentes
Mifare, las cuales contienen en su interior un chip Mifare desarrollado por Philips, de
manera que tienen una estructura especfica de almacenamiento.
Una tarjeta que cumple con el estndar MIFARE est conformada por 16 sectores,
donde cada sector posee 4 bloques de 16 bytes.
El bloque cero del sector cero es de slo lectura, donde se almacena la informacin del
nmero serial de la tarjeta o Card ID, datos del fabricante e informacin de control. Los
bloques finales de cada sector (3, 7, 11,..,63) almacenan los datos de configuracin de
cada sector.
92

Estos datos de configuracin incluyen las claves de acceso A y B como tambin las
condiciones de acceso al sector. Este bloque recibe el nombre de Sector Trailer.
A continuacin se presenta un esquema de la distribucin de la memoria de las tarjetas

inteligentes que cumplen con el estndar MIFARE:
4.1.3. Plataforma donde reside el sistema

El Sistema Control de Accesos a Edificios residir en un ordenador ubicado en la
entrada del edificio del departamento del IIT, lugar donde el usuario de las aplicaciones
podr llevar a cabo los controles correspondientes para cada una de las aplicaciones que
constituyen el sistema. Consistir en una plataforma PC, a la cual se conectarn el lector
de tarjetas inteligentes, y el lector RFID, a travs de dos puertos USB.
4.2. Especificacin de la tecnologa software y de comunicaciones

El software necesario para que las aplicaciones se puedan ejecutar en la mquina del
usuario final es el siguiente:
Los drivers de cada uno de los lectores, que se encontrarn en una ubicacin
especfica en dicho ordenador.
La mquina virtual de Java, JVM, elemento necesario para que se pueda llevar
a la prctica cualquier programa Java.
93

Las comunicaciones necesarias para implantar el Sistema Control de Accesos son

bsicamente las de acceso al Servidor de BBDD que se encuentra localizado en el
4.3. Arquitectura final del sistema
La arquitectura del sistema est formada por cinco niveles claramente diferenciados
entre s, a travs de los cuales se transmite tanto el flujo de entrada como el de salida,
generado durante el proceso de control en el Control de Inventario. A continuacin, se
procede a describir cada uno de los niveles:
Tarjetas: Constituye la entrada de datos en el sistema, actividad indispensable

para la etapa de identificacin de cada uno de los dos controles que se realizan.
En el caso RFID, las tarjetas tambin son destino de informacin, ya que cuando
se registra algn movimiento de un recurso se escribe en el TAG
correspondiente un texto de observaciones.
94

Lectores: Son los dispositivos que se comunican con las tarjetas de

identificacin, y son responsables de retransmitir la informacin leda en cada
lectura al sistema, para que ste ltimo la procese.
Middleware: Nivel intermedio destinado a traducir la informacin que recibe de

los dispositivos, y a retransmitir la conversin de dicha informacin a la
aplicacin de nivel superior en el protocolo correspondiente para poder llevar a
cabo el procesado de la misma. En el Control de Inventario el fichero .C es el
que desempea el perfil de estado intermedio, ya que por un lado se comunica
con el lector RFID, y por otro con la aplicacin Java, manteniendo de esta forma
la independencia entre los niveles. Sin embargo, en el Control de Visitas no hay
un middleware tan diferenciado debido a que la aplicacin s que tiene medios
(el API) para comunicarse con el lector de tarjetas inteligentes directamente.
Sistema: Representa las dos aplicaciones de controles de acceso que reciben,

procesan y generan flujo de datos, registrndolos, si procede, en el servidor de
BBDD.
BBDD: ltimo nivel de la arquitectura, que se corresponde con el repositorio de

datos del sistema.
4.4. Evaluacin Econmica

La viabilidad econmica considera tanto la inversin en el proyecto, como el gasto que
supone. Un estudio detallado del factor econmico se realiza en base al llamado
Anlisis de Coste/Beneficio. En l se recogen los costes del proyecto y se comparan con
los beneficios que proporcionar el sistema. Dichos beneficios pueden ser tangibles,
aquellos que se valoran directamente y por tanto se pueden cuantificar; e intangibles,
caracterizados porque no se pueden valorar de forma precisa y son el resultado de
juicios objetivos.
95

Con los costes y beneficios cuantificados se define la rentabilidad del proyecto mediante
consideraciones de amortizacin: tiempo requerido para recuperar el dinero invertido en
el proyecto. Sin embargo, debido a las caractersticas particulares del presente proyecto
como proyecto fin de carrera, no corresponde la realizacin de este aspecto al no existir
inversin alguna. Aun as, se proporcionar el estudio de amortizacin que le
correspondera como proyecto real.
Todos estos clculos requieren un conocimiento sobre el valor actual del dinero, su
tendencia en el futuro, y otros aspectos monetarios que influyen en un anlisis de este
tipo. Por este motivo, el Anlisis de Coste/Beneficio resulta laborioso de realizar debido
a los criterios variables que se han de aplicar, por las caractersticas del sistema que se
est diseando, el tamao y complejidad del proyecto, y la recuperacin esperada de la
inversin (ROI). Sin embargo, desde el punto de vista del estudio de diferentes
alternativas, para determinar qu solucin supone ms coste para el proyecto, es
suficiente con tener en cuenta slo los beneficios tangibles. Dichos beneficios son:
1. Costes de implantacin.
Costes de desarrollo: Incluye al personal necesario para el desarrollo del nuevo

sistema. Se requiere de analistas, consultores, programadores y desarrolladores,
que en este caso, todos ellos son responsabilidad del alumno que est realizando
el proyecto fin de carrera.
Costes de puesta en marcha: supone el paso a produccin, una vez desarrollado

el sistema. Particularizando en este proyecto, no se cuenta con este coste si
consideramos como mtrica los euros, pero si el estudio se realiza en
horas/hombre, entonces s supone un gasto, ya que requiere en primer lugar las
reuniones necesarias con el director. En segundo lugar, la estancia en el
departamento del alumno para instalar tanto los lectores como el sistema en el
ordenador del usuario final.
96

Tras la instalacin, se llevan a cabo las pruebas pertinentes para confirmar y

garantizar el correcto funcionamiento de las aplicaciones.
Costes de formacin: Ensear a todos los usuarios finales del sistema a utilizar
el nuevo sistema. En el proyecto que se esta desarrollando no ser necesario que
el usuario final asista a cursos de formacin para la utilizacin de las
herramientas finales: se le ensear personalmente la metodologa de cmo
manejar el sistema.
2. Costes de adquisicin de tecnologa.
Coste del hardware: Coste del equipo para el nuevo sistema, considerando los
costes de instalacin y mobiliario. Por ello, en este coste se debe tener en cuenta
la adquisicin de los lectores y de las tarjetas RFID.
Coste del software: Licencias de productos ya desarrollados y comerciales,

necesarios para el desarrollo del proyecto como hojas de clculo, bases de datos,
sistemas operativos, cambios de versin de herramientasEn el proyecto se han
utilizado herramientas, como por ejemplo los compiladores, que no han supuesto
ser un coste para llevar a cabo el desarrollo correspondiente. Como se ha
comentado con anterioridad, los drivers se catalogan como software, y como tal,
se debe considerar el gasto correspondiente de los mismos. Sin embargo, dicho
gasto es nulo, ya que los lectores vienen acompaados por sus correspondientes
drivers.
Coste de las comunicaciones: Instalacin de redes locales, unidades de control

de transmisin o equipos de comunicacin a adquirir. Como se ha comentado en
el apartado anterior, el Sistema Control de Accesos no requiere de una red de
comunicaciones para efectuar los controles de acceso: slo necesita comunicarse
con el servidor de base de datos para gestionar correctamente los flujos de datos
de entrada y de salida que se generarn en cada uno de los controles
97

3. Costes operacionales.
Este apartado recoge los costes del centro de proceso de datos y los costes de
mantenimiento y mejora. Como coste del centro de proceso de datos son los costes fijos
de explotacin del nuevo sistema, considerando tanto a las personas como los recursos
materiales.
Por ello, los costes operacionales importantes que influyen en el nuevo sistema son
poco relevantes, ya que por coste fijo podemos considerar la energa que requiere el
funcionamiento del sistema, y el posible mantenimiento que se tenga que realizar en un
futuro, gasto que se considerar en el momento que se tenga que llevar a cabo alguna
actividad que permita mejorar o resolver un determinado problema que impide
proporcionar el correcto servicio del sistema.
La Matriz de Evaluacin de Costes recoge, por Grupos o por Factores, cada uno de los
costes estimables o cuantificables que se han descrito con anterioridad. En esta matriz se
anotan los costes reales o esperados de cada parmetro, obtenindose como suma de
cada uno de ellos, el valor del coste total de la solucin tecnolgica que se ha elegido.
Cuando no pueden barajarse datos numricos ms o menos fiables, no cabe la

posibilidad de establecer la viabilidad econmica del proyecto, pero s se puede realizar
una estimacin aproximada de lo que supone la alternativa, facilitando la posibilidad de
compararla con el resto de soluciones en el caso de que se haya estudiado ms de una.
En muchas ocasiones, en lugar de valorar numricamente cada uno de los factores, se
les asigna un valor simblico: ++ para indicar un coste alto, + un coste aceptable, - un
coste bajo, y un coste poco apreciable. El resultado mostrar un conjunto de signos +
y por cada una de las soluciones, permitiendo compararlas de manera individual.
La Matriz de Evaluacin de Costes correspondiente al proyecto que se est diseando es

la siguiente :
98

Alternativa
(euros)
Costes de Implantacin
Costes de Desarrollo
38010
Costes de puesta en marcha
1000
Costes de Formacin
20
Costes de Tecnologa
Costes del Hardware
550
Costes del Software
Costes de Comunicaciones
Costes Operacionales
Costes del C.P.D
Costes de Mantenimiento y
mejora
Costes Totales
0
0
39580
4.5. Elaboracin del Plan de Proyecto

Definida ya la tecnologa hardware, software y de comunicaciones que se ha elegido
utilizar, se procede a realizar la planificacin general del resto de etapas: Diseo
Externo, Diseo Interno, Programacin, Pruebas e Implantacin.
Con la informacin y conocimiento que se tiene del proyecto en este momento, resulta
ms segura y fiable una planificacin detallada de cada una de las etapas que quedan
por realizar. Por tanto, debe actualizarse la planificacin general realizada al comienzo
del proyecto, y adecuarla a las condiciones actuales establecidas por la solucin a
desarrollar. An as pueden producirse cambios sustanciales a lo largo del desarrollo de
una etapa. Por este motivo, el proceso de planificacin es una tarea cclica y permanente
durante el desarrollo del proyecto. A continuacin, se muestran el ciclo de planificacin
del proyecto:
99

Como se ha comentado con anterioridad, el Plan de Proyecto en este punto del

desarrollo debe recoger el resto de etapas que quedan por realizar, determinando de
manera especfica el objetivo de cada una de ellas, considerando al mismo tiempo sus
duraciones para garantizar que la finalizacin del proyecto se encuentra dentro del plazo
previsto.
La revisin del Plan que se realizar a posteriori al terminar cada una de las etapas
consistir en comprobar que se satisfacen los requerimientos funcionales del sistema,
as como los que estn relacionados con el tiempo, ya que si no se cumplen con las
expectativas determinadas para cada etapa se deber reestructurar la planificacin.
La metodologa de desarrollo que se est siguiendo es lineal aunque evidentemente la

revisin del plan definido sea cclica debido a las verificaciones que se han de llevar a
cabo del mismo. Ya definido el ciclo de desarrollo y las actividades a realizar, se
procede a determinar la secuencia de ejecucin de tales actividades, y la duracin de
cada una. A continuacin se muestra el plan de actividades:
100

La secuenciacin de las actividades es lineal, de forma que no se admiten alteraciones

en la planificacin en las mismas ya que determinan un camino crtico en el proceso de
desarrollo que se ha de realizar a partir de este momento. La finalizacin de las cuatro
actividades en conjunto se llevara a cabo el da 151, considerando como da de inicio el
comienzo de la etapa de Diseo Externo. Adems, se ha de tener en cuenta la actividad
de Gestin del Proyecto definida en el Plan de Gestin del apartado 1, ya que se su
realizacin es constante a lo largo de todo el desarrollo del proyecto. La duracin de las
actividades en este punto se ha estimado en semanas, ya que permite estimar con ms
facilidad el trabajo que queda por realizar as como el tiempo existente para llevarlo a
cabo con el objetivo de satisfacer la planificacin inicial.
Para completar el plan, se deben tener en cuenta los recursos que se van a utilizar as
como el esfuerzo que se espera dedicar en cada una de las etapas. Dicha informacin se
encuentra recogida en la tabla de asignacin de recursos que se estim en el comienzo
del proyecto en el Plan de Gestin del mismo.
101

5. Diseo
Externo
102

A partir de la plataforma tecnolgica elegida en el Estudio de la Arquitectura, en esta

fase se completarn los requisitos fsicos del sistema final, se disearn las entradas y
salidas, se completar la especificacin de los procesos del modelo, y se elaborar el
modelo lgico de datos, a partir de los volmenes manejados por el sistema. Con el
objetivo de completar la definicin del modelo fsico, se le dota de procesos de control,
de seguridad y auditabilidad, necesarios para una instalacin mecanizada.
Y como el conocimiento del nuevo sistema aumentar considerablemente en esta etapa,

se podr definir la estrategia a seguir en los planes de formacin al usuario, la
conversin de los datos, las pruebas del sistema e implantacin, como parte del ciclo
vida a recorrer.
5.1. Requisitos fsicos del nuevo sistema

A partir de las necesidades hard/soft definidas en la etapa anterior para la solucin
elegida, se debe completar detalladamente la plataforma hardware y software para la
puesta en marcha del sistema. Estos requisitos fsicos se expresan bajo los conceptos de:
entorno operativo del sistema y configuracin hardware/software.
5.1.1. Entorno Operativo del Sistema

Se especifican aspectos clave del diseo del sistema, como los descritos a continuacin.
Entrada, salida y recogida de datos
En este punto se establecen los diferentes tipos de entradas y salidas de datos, con el
objetivo de poder disear interfaces con otras aplicaciones o sistemas que dialogan con
ste. Adems se debe especificar cmo van a llevarse a cabo las respectivas tomas de
datos para la entrada al sistema: quines van a realizarlas, con qu seguridad se va a
contar, qu informacin se va a introducir.
103

Si acudimos al modelo lgico de procesos obtenido en la etapa de Anlisis de

Requisitos, podemos extraer las entradas y salidas del sistema a partir de los flujos de
datos que figuran en el Diagrama de Contexto. Estos flujos comunican entidades
externas con el sistema.
Los flujos de interfaz que el sistema en conjunto tiene con otras entidades se representan
en los respectivos diagramas de contexto de los dos controles de acceso:
Control de Visitas
104

Mantenimiento de Ficheros
Los ficheros maestros del sistema que representan el cdigo de la aplicacin residirn
en el ordenador del usuario, en un directorio especfico para ello, donde el usuario no
tenga acceso, u otra persona, o no se corresponda con los contextos habituales de trabajo
de dicho usuario. De esta forma, en cierto modo se garantiza de la mejor manera
posible, la seguridad y mantenimiento de los ficheros de arranque de los controles de
acceso.
Por otro lado, las bases de datos residirn en el servidor del departamento, responsable
de albergar todos los registros de control que se efecten cada da. No se ha pensado en
llevar a cabo un plan de mantenimiento de las BBDD debido a su simplicidad y a que
no suponen un consumo considerable de la capacidad del servidor.
Generacin de Informes
En este apartado se definen los informes o avisos por pantalla que el sistema producir
en determinadas situaciones. Dichos informes se catalogan como mensajes por pantalla
que se imprimirn ante situaciones consideradas relevantes para encaminar
adecuadamente la ejecucin del programa, y como listados, generados a partir de las
visitas registradas (fichero Excel de las visitas de los tres ltimos das). Los mensajes de
informacin que se proporcionarn en ambos controles de acceso se clasifican de la
siguiente manera:
Error:
stos a su vez, pueden ser tecnolgicos, cuando hay un fallo en la comunicacin con el
lector, bien porque no se encuentre conectado correctamente, o bien porque la
transmisin no se ha completado adecuadamente. Tambin pueden ser errores de
aplicacin, cuando el registro de un flujo de datos, ya sea de una visita o de un
movimiento de entrada y salida de un recurso, no se ha completado.
105

Tambin se consideran avisos de este tipo los fallos derivados de las lecturas de la base
de datos cuando es necesario mostrar informacin del estado actual de los recursos del
departamento, o de las reservas y visitas registradas con anterioridad.
Confirmacin:
Avisos informativos del correcto registro de la visita o del movimiento de inventario, ya

sea de entrada como de salida.
Control de informacin y de seguridad del sistema
La ejecucin de las aplicaciones de los diferentes controles de acceso es responsabilidad

del usuario final, trabajador interino de la universidad Comillas. Dicha ejecucin no est
sujeta a ningn control de seguridad, sin embargo s esta respaldada por la
autentificacin inicial cuando el usuario arranca el ordenador por primera vez, ya que
para encenderlo debe de introducir su contrasea como usuario del sistema general de la
universidad.
Por otro lado, el acceso al servidor de base de datos del departamento se realiza bajo un
usuario y una contrasea, para poder realizar la conexin con el mismo.
La transmisin de los datos entre los lectores y el sistema no est cifrada ni sometida a
ningn control de seguridad, excepto cuando se escribe en un TAG RFID. Dicha
escritura se realiza bajo un algoritmo simple de codificacin de la informacin textual
(de caracteres), cuando se quiere recoger el nombre y el primer apellido del responsable
del recurso, y no caracteres numricos, como es el caso del identificador de dicha
persona.
Adems, el acceso a una tarjeta RFID requiere la utilizacin de una clave determinada
para poder acceder a la informacin que almacena en sus bloques, de forma que supone
un punto de seguridad adicional del sistema.
106

Rendimiento del sistema y escalabilidad
Con el fin de conseguir que el sistema alcance los objetivos marcados, se debe de medir
el flujo de datos que se manejar de manera que se pueda determinar el tiempo mximo
de respuesta. En este caso, el tiempo mximo queda definido por el acceso a la base de
datos que corresponda, ya que la comunicacin con los lectores constituye una mnima
parte del tiempo total que supone un control de acceso. A su vez, el sistema se
caracteriza por carecer de una plataforma pesada de comunicaciones, de manera que el
tiempo de respuesta slo depender de los accesos a la base de datos. El tiempo de
ejecucin queda definido por las lecturas a la base de datos, ms el tiempo de gestin
del control de acceso, ms el acceso al servidor para registrar la visita o el movimiento
de reserva o devolucin.
La arquitectura que presenta el Sistema Control de Accesos a edificios es fcilmente

portable, ya que se puede migrar a otro entorno de desarrollo instalando simplemente
los drivers de los lectores y los archivos de codificacin sobre los que est programado.
Por otro lado, la expandibilidad del sistema es posible, instalando varios lectores
conectados entre s a partir de una red local que permita la comunicacin entre todos
ellos, y tambin con el servidor de base de datos. A su vez, se puede ampliar la
funcionalidad del sistema proporcionando ms servicios que los que se exponen en el
proyecto actual.
Condiciones de operacin
El horario operativo de explotacin del sistema se realizar durante la jornada laboral de

los empleados del departamento del IIT, es decir, durante todo el tiempo que el
departamento se encuentre abierto tanto para el personal del edificio como para las
personas ajenas al mismo. Los controles de acceso se llevarn a cabo en cualquier
momento que se corresponda con los contextos ya descritos con anterioridad: una nueva
visita, o un prstamo/devolucin de un recurso.
107

La carga de trabajo del sistema es aleatoria, aunque no elevada, ya que depende de la

afluencia de movimientos que se tengan que gestionar. Dicha carga de trabajo es
constante en cada registro, ya que en todo momento se trabaja con los mismos flujos de
informacin, siendo el mayor de todos el que se refiere a las inserciones de los mismos
en las diferentes tablas de la base de datos.
Forma de implantacin
El sistema residir en el ordenador personal del usuario final, que se encuentra

conectado con la red local del departamento, y por tanto de la propia universidad. Dicho
ordenador est ubicado en la entrada del IIT, lugar estratgico desde donde se
gestionarn todas las visitas, prstamos y devoluciones de recursos.
La implantacin del sistema es sencilla. En primer lugar se deben instalar los drivers de
cada uno de los dos lectores en el ordenador donde se va a ubicar el sistema (para ello
los lectores debern estar conectados). Seguidamente se copiarn los ficheros de cdigo
que constituyen las aplicaciones de los controles de acceso en un directorio especfico
para ello.
Se ha optado por proporcionar dos ejecutables que permitan arrancar las aplicaciones de
Control de Visitas y Control de Inventario directamente, de manera que se configure
automticamente el entorno de ejecucin y su inicio. Dichos ejecutables se ubicarn en
el entorno de trabajo del usuario final (Vase Anexo 3).
5.1.2 Configuracin hardware/software

De acuerdo con la solucin elegida en el Estudio de la Arquitectura se completa la
especificacin de los elementos hardware y software que van a constituir la plataforma
del sistema.
108

La especificacin se plantea mediante un grfico para la configuracin hardware y otro

para la configuracin software. En el primero de ellos se recogen los elementos bsicos
que van a formar la plataforma y sus interconexiones de comunicacin. En el segundo,
se representan los ficheros maestros, las bases de datos y productos software que estarn
soportados bajo la plataforma hardware
Grfico de Configuracin hardware
Grfico de Configuracin software
109

ESPECIFICACIONES HARDWARE DEL SISTEMA

Servidor de Base de Datos
8 CPUs
8GB RAM
250GB HD
Lector de tarjetas inteligentes
CPU CMOS de 8 bits
Alimentacin 5V DC del propio ordenador.
Soporta velocidades de comunicacin entre 9600bps y 115200bps
Puerto USB/Serial
Lector RFID
Antena Incluida.
Frecuencia de Operacin 125KHz.
Conector USB.
Led de operacin y led de lectura incorporado.
Lectura de tarjetas a una distancia entre 5 y 9 cm.
Alimentacin requerida: 5V/80 mA.
PC Usuario
512MB de RAM
Procesador 2,5MHz
100GB de HD
Puertos serie y USB
110

ESPECIFICACIONES SOFTWARE DEL SISTEMA
Servidor de Base de Datos
Sistema Operativo Solaris
Gestor de Base de Datos Relacional
SQL
Adaptador TCP/IP
PC Usuario
Windows XP
Driver lector tarjetas inteligentes
Driver RFID
Java Virtual Machina
Navegador
Fichero de cdigo fuente
Drivers ODBC
5.2. Desarrollo del Modelo Fsico Nuevo

Durante la etapa de Anlisis de Requisitos se han diseado los modelos fsicos actual y
lgico actual, con el objetivo de conocer la situacin de partida y detectar los problemas
y carencias. A partir de ellos y de los requisitos adicionales que se han ido especificando
se ha deducido el modelo lgico correspondiente al sistema que se est desarrollando
sin pensar an en su mecanizacin.
111

En la fase de Estudio de la Arquitectura se ha definido una solucin tcnica y

organizativa, basada ya en una plataforma hardware y software. En el anterior punto, se
ha completado la especificacin de esta plataforma, determinando cada uno de los
elementos que van a constituir la plataforma del sistema.
En este punto del desarrollo, se regresa al modelo lgico del sistema para transformarlo
en un modelo fsico que contemple la plataforma tecnolgica escogida.
El DFD del modelo fsico tender a convertir qu hace el sistema por cmo lo hace
utilizando dicha plataforma. Para desarrollar este modelo deben realizarse diferentes
actividades:
Establecer las fronteras de mecanizacin: qu procesos deben realizarse

manualmente y cules mediante ordenador.
Determinar los diferentes tipos de procesos y especificarlos por lotes, on-line,

servicio
Disear las entradas y salidas del sistema: ventanas y formularios.
Estimar volmenes de informacin e identificar las transacciones crticas para

desarrollar el modelo lgico de datos a partir del modelo conceptual.
Definir los controles y seguridad del sistema para su explotacin: procesos de

control y seguridad.
Todas las actividades constituyen el modelo fsico del nuevo sistema, y sern estudiadas
una a una en esta seccin.
112

5.2.1. Fronteras de Mecanizacin

La implantacin del sistema sobre la plataforma tecnolgica se especific en la etapa de
Estudio de la Arquitectura, fase en la que se determinaron las caractersticas tcnicas,
organizativas y operativas de la solucin a desarrollar. A partir de ello, se determinan
qu procesos se llevarn a cabo manualmente y cuales se automatizarn, apareciendo
ambos tipos en el modelo fsico final del sistema ya que si no, la funcin de negocio
quedara incompleta. A continuacin se muestran los procesos clasificados segn su
modo de ejecucin, de los dos tipos de controles de acceso:
PROCESO
MODO DE EJECUCIN
Control de Visitas
Iniciar Servicio RFID
Automtico
Identificar
Automtico
Consultar Reservas
Automtico
Confirmar Movimiento
Automtico
Realizar Reserva
Automtico
Actualizar Recursos
Manual
Registrar Prstamos
Manual
Consultar Personal
Automtico
PROCESO
MODO DE EJECUCIN
Obtener Estado Actual
de los Recursos
Esperar Lectura
Identificar Recurso
Obtener Reserva
Asociada
Registrar Movimiento
Automtico
Manual
Automtico
Automtico
Manual
113

La tarea de definir el modelo fsico final se realizar a partir del modelo lgico diseado
en la etapa de Anlisis de Requisitos representando mediante una lnea discontinua las
fronteras entra unos procesos y otros. Dichas lneas se denominan interfaz hombremquina debido a que aparecen bsicamente en las entradas y salidas del sistema.
A continuacin se muestra el DFD correspondiente al modelo lgico mostrando las

fronteras de mecanizacin:
Control de Visitas
En el DFD del modelo lgico se representa el proceso 1 seleccionado mediante una

lnea discontinua indicando que ser automatizado, mientras que el proceso 2 requiere la
intervencin del usuario del sistema de forma que se ejecutar manualmente.
114

Las nicas etapas en las que es necesaria la intervencin del usuario son al solicitar una
lectura y al confirmar un movimiento, de forma que el resto de procesos que constituyen
la gestin de un recurso se ejecutan de manera automtica
En el diagrama correspondiente al Control de Inventario, la frontera de mecanizacin

resulta bastante clara y precisa, mientras que en el Control de Visitas puede encaminar a
una ambigedad contextual por una falta de precisin.
Por ello, si se tiene en cuenta cmo se lleva a cabo la obtencin de la informacin de

una visita probablemente existan procesos que no se ejecutan de forma manual, sino que
en funcin del la fase en la que se encuentre el control de acceso se ejecutar un proceso
u otro, segn proceda, automticamente. Por este motivo, es conveniente disear el
modelo con ms detalle realizando la conversin del qu al cmo: modelo fsico.
115

5.2.2. Especificacin de Procesos

En el diccionario de datos se definen todos los procesos originados en el modelo lgico.
A partir de las fronteras de mecanizacin, se aade una caracterstica ms a estos
procesos: manual o automtico, ya que la definicin realizada de los mismos se orient
hacia la lgica de negocio ms que hacia el contexto informtico o de programacin.
Por ello, se revisan de nuevo las descripciones de los procesos con el objetivo de
mejorar la miniespecificacin actual de cada uno de ellos, considerando que el proceso
ser iniciado por el usuario o automticamente segn corresponda.
Las nuevas miniespecificaciones se realizarn a partir de las ya existentes, que fueron

definidas en la etapa de Anlisis de Requisitos para cada uno de los dos controles de
acceso que se estn diseando.
116

Objeto: Proceso 1, Iniciar Servicio TI
Tipo: Automtico
Control de Visitas
Procedimiento destinado a configurar la comunicacin con el lector LTCX. Dicha

configuracin consiste en determinar un terminal a partir de un slot del mismo, que se
mantendrn durante todo el tiempo de ejecucin de la aplicacin de control de acceso.
Tipo: Automtico
Control de Visitas
Segundo estado de la ejecucin del control de acceso, en la que la aplicacin se

encuentra en espera activa de procesar una lectura y realizar su correspondiente registro
en la base de datos. En este estado de la ejecucin del control de acceso, el usuario
puede proceder a finalizar la aplicacin, bien porque lo desea, o porque se produjo un
error durante la lectura
Objeto: Proceso 3, Mostrar Informacin
Tipo: Automtico
Control de Visitas
Estado del control de acceso en que se proporciona la informacin sobre la

identificacin de la persona que realiza la visita, a quin ha visitado las ultimas veces
que se ha encontrado en el departamento, y todo el personal que constituye la plantilla
117

Objeto: Proceso 4, Consultar Visitante
Tipo: Automtico
Control de Visitas
Proporciona el personal del departamento que aparece en los registros de las ltimas
diez visitas que ha realizado la persona que se est atendiendo, y que se acaba de
identificar a travs de su tarjeta de alumno.
Objeto: Proceso 5, Consultar Personal
Tipo: Automtico
Control de Visitas
Proporciona informacin de toda la plantilla del personal del IIT, con el objetivo de que
el usuario, cuando lo necesite, seleccione la persona que se desea visitar.
Objeto: Proceso 6, Obtener Visita Actual
Tipo: Manual
Control de Visitas
Etapa durante la fase de ejecucin en la que se configuran los datos que definen la visita
que se desea registrar. Cuando el usuario confirme los datos proporcionados a travs del
interfaz de la aplicacin, se proceder a realizar un registro del visitante y de la visita
asociada al mismo.
Objeto: Proceso 7, Apagar Lector
Tipo: Manual
Control de Visitas
Finalizar la comunicacin con el lector LTCX, procediendo a su apagado.
118

Objeto: Proceso 1, Mostrar estado actual

de los recursos
Tipo: Automtico
Tipo: Manual

aplicacin.
Objeto: Proceso 3, Identificar recurso
Tipo: Automtico
la TRAMA, lo primero que realiza es la identificacin del cdigo recibido.
119

Objeto: Proceso 3, Identificar recurso (Cont) Identificador: PSCAP.3

Tipo: Automtico
Si ste se corresponde con alguno de los recursos del departamento se proceder a

registrar el movimiento en cuestin, pero si no se corresponde con ninguno el sistema
solicitar una nueva lectura cambiando de nuevo al estado de Esperar Lectura.
Objeto: Proceso 4, Obtener reserva

asociada
Tipo: Automtico


120

Objeto: Proceso 5, Registrar movimiento
Tipo: Automtico

Los movimientos gestionados se corresponden con entregas, ya reservadas o no, y

devoluciones de recursos, cuando finaliza la validez del prstamo.
Adems de las especificaciones, se debe de determinar la categora de todos los

procesos. La categora de un proceso establece su naturaleza, en funcin de la
arquitectura elegida. En este caso todos los procesos ofrecen un servicio particular que
en conjunto permite realizar la gestin de un control de acceso determinado.
Por ltimo, los procesos deben estar definidos con una frecuencia de operacin, la cual
determina en qu periodos de tiempo se debe ejecutar el proceso. Cada uno de los
controles de acceso se ejecutar todos los das de manera aleatoria, dependiendo de la
asiduidad con que se reciban las entidades a controlar, ya sean visitas como el
tratamiento de los prstamos o devoluciones de los recursos del departamento.
5.2.3. Diseo de Entradas

En esta etapa se realiza el diseo de las ventanas que van a constituir el interfaz de los
controles de acceso. Dichas interfaces se caracterizan por ser constantes, es decir, no
hay una navegacin entre ms de una ventana, sino que los diferentes flujos de
informacin se irn mostrando cuando proceda en la misma.
121

Ventana Control de Visitas
Es posible que durante la etapa de programacin se realicen cambios en el diseo del

interfaz de forma dinmica, con la finalidad de alcanzar los objetivos marcados en cada
una de las etapas y de proporcionar un interfaz claro e intuitivo de cara al usuario final.
122

Ventana Control de Inventario
5.2.4. Diseo de Salidas

Los flujos de datos que salen del sistema hacia las entidades externas se pueden
considerar como salidas hacia el exterior, y podrn resultar ser ventanas de resultados o
formularios.
En el Control de Visitas el flujo de salida se mostrar siempre en la ventana principal,

siendo el usuario de la aplicacin quien confirme la visita para proceder a su registro en
la base de datos.
Por otro lado, el Control de Inventario tiene adems situaciones en las que se
proporciona un formulario para completar el movimiento de un recurso, ya sea un
prstamo no reservado con anterioridad o una devolucin temprana respecto a la fecha
de devolucin registrada.
123

5.2.5. Estimacin de Volmenes de Informacin

La estimacin de volmenes pretende alcanzar dos objetivos principalmente. El primero
de ellos es dimensionar el tipo de transacciones que se pueden presentar ajustando el
modelo a las necesidades fsicas de stas.
Las transacciones que supongan mayor nmero de accesos a la base de datos sern las
ms crticas, de forma que se deber prestar ms cuidado con el objetivo de no
sobrecargar el sistema. An as, no se considera un problema como tal ya que no
existirn dos ejecuciones de las mismas caractersticas en paralelo.
Tambin este estudio de volmenes indicar si los procesos definidos en el modelo

lgico estn bien diseados respecto a los flujos de informacin con los que trabajan.
Para que el modelado sea fsico y se pueda implantar en una mquina, se debe
considerar el modo ms rentable y eficaz de acceso a los datos y de procesado de los
mismos.
El segundo objetivo determinado es el de obtener informacin acerca de las diferentes

entidades del modelo de datos, con la finalidad de realizar un buen diseo conceptual de
datos.
De esta manera se pueden encontrar nuevas necesidades de crear claves o

identificadores que resten tiempo de acceso a la base de datos de los programas, aunque
se requiera aumentar la redundancia y por tanto la ocupacin en disco.
Para realizar el anlisis se parte del modelo lgico o fsico de procesos, del modelo de
datos, del ciclo de vida de las entidades y de los diseos de entrada y salida. Un primer
anlisis se puede realizar configurando una Matriz de Procesos/Entidades:
124

Control de Visitas
PROCESOS/ENTIDAD
VISITANTE
EMPLEADO
VISITA
SISTEMA
Iniciar Servicio TI
Esperar Lectura
Mostrar Informacin
Consultar Visitante
Consultar Personal
Obtener Visita Actual
Apagar Lector
A
C
PROCESOS/ENTIDAD RECURSO EMPLEADO PRESTAMO RESERVA SISTEMA

Mostrar estado actual
de los recursos
Esperar Lectura
Identificar recurso
C, L
Mostrar reserva
asociada
Registrar movimiento
125

En las filas se colocan los procesos y en las columnas las entidades y relaciones del
modelo de datos. Una vez definida la matriz, se deben localizar las transacciones que
componen el sistema. Las transacciones son conjuntos de procesos que transforman la
informacin a travs del sistema, constituyendo una actividad o funcin especfica para
el negocio que se est diseando.
El mtodo que se ha escogido para definir las transacciones consiste en agrupar los
procesos de DFDs partiendo del DFD de nivel conceptual, y teniendo en cuenta la
integridad de la operacin que se ha de realizar a travs del sistema, combinndola
adecuadamente a la interaccin externa del usuario final. Por tanto este mtodo tiene en
cuenta el proceso lgico y el operador fsico que lo realiza, pero no los datos que se
estn manejando.
Control de Visitas
126

Los procesos 3, 4 y 5 tienen un cometido homogneo, lectura de la base de datos, de

manera que no supone un riesgo para garantizar la compatibilidad de las operaciones y
la integridad de los datos. Realizan una lectura cada vez que se gestiona un control de
acceso, no se considera operacin crtica, de manera que si se tiene en cuenta una
perspectiva de futuro se podran ejecutar ms de una transaccin de este tipo en paralelo
si se desea llevar a la prctica controles de acceso en varios puntos del edificio, en este
caso, de la universidad.
El proceso 6 es el nico que realiza una operacin caracterizada por su criticidad,

debido a que realiza escrituras contra la base de datos responsable de registrar la visita
que se va a llevar a la prctica as como la escritura en el log, de forma que es coherente
que se considere como una transaccin independiente de la ya descrita con anterioridad.
127

Los procesos 1,3 y 4 son de lectura, realizan consultas contra la base de datos con el
objetivo de obtener la informacin necesaria para poder realizar adecuadamente la
gestin de un recurso. Por ello, los tres procesos anteriores se pueden considerar en
conjunto como una misma transaccin.
El proceso Registrar movimiento supone la escritura del prstamo gestionado en la

base de datos, y la actualizacin del estado del recurso que se ha entregado o devuelto.
Por este motivo, al tratarse de operaciones crticas que pueden alterar la coherencia e
integridad de la informacin almacenada, este proceso se ha de gestionar como una
transaccin independiente.
5.2.6. Procesos de Control y de Seguridad

En el modelo de procesos diseado en la etapa de Anlisis de Requisitos no se tuvieron
en cuenta los posibles controles del proceso de explotacin del sistema, debido a que
dichos procesos no definen la funcionalidad de negocio del sistema ya que se trata de
procesos destinados al control de la operacin del sistema. Ms concretamente,
podemos relacionar dichos procesos con el mbito de la informtica.
En este punto del proyecto ya se conoce con ms detalle el nuevo sistema, de manera
que a continuacin se procede a introducir y especificar en el modelo los controles de
operacin y de seguridad, ya que se sabe cmo se van a mecanizar las tareas que se han
definido en los apartados anteriores. Todos estos procesos de control y de seguridad se
incluirn dentro de los procesos existentes ya que el alcance del proyecto es bastante
limitado y los procesos slo se ejecutaran cuando se est gestionando un control de
acceso (no es un proceso que se est gestionando de manera activa durante todo el
tiempo). En otros proyectos, estos procesos se consideran independientes de los dems
debido a que realizan otras funciones adicionales como consecuencia de los controles
que lleven a la prctica, de forma que se incluyen en el modelo fsico del sistema. Para
realizar un anlisis completo del control del sistema, se deben estudiar los procesos de:
128

Controles destinados a preservar la integridad de los datos
Seguridad de la informacin y del acceso
Auditabilidad del sistema por el usuario o por el administrador
Procedimientos de recuperacin de la informacin
Historizacin de la informacin
Debido a las caractersticas del proyecto no procede realizar un estudio de todos los
puntos enumerados, ya que no se trata de un sistema de gran contenido funcional, y
mucho menos requiere de procedimientos de recuperacin y de historizacin tan
exhaustivos al no manejar grandes volmenes de datos de manera continua en el tiempo.
Tampoco se necesitan editar informes de anlisis que muestren el correcto

funcionamiento del sistema, ni realizar actividades de auditabilidad. A continuacin se
explican los aspectos de control y de seguridad que se consideran que debe de poseer el
sistema que se est desarrollando.
Procesos de Control
Se entiende por control a la comparacin de un hecho o una tarea realizada con un

objetivo prefijado. Estos objetivos son las reglas que de acuerdo a la finalidad del
sistema en estudio se deben cumplir, mientras que los hechos sern las circunstancias
detectadas en un momento dado durante el periodo de explotacin del sistema.
Las medidas estudiadas y seleccionadas para garantizar la integridad de los datos son las
siguientes:
129

1. Control de los registros ledos frente a los registros grabados. Todo proceso que
realice una lectura de un conjunto de registros de una tabla de la base de datos,
para tratarlos y gestionarlos en su totalidad debe generar el mismo nmero de
registros insertados o presentados. Si no se cumple esta igualdad, algn registro
habr sido despreciado, ignorado, o lo que es ms grave, perdido.
2. Disear algoritmos que relacionen registros ledos, tratados y rechazados. Es

posible definir ecuaciones o algoritmos donde, de acuerdo al proceso realizado,
el nmero de registros ledos debe ser el mismo que la suma de los grabados ms
los rechazados.
3. Controles de las lecturas y escritura realizadas contra la base de datos donde

residen los registros de informacin que maneja el sistema
No se contempla tener un registro de logging, ya que los movimientos que se escriban

en la base de datos, en este caso, muestran el estado actual de los recursos y del personal
en cada momento dentro del departamento.
Seguridad de la informacin
Engloba los procesos o procedimientos de seguridad de uso, seguridad de los datos,

privacidad de la informacin y seguridad ante accesos no autorizados. Para estudiar
estos procesos se deben definir los riesgos potenciales del sistema considerando las
consecuencias de los mismos. As los aspectos a considerar se han desglosado en cuatro
categoras:
1. Seguridad de los datos en su gestin, asegurando que los datos de salida desde el
sistema, sean utilizados por aquellos a los que van dirigidos.
130

2. Seguridad de la confidencialidad de la informacin, garantizando que

nicamente las personas que estn autorizadas pueden acceder a la informacin
de carcter personal, de acuerdo con la legalidad vigente.
3. Seguridad del propio sistema proporcionando la disponibilidad del sistema ante

cadas provocadas por el hardware o software.
4. Asegurar el acceso al sistema desde un terminal.
An as, se deber sopesar el esfuerzo del diseo y de programacin que suponen estos
controles frente a los beneficios que van a proporcionar, y establecer el grado de control
y se seguridad que se requiere alcanzar.
131

6. Diseo
Interno
132

En esta fase de identifican y disean los diversos componentes software del sistema,
describiendo detalladamente sus especificaciones fsicas. Dependiendo de la
arquitectura elegida correspondiente al sistema final, estos componentes pueden ser de
una naturaleza muy diferente.
Teniendo en cuenta el Modelo Fsico de Procesos diseado en la etapa de Diseo

Externo, donde cada proceso ha sido catalogado como de naturaleza de servicio, se
reunirn todas las funciones de negocio de nivel ms detallado en funcin de su
tipologa, y se estructurar el sistema en un conjunto de subsistemas. Generalmente los
subsistemas estn formados por procesos de diferente naturaleza, pero en este proyecto
el sistema est definido por procesos de la misma naturaleza: de servicio.
Tambin se deben considerar las ventanas y formularios que se han diseado en la etapa
anterior, para garantizar la coherencia del diseo. Para aquellos subsistemas de tipo
cliente-servidor se tendrn que identificar y disear los mdulos o programas cliente y
los programas de servicio, al igual que las transacciones (es la tipologa que se
corresponde ms fielmente a la del sistema que se est desarrollando).
Una vez diseada la funcin de negocio y estructurada en sus componentes de

programacin, se realizar una especificacin de cada uno de ellos, denominada
Cuaderno de Carga.
Dicha especificacin recoge todos los elementos de diseo que debe tener en cuenta el
programador para codificar cada programa, cmo son los ficheros de entrada y salida,
los diseos de ventanas utilizados por el programa, los controles que se deben aplicar, y
las reglas de negocio que deben satisfacerse para que a partir de los datos de entrada se
obtengan los de saldas esperados.
El Cuaderno de Carga es un documento que ser utilizado tanto para la programacin

como para llevar a cabo la etapa de pruebas.
133

Antes de iniciarse la programacin se debe finalizar el diseo de la base de datos y

dems ficheros para que los programas se codifiquen utilizando la configuracin
establecida, y mediante las pruebas correspondientes comprobar la correcta ejecucin de
stos.
Finalmente, a partir de la estrategia definida para cada uno de los planes de pruebas y de
formacin, se deben disear los elementos software necesarios para llevarlos a la
prctica, y especificarse cada uno de los planes mediante las actividades a realizar, los
recursos a utilizar, y la planificacin a seguir.
6.1. Tcnicas a utilizar

Se cuentan con diversas tcnicas para el diseo de componentes software de una
funcin de negocio. Las metodologas estructuradas basan su diseo de modelo de
procesos en la tcnica de Diagrama de Flujo de Datos, por lo que los diseos de
funciones realizados sobre ellos permiten estructurarlos y disearlos paralelamente. De
esta manera existe una continuidad en el diseo, que de otro modo supondra abandonar
el modelo fsico de procesos ya realizado para inventar el diseo detallado de la
funcin. Por este motivo, y considerando que las funciones de negocio sern On-line,
cualquier componente puede disearse basndose en los DFDs. Bsicamente la tcnica
que se va a utilizar consiste en realizar la conversin del DFD al diagrama estructurado
que le corresponda para identificar a cada componente.
Para los subsistemas online tanto las transacciones a ejecutar bajo un monitor
transaccional como los programas cliente-servidor, se utiliza la derivacin del DFD
fsico de cada funcin hacia el diagrama de cuadros estructurado o Structured Chart.
ste es un diagrama que permite mostrar la jerarqua existente entre los mdulos
principales y subordinados, de manera que cada uno realice una nica tarea y se muestre
como un componente al que se le llama envindole unos parmetros y devolviendo un
resultado.
134

Dependiendo de las caractersticas del diseo, stos mdulos pueden empaquetarse o

encapsularse en rutinas reutilizables, mdulos funcionales o libreras de funciones
(DLLs o clases .java). Para comprender y disear el dilogo de la aplicacin con el
usuario final, a veces resulta conveniente utilizar los Diagramas de Flujo de Aplicacin,
pero en este caso no se considera necesario por la sencillez de la navegacin que
caracteriza a las aplicaciones de los controles de acceso, al no variar de ventana
principal.
6.2. Subsistema Online

Aquellas funciones de negocio que no se ejecuten bajo un orden secuencial, y por el
contrario, se procesen de manera aleatoria a peticin del usuario, constituyen el
subsistema online. Estas funciones han sido diseadas en el modelo fsico de procesos,
donde sus componentes son flujos de datos, almacenes y procesos. Mediante la
derivacin del DFD de la funcin hacia un Diagrama de Cuadros Estructurado o STC,
estos componentes darn lugar a los ficheros, ventanas, y mdulos de programa que se
disearn y especificarn unitariamente.
El mtodo a seguir consiste en tomar toda la informacin de cada funcin disponible en

el modelo fsico y derivarla al diagrama STC, mediante dos mtodos posibles de
derivacin y la creatividad de la persona que desempea el perfil de diseador. Por
ltimo, se encapsula la funcin en una transaccin o librera.
El diseo del software orientado a objetos utiliza otros paradigmas diferentes al

subsistema online, dadas sus caractersticas propias de herencia, encapsulamiento y
polimorfismo: diagramas UML. Por ello, se ha decidido disear el sistema utilizando las
dos metodologas: en OO porque uno de los requisitos del proyecto es que se programe
en Java, y tambin se representa como un subsistema Online ya que en futuras versiones
el software final del proyecto se puede implantar como un sistema distribuido donde
varios lectores, conectados a travs de una LAN, se comuniquen con una aplicacin que
se encuentre ubicada por ejemplo en el servidor o en otra estacin de trabajo a la actual.
135

6.2.1. El diagrama de Cuadros Estructurado (STC)

El STC es un diagrama jerrquico donde los elementos son mdulos con informacin
sobre su acoplamiento respecto a otros mdulos: datos y control. Un mdulo es un
programa con una funcin nica, que puede ser llamado por otros mdulos y a su vez
puede llamar a otro, mediante el paso de parmetros o flujos de informacin y/o control.
En el subsistema online aparece un nuevo componente que no aparece en un subsistema

BATCH. Lo constituyen los eventos que pueden proceder del propio sistema operativo
de la mquina donde reside el sistema o del exterior, provocados por las acciones del
usuario final sobre su interfaz.
De esta forma, cuando se disearon las ventanas o el interfaz, se tuvieron en cuenta los
diferentes eventos que podan tener lugar durante la ejecucin de la aplicacin, y la
actuacin o respuesta que el sistema deber realizar en cada situacin. Ahora es el
momento de solapar la navegacin del sistema con la lgica de negocio (servicios).
El modelo de diseo utiliza tres elementos, de manera similar a los modelos de

procesos:
Estructuras de cuadros o diagrama STC (componente grfico)
Repositorio o diccionario (componentes de definicin)
Miniespecificaciones (componentes de especificacin)
La tcnica STC se basa en tres conceptos: descomposicin, jerarqua e independencia.
La descomposicin:
Divisin de las funciones de negocio, en mdulos ejecutables.
136

Fcil de mantener, al obtener una alta modularidad del software
Minimiza la duplicidad del cdigo
Posibilita la reutilizacin del cdigo
La jerarqua:
Facilita el diseo basado en componentes: presentacin, negocio y datos.
Mdulos altos, responsables de realizar la coordinacin y el control del proceso.
Mdulos bajos, encargados de realizar las operaciones.
La independencia:
Un mdulo es un componente software: procedimientos, datos.
Un mdulo no debe preocuparse de la estructura de otro: son cajas negras.
El diagrama STC utiliza una sencilla paleta para realizar su diseo, aunque varia en
funcin de la herramienta CASE que se utilice. Los smbolos esenciales son los
siguientes:
El rectngulo identifica un mdulo genrico, que se localizar en un

determinado nivel dentro de la jerarqua. De esta forma, existirn mdulos
padres o jefes, y mdulos hijos o subordinados, de acuerdo con la jerarqua de
control del proceso que se desee establecer.
137

Un rectngulo con una flecha en semicrculo en su base, representa a un mdulo

iterativo, de forma que una vez que es llamado permanecer en ejecucin hasta
que se detenga su mdulo principal.
Un rectngulo con un rombo en su base representa un mdulo de decisin, de

modo que la secuencia de ejecucin de los mdulos subordinados es un nico
camino entre varios. Generalmente este camino ser tomado en funcin del flujo
de control o de informacin que reciba.
Un rectngulo con dos lneas paralelas representa un mdulo reutilizable en

diferentes funciones de negocio, de manera que ser diseado una sola vez, y
llamado tantas veces como sea necesario.
Para expresar la utilizacin de diferentes dispositivos de E/S se suelen utilizar

diversos smbolos, siendo los ms comunes y genricos los que se muestran en
los organigramas tradicionales. Este icono representa cualquier soporte de
entrada y salida, debido a que ser el componente de definicin del modelo el
que determine la unidad fsica que se utiliza. En este caso se correspondern con
los lectores que se instalarn para realizar los dos controles de acceso.
138

Las flechas con direccin dispuestas sobre la estructura jerrquica del diagrama
representan los flujos de informacin. Estos flujos son los datos de negocio que
manipulan los mdulos. Estas mismas flechas en vdeo inverso hacen referencia
a los flujos de control, que se corresponden con los datos utilizados por el
sistema del ordenador para controlar el proceso: mensaje de error, finalizacin
correcta, caracteres de control de dispositivos
El diagrama STC establece una jerarqua en la dependencia de los mdulos principales

y sus subordinados. Un STC debe interpretarse de arriba hacia abajo y de izquierda a
derecha.
6.2.2. Derivacin del DFD al STC

A partir del diseo fsico de la funcin de negocio recogida en el modelo de procesos,
aplicamos el mtodo de derivacin de transformacin para conseguir organizar dicha
derivacin como una transaccin online, donde existe un programa principal que
identifica dicha transaccin o funcin. Para ello deben considerarse los siguientes
puntos:
1. Disponer o dibujar el DFD de ltimo nivel
El DFD que se utilizar para realizar la derivacin al diagrama STC es el que se dise
en la etapa de Anlisis de Requisitos, el cual proporciona informacin sobre lo que hace
el sistema y cmo.
Para que el estudio sea mucho ms detallado, se realizar la derivacin de los dos
controles de acceso en paralelo, ya que se tratan de aplicaciones que se ejecutan de
manera independiente sobre bases de datos diferentes, a pesar de que en conjunto
constituyen el mismo sistema.
139

Control de Visitas
140

2. Identificar el centro de transformacin (CT)
Los centros de transformacin identificados en cada uno de los controles de acceso se

muestran con una lnea roja discontinua.
Control de Visitas
141

3. Realizar la primera aproximacin al STC
A partir de la localizacin del CT, se realiza una primera aproximacin de la estructura

del diagrama. Generalmente cada funcin derivada requiere de un mdulo principal, que
identificar la transaccin. Este mdulo se encargar de recibir la llamada del men de
la aplicacin, y coordinar la ejecucin del proceso cediendo el control a sus mdulos
subordinados.
Adems el mdulo principal ser el que deba configurar las variables de entorno o
globales de la funcin, as como la peticin de recursos al sistema para poder llevar a
cabo la ejecucin de la transaccin. Bajo ste mdulo, siempre aparecer una estructura
donde a la izquierda estarn los mdulos del camino o camino de entrada, a la derecha
los mdulos que configuran el camino o los caminos de salida, y en el centro, el mdulo
o mdulos que constituyen el centro de transformacin.
Puede ocurrir que se cuenten con varios caminos de entrada o salida, en cuyo caso se
establecer directamente la jerarqua de los caminos, o un mdulo intermediario que se
encargue de controlar a los diferentes caminos de entrada o salida, bajo el cual se
subordinarn los caminos.
Los mdulos intermediarios de entradas y salidas son responsables de controlar los

procesos de los caminos subordinados.
142

La primera aproximacin correspondiente a los DFDs de las aplicaciones que realizan

los dos controles de acceso son las siguientes:
Control de Visitas
4. Refinar la estructura con criterios de diseo
Una vez obtenida la estructura de aproximacin, se retrocede de nuevo al DFD de

partida para trasladar los procesos, flujos y almacenes al STC. Los procesos de los
caminos de entrada y de salida se llevan al diagrama en el mismo sentido en que se
recorren dichos caminos, desde el centro de transformacin hacia el exterior. Esto
significa que las burbujas de los caminos de entrada quedarn representadas como
mdulos subordinados, donde el ltimo de ellos se corresponder con el de ms bajo
nivel o de lectura, debido a que el diagrama se recorre de arriba hacia abajo y de
izquierda a derecha.
143

Las burbujas de los caminos de salida se organizan en mdulos subordinados en el

mismo sentido que en el DFD.
Adems se deben mostrar los dispositivos de entrada y salida, en este caso los lectores,
el terminal del usuario y la base de datos, utilizados para realizar las lecturas y escrituras
que se configuren y utilicen a lo largo de la gestin del movimiento del control de
acceso.
Respecto a los flujos de datos se mantienen su estructura y ubicacin, justamente en los

mismos lugares donde aparecen en el DFD, ya que son los mdulos ahora los que se
encargan de transformar unos flujos en otros.
Se pueden introducir tantos flujos de control como se consideren que sean necesarios.
Dichos flujos de control permitirn conocer el estado de los controles de acceso en cada
momento.
En el diagrama STC correspondiente a cada uno de los DFDs de los controles de acceso
se muestran las burbujas en diferentes niveles caracterizados por un color diferente,
dependiendo del nivel que le corresponda.
Como se ha comentado con anterioridad, se han aadido las seales de control que se
transmiten entre el sistema y el lector, con el objetivo de gestionar y controlar el
correcto funcionamiento de la aplicacin, y as reaccionar de la mejor manera posible
ante las diversas situaciones que se pueden dar durante cada una de las ejecuciones de
los controles de acceso.
A continuacin se muestra para cada control de acceso el diagrama STC final diseado
a partir de las consideraciones que se han ido comentando a lo largo del desarrollo del
presente punto.
144

Control de Visitas
145

5. Verificar la estructura final encapsulando mdulos en programas
Una vez obtenida la estructura final, se debe realizar un ltimo estudio de la

funcionalidad, verificando su correcto funcionamiento, y estableciendo la forma en que
se van a encapsular los mdulos en los diferentes programas, dando lugar a las
diferentes transacciones que definirn el sistema final. Esta operacin se debe realizar
teniendo en cuenta las pautas que se han descrito en al apartado 6.2.3. , referentes al
tamao de los programas, la reutilizacin del cdigo, la ubicacin fsico
El mdulo principal se corresponde con un mdulo de control de la transaccin, y

permanecer como programa de control. La funcin de entrada, constituida por los
mdulos encargados de recoger los flujos de datos de entrada, se encapsular en un
nico programa que ser ejecutada en la mquina del usuario final, al igual que el resto
de mdulos. El mdulo principal ser el responsable de controlar el estado de la
aplicacin al iniciar su funcionalidad con una lectura, y a la hora de tratar los accesos a
travs de las correspondientes llamadas a los dems mdulos: el de acceso a la base de
datos, y el mdulo que se comunica con el lector.
La funcin de negocio, por ejemplo Obtener Informacin en el Control de Visitas, se

encapsular de manera aislada al resto, al menos en tratamiento, ya que facilita el
mantenimiento ante posibles cambios en un futuro. Hay que recordar que, el mdulo de
Obtener Informacin representa el Centro de Transformacin del Control de Visitas.
Por otro lado, los mdulos de salida de ambos controles de acceso se gestionarn desde
el mdulo principal, de forma que los primeros sern los responsables de informar al
usuario el resultado de la gestin y tratamiento del movimiento de acceso, y de hacerlo
permanente en la base de datos correspondiente.
Finalmente, el encapsulamiento del STC de Control de Visitas esta formado por cuatro
transacciones diferentes, y lo mismo ocurre con el subsistema Control de Inventario.
146

Control de Visitas
147

6.2.3. Consideraciones de diseo

El software se caracteriza por una serie de caractersticas que se deben tener en cuenta
cuando se quiere decidir cmo encapsular los programas, con el objetivo de conseguir
las ventajas ms apropiadas para el diseo que se est realizando. Las aplicaciones
presentan requerimientos muy diferentes, por lo que hay que conocer al mximo detalle
el software que se est generando.
Dos propiedades que delimitan la divisin del sistema en subsistemas o mdulos son el
tamao y la complejidad. Es decir, decidir si interesa construir un programa con muchas
o pocas instrucciones. En este caso, la ejecucin de los controles de accesos se realiza a
partir de ficheros de cdigo cuyo tamao no es grande debido a que el alcance del
mismo est acotado para el departamento de la universidad, y por tanto la funcionalidad
tambin. Debido al pequeo tamao de los ficheros, permitir evitar problemas de
diseo, de pruebas y sobre todo de mantenimiento.
A lo anterior, hay que aadirle que se evita el problema de falta de memoria para llevar
a cabo la ejecucin de las aplicaciones, de modo que el tiempo de ejecucin de los
mismos no se ven afectados por este problema. An as, hay que tener en cuenta que la
tecnologa bytecode de Java presenta algn retardo en la gestin de eventos que se ven
compensados por los rpidos accesos a la base de datos.
Los ficheros de cdigo se ubicarn en el ordenador del usuario final que se encuentra
localizado en la entrada del edificio del departamento del IIT. En este caso, al contar
slo con una mquina servidora no existen problemas derivados de la distribucin de la
carga a travs de la red.
La complejidad es otro factor que determina la modularidad de los programas. Existen

funciones de negocio que por su complejidad generan gran cantidad de cdigo. En este
caso, dado que dicha funcin de negocio se ha estructurado sobre el modelo fsico de
procesos, siempre se puede descomponer en un conjunto de programas.
148

El factor de reutilizacin siempre debe tenerse en cuenta a la hora de encapsular los

programas. En este aspecto, las tecnologas orientadas a objetos han superado a los
paradigmas estructurados. Y la premisa seguida es muy razonable: se encapsulan
aquellos mdulos que puedan ser reutilizados por otros componentes.
Otro elemento a tener en cuenta es el diseo basado en componentes, donde la lgica de

presentacin suele estar en las estaciones cliente, o los servidores Web, la lgica de
aplicacin en los servidores de aplicaciones, y la lgica de datos en los servidores de
bases de datos. En el presente sistema, la lgica de presentacin y de aplicacin se
encuentra en la mquina del usuario final, pero gestionadas por diferentes mdulos, o
patrones de diseo. Al encapsular el software se tiene que considerar dnde se va a
ejecutar el programa, de manera que se pueda distribuir coherentemente con la funcin
de negocio a desempear en cada mquina o sistema.
En cuanto al diseo, existen dos factores que se deben tener en cuenta para determinar
la modularidad del software: el acoplamiento, o dependencias, que pueda existir entre
diferentes mdulos, lo cual es negativo, y la cohesin, dependencia funcional, entre los
elementos de un mdulo, factor que se pretende maximizar.
6.3. Diagrama del Sistema

Este tipo de diagramas son utilizados para mostrar visualmente las diferentes opciones
de navegacin por el sistema, de manera que a partir de la ventana principal se observen
las diferentes funciones de negocio del mismo.
Cada dilogo o submen podr estar formado por varias ventanas o mostrarse dentro del
contexto de la ventana principal. El diagrama del sistema sirve por tanto como un punto
de referencia para realizar el Manual de Usuario.
149

Se debe tener en cuenta en todo momento el tipo de usuario final que ser el responsable
de utilizar la aplicacin, de forma que el diseo debe ser sencillo e intuitivo con el
objetivo de que el usuario se pueda familiarizar sin problemas con los programas.
Control de Visitas
6.4. Cuaderno de Carga

Los Cuadernos de Carga recogen toda la informacin de diseo del programa, ya sea
online o de tipo batch. A continuacin se describen los Cuadernos de Carga de los dos
controles de acceso que constituyen el sistema que se est desarrollando.
150

6.4.1. Cuaderno de Carga de Control de Visitas

1. Descripcin de archivos
El programa se codificar en Java, de forma que los archivos tendrn la extensin de

.java (junto con sus correspondientes ficheros de compilacin denominados .class).
Adicionalmente, se proporciona la posibilidad de recoger en un fichero Excel todas las
visitas que se hayan tratado durante los ltimos tres das.
2. Descripcin del tratamiento o lgica de negocio
INICIAR SERVICIO TI
Identificador: PROCV.01
Al arrancar por primera vez la aplicacin, se establecer la comunicacin inicial entre el

sistema y el lector TI, con el objetivo de configurar el canal de transmisin para las
lecturas que se realicen a posteriori.
ESPERAR LECTURA
Seguidamente el sistema pasar a un estado de espera de lectura, hasta que reciba la

notificacin, mediante el String de caracteres, de que se ha introducido una tarjeta. El
sistema siempre se va encontrar en este estado menos cuando se encuentre gestionando
una visita.
Si se recibe una persona ajena de la universidad o un alumno sin la tarjeta que le

identifica como tal, se proporcionar la opcin de registrar la visita sin realizar una
lectura como tal.
151

IDENTIFICAR TARJETA
Cuando el sistema reciba la cadena de caracteres deber codificarlo para garantizar que
la tarjeta introducida es la de la universidad y proporcionar los datos personales del
visitante: identificador de alumno junto con el nombre y los apellidos.
OBETENER INFORMACIN
Cuando se haya autentificado la tarjeta e identificado el visitante, se proporcionar la

plantilla de empleados del IIT, y las ltimas visitas que la persona que se est
atendiendo ha realizado con anterioridad.
Si el visitante no dispone de carnet de alumno, se le asignar un identificador especial
para poder registrarlo en la base de datos, activando para ello la opcin que estar
localizada en la ventana principal.
OBETENER VISITA ACTUAL
El usuario deber de seleccionar la fila correspondiente a la persona que se va a visitar,

ya sea en la tabla de visitas anteriores o en la tabla que recoge al personal del
departamento.
REGISTRAR VISITA
La confirmacin del usuario supone la insercin en la base de datos de los registros:
Visitante: identificador, nombre, apellidos
Visita: identificador visitante, identificador empleado, hora
152

MOSTRAR SOLUCIN
Despus de definir la vista que se est gestionando y de registrarla en la base de datos,

se deber de informar al usuario del resultado de las inserciones en dicha base de datos.
Se considera la posibilidad de ofrecer a travs de un men, la opcin de salir del

programa, de ayuda y de realizar el volcado del fichero de recuperacin.
3. Estructura del programa: Pseudocdigo
153

4. Diseo del formato de los registros
Como se ha explicado en el punto del Modelo Conceptual de Datos, se han definido tres
tablas para poder realizar el registro de las diferentes visitas, cuyos formatos se
describen a continuacin:
TABLA: USUARIOS
IDENTIFICADOR: TABLACV.1
TABLA: VISITANTES
TABLA: LOG_VISITAS
154

6.4.2. Cuaderno de Carga de Control de Inventario

1. Descripcin de archivos
La aplicacin ser programada en Java, de forma que el cdigo fuente con extensin
.Java (junto con el compilado .class) residir en una carpeta especial. Adems, en dicha
carpeta se ubicarn tambin las DLLs necesarias para la comunicacin con el lector
RFID.
2. Descripcin del tratamiento o lgica de negocio
Mostrar estado actual de los recursos
Esperar Lectura

aplicacin.
155

Identificar Recurso
la TRAMA, lo primero que realiza es la identificacin del cdigo recibido. Si ste se
corresponde con alguno de los recursos del departamento se proceder a registrar el
movimiento en cuestin, pero si no se corresponde con ninguno el sistema solicitar una
nueva lectura cambiando de nuevo al estado de Esperar Lectura.
Mostrar reserva asociada



Registrar movimiento

156

Se ha decidido aadir un aspecto funcional a la utilidad de RFID: en cada uno de los

registros de un prstamo escribir en la tarjeta las condiciones con que se realiza ste por
ejemplo sin maletn, sin discoDicha escritura ser controlada para no superar la
longitud mxima de 16B del bloque del TAG donde se almacenar el comentario.
3. Estructura del programa: Pseudocdigo
157

4. Diseo del formato de los registros
Como se ha explicado en el apartado del Modelo Conceptual de Datos, se han definido

tres tablas para poder realizar la gestin de la entrega o devolucin de los recursos. El
formato de los registros de stas se describe a continuacin:
TABLA: PRSTAMOS
IDENTIFICADOR: TABLACI.1
TABLA: ITEMS
TABLA: RESERVAS
158

7. Programacin
159

El objetivo de esta etapa es alcanzar la transformacin del sistema en un conjunto de

programas que se ejecuten satisfaciendo los requisitos marcados bajo unos criterios de
seguridad. La dificultad reside en cmo realizar la transformacin de la mejor forma
posible, debido a que va a depender de los lenguajes de programacin que se utilicen, de
las herramientas y utilidades software disponibles, y del responsable de la
programacin.
Como ya se ha comentado en las primeras etapas, no slo es necesario realizar un buen

diseo, sino tambin conseguir un sistema tangible de calidad, con resultados
econmicos, fiables, y que funcione adecuadamente facilitando y disminuyendo el
mantenimiento futuro.
En esta etapa se inician las pruebas del software con el objetivo de confirmar que cada
mdulo del programa funciona correctamente de acuerdo a los criterios establecidos. No
basta con una compilacin correcta, sino que deben contemplarse todas las
circunstancias en el que el programa pueda ejecutarse con el objetivo de evitar posibles
errores no controlados. Sobre todo, el programa debe tener un control completo de su
ejecucin, de manera que en el caso de que se tengan que afrontar anomalas, el mismo
programa debe auditarse e informar al usuario de lo sucedido, para que el propio
programa o el usuario sea el responsable de tomar la decisin de qu accin realizar.
Adems de codificar los programas, de acuerdo a los Cuadernos de Carga diseados en

la etapa del Diseo Interno, deben desarrollarse los procedimientos catalogados o scripts
de ejecucin, que constituyen los programas de control de ejecucin de las funciones de
negocio o transacciones.
En base a los programas desarrollados y los procedimientos de control, se confeccionan

los manuales o guas de usuario y de explotacin del sistema. El sistema quedar
definido por dos manuales de usuario y de explotacin, debido a que esta formado por
las dos aplicaciones que llevan a la prctica los controles de acceso al edificio del
160

7.1. Anlisis y diseo orientado a objetos

Dado que los programas sern codificados utilizando el lenguaje de programacin Java,
se ha optado por realizar el Ciclo de desarrollo orientado a objetos.
7.1.1. Introduccin
Las metodologas orientadas a objetos y de Anlisis Estructurado se diferencian en el
nfasis que se aplica a los distintos componentes del modelado. Las tcnicas de
orientacin a objetos (OO) se encuentran dominadas por los modelos de clases y de
objetos. Estas tcnicas representan la realidad a travs de objetos, de clases de objetos,
de sus relaciones y de sus caractersticas propias o atributos, ofreciendo un contexto
para comprender el comportamiento dinmico y funcional del sistema. Por el contrario,
el Anlisis Estructurado acenta la descomposicin funcional, proporcionando un
conjunto de funciones al usuario final.
Los mtodos de Booch y OMT (Object Modeling Technique) se desarrollaron de

manera independiente entre s, reconocindose como mtodos de orientacin a objetos.
El desarrollo de UML (Unified Modeling Language) se inici en Octubre de 1994
cuando Grady Booch y Jim Rumbaugh unificaron los dos mtodos anteriores de OO.
Las motivaciones que impulsaron el desarrollo de un lenguaje de modelizacin

unificado son las siguientes:
Eliminar las diferencias entre los mtodos de OO para evitar posibles

confusiones entre los usuarios.
Unificar la semntica y notaciones simblicas definiendo estndares universales.
Mejorar los mtodos existentes aportando mayor funcionalidad a los anteriores,

y nuevas formas de resolver la problemtica ms usual o habitual.
161

7.1.2. Ciclo de desarrollo orientado a objetos

El ciclo de desarrollo OO consiste en un modelo incremental o evolutivo, donde cada
incremento se desarrolla sobre las mismas etapas de la metodologa estructurada,
utilizando para ello las tcnicas y herramientas OO. Por tanto, un proyecto de desarrollo
software OO se inicia con la identificacin de Necesidades y la Definicin de
Requisitos. A partir de este punto, se desarrolla un primer incremento basado en las
metodologas de Anlisis, Arquitectura, Diseo, Programacin, Pruebas e Implantacin.
El resto de incrementos se suelen realizar en paralelo, o en ciclo incremental en base a
los resultados que se van obteniendo en los incrementos anteriores. El nmero de
incrementos que se deben llevar a cabo para disear el sistema se deben definir en la
etapa de Identificacin de Necesidades, donde se acuerda con el cliente el nmero de
incrementos y las entregas con nueva funcionalidad que se realizarn en cada uno.
La estrategia del paradigma incrementar se puede reforzar aplicando algunos

procedimientos de desarrollo como:
Desarrollo temprano de la interfaz de usuario. Lo ms recomendable es mostrar

el escenario sobre el que va a tener que trabajar el usuario final, y as realizar los
cambios que se consideren oportunos en las primeras etapas.
Desarrollo temprano de las clases generales: es conveniente desarrollar las clases

de las que van a depender el resto como interfaces con el sistema operativo de
base de datos.
Desarrollo temprano de las clases crticas: aquellas clases que son esenciales
para el funcionamiento del sistema, y as posibilitar su reutilizacin.
Desarrollo de prototipos: consiste en el diseo de una versin parcial o bsica

del sistema. El prototipo debe ser evolutivo, de manera que el software no sea
desechable, sino que a partir de l se pueda seguir desarrollando el sistema.
162

En la prctica, las fases de anlisis de requisitos, de validacin y de aceptacin se llevan

a cabo a travs de reuniones constantes con el director del proyecto. Dichas reuniones
definen el desarrollo incremental de la codificacin del sistema, pero no del estudio y
diseo del mismo. Por este motivo, se realiza el diseo detallado del sistema de acuerdo
a la metodologa estructurada sin considerar la tecnologa de programacin que se va a
utilizar (presente documento), y por otro lado, se lleva a cabo la codificacin del sistema
de acuerdo al ciclo de vida de la metodologa de orientacin a objetos en la etapa de
programacin del desarrollo estructurado del proyecto.
7.1.3. Tcnicas OO en las fases de la metodologa

Las fases del ciclo de vida cuyas actividades tcnicas se encuentran influenciadas por
las tcnicas de OO a utilizar son las de Anlisis de Requisitos y de Programacin.
Tcnicas de orientacin a objetos en la etapa de Anlisis de Requisitos
La etapa de Anlisis de Requisitos se debe completar con tcnicas OO para realizar el

modelado del sistema. Ests tcnicas se encuentran orientadas a la recopilacin de
informacin para llegar a obtener el modelo final del sistema. Este modelado se realiza
de manera iterativa durante esta etapa, y se completar definitivamente en la etapa de
Diseo, por lo que se comienza con unos diagramas bsicos que se irn refinando a
medida que se obtiene ms informacin del sistema.
En una primera iteracin se debe obtener un conocimiento general del sistema

identificando y describiendo el proceso que el sistema debe controlar y realizar. Tras
sucesivas iteraciones deben definirse todos los elementos que constituyen el dominio de
la aplicacin. Al final de este proceso de anlisis se obtiene un modelo del sistema tanto
desde la perspectiva estructural (descripcin esttica) como desde la de comportamiento
(descripcin dinmica). Por tanto, los objetivos a cubrir en esta etapa son:
Descomponer funcionalmente las operaciones complejas en clases del dominio.
163

Organizar el sistema en partes manejables.
Determinar el comportamiento dinmico esencial de las clases cuyo

comportamiento es fundamental para la lgica de negocio y control del sistema
en su totalidad.
Diagrama de Clases: modelo esttico
Es un modelo de estructura esttica, por lo que la informacin que representa no

depende del factor tiempo. Proporciona una descripcin del problema reflejando la
realidad. Su descomposicin en otros niveles depende de la complejidad del problema y
no del sistema.
El diagrama de clases es una tcnica de modelizacin, por lo que requiere de un

componente grfico y un componente de definicin de sus atributos y de su
comportamiento. Debe describir las operaciones de las clases, as como la dependencia
entre ellas, utilizando tanto la definicin textual como el pseudocdigo. El modelo
describe:
Las precondiciones: Los requisitos que se deben cumplir desde el punto de vista
del sistema.
Las postcondiciones: Los eventos, acciones o informaciones que se pueden

garantizar despus de haber ejecutado con xito una clase.
Las excepciones: Las diferentes situaciones especiales o anmalas que pueden

tener lugar durante la ejecucin del programa, y que deben tenerse en cuenta
para garantizar la continuidad del servicio.
Los parmetros. Argumentos de entrada y salida.
164

Los algoritmos: Los mtodos utilizados por las clases.
Los resultados: Son las salidas resultantes de la ejecucin de una clase.
Este modelo determinar la jerarqua de herencia para todas las clases generadas, as
como las relaciones entre ellas.
Diagrama de Clases inicial de Control de Visitas
165

Diagrama de Clases inicial de Control de Inventario
Definicin de Casos de Uso
La definicin de los casos de uso permite mostrar la funcionalidad del sistema desde el
punto de vista del usuario. Un caso de uso es una descripcin de un conjunto de
caminos de ejecucin relacionados a travs de su comportamiento, durante la
interaccin del usuario con el sistema.
Estos caminos son el resultado de los estmulos o eventos transmitidos al sistema por
una entidad externa o actor: el usuario, el sistema u otro interfaz externo. Si el nivel de
detalle de estudio del sistema es alto, y se trata de un sistema complejo, es conveniente
utilizar diagramas de secuencia o diagramas de actividad como una forma de especificar
los casos de uso de una manara ms precisa. Sin embargo en esta fase no se suelen
utilizar los diagramas de secuencia.
166

Caso de Uso de Control de Visitas
Control de Visitas tiene un nico Caso de Usos que es el de Registrar Visita, el cual
representa la nica funcionalidad de negocio de la aplicacin de Visitas.
Las diferentes situaciones o contextos que pueden existir durante la ejecucin de la

aplicacin, se contemplarn en la definicin detallada del escenario primario del caso de
uso como extensiones del mismo.
Casos de Uso de Control de Inventario
167

Tcnicas de orientacin a objetos en la etapa de Diseo
En esta etapa se parte del modelado realizado en las fases anteriores para conseguir un
nivel de detalle que permita implantar el sistema mediante el lenguaje de programacin
elegido, en este caso Java.
Por tanto, los diagramas diseados con anterioridad sern los mismos que los utilizados
en sta pero llevando a cabo un refinamiento y un diseo detallado, incorporando a su
vez, nuevas clases necesarias para alcanzar y completar el sistema deseado. Al detallar
los modelos realizados se pretende conseguir:
Refinamiento del modelo esttico:
Definir todas las clases del sistema
Disear todos los diagramas de clases de todos los componentes
Identificar asociaciones y agregaciones
Determinar todos los atributos de las clases y sus enlaces
Determinar la jerarqua de herencia para todas las clases del sistema
Describir completamente los mtodos utilizados en las clases
Refinamiento dinmico:
Describir detalladamente la interaccin de las clases que poseen un

comportamiento dinmico
Especificar los eventos y estados de las clases con comportamiento dinmico
168

Completar el modelo de clases contemplando los cambios realizados durante

el modelado dinmico (nuevas clases, operaciones, atributos, etc.)
Por ello, los diagramas utilizados en esta etapa debern de hacer referencia a los
diagramas sobre los que se realiza el refinamiento, diseados con anterioridad.
Diagrama de Clases Detallado
Como se ha comentado con anterioridad, el diagrama de clases representa una visin

esttica del sistema. Se puede representar con varios niveles de detalle, de manera que
se aadir al diagrama inicial el resto de clases necesarias para definir el sistema
completamente.
Diagrama de Clases Detallado de Control de Visitas
169

Diagrama de Clases Detallado de Control de Inventario
Diagrama de Casos de Uso Detallado
Un caso de uso muestra la manera de interactuar con el sistema. Cuando se disea un

diagrama de este tipo, se debe considerar adems de la funcionalidad del sistema, el uso
que le va a dar el usuario final. Cada caso de uso constituye una recopilacin de
sucesos, cuyo evento inicial lo provoca una entidad externa o actor, especificando la
interaccin existente entre el sistema y el actor.
En esta etapa del proyecto se estudian detalladamente los casos de uso que se han
definido en la fase de Anlisis de Requisitos, estudiando el escenario primario de cada
uno de ellos as como las extensiones que surjan y que se tengan que tener en cuenta.
170

El diagrama debe de estar acompaado por una descripcin especfica de los casos de
uso fundamentales que constituyen la funcionalidad del sistema. La descripcin de cada
uno de ellos debe ser lo ms completa posible, a pesar de que los diagramas en esta fase
se hayan refinado respecto a su versin inicial si fuese necesario. Para cada caso de uso
debe especificarse:
Una breve descripcin del caso de uso, indicando su empleo, su modo de

funcionamiento y frecuencia de utilizacin.
Una descripcin de la secuencia de iteraciones entre el actor y el sistema,

incluyendo
las
posibles
excepciones
de
la
secuencia
esperada
del
funcionamiento del sistema.
Las precondiciones que activan el caso de uso: son los requisitos que se han de
satisfacer, desde el punto de vista del sistema, antes de iniciarse cada caso de
uso, sin tener en cuenta aquellos requisitos de los que el usuario no tenga
visibilidad.
Las postcondiciones: representan los eventos, acciones o informaciones que se

han obtenido como resultado de la ejecucin correcta del caso de uso.
Las excepciones: corresponden a los situaciones anmalas que pueden ocurrir en

cualquier momento, durante la ejecucin normal del caso de uso. En el caso de
que existan, se debe especificar cundo suceden, cmo se detectan y el
tratamiento que se debe realizar con ellas.
A continuacin, se realizan las descripciones de los escenarios primarios

correspondientes a los casos de uso que definen la funcionalidad de cada uno de los
controles de acceso. Junto a cada escenario primario, se indicarn las estructuras de
datos utilizadas, as como las posibles extensiones que pueden tener lugar durante la
ejecucin del control de acceso.
171

Descripcin del Caso de Uso de Control de Visitas
Caso de Uso: Registrar Visita
Actor: Usuario final
Precondiciones: El sistema debe haber detectado correctamente la conexin del

lector de tarjetas inteligentes, y comprobar la comunicacin entre ambos.
Trigger: Introducir una tarjeta de la universidad o activar la opcin de visita sin

tarjeta.
Escenario Primario:
1. El sistema muestra los datos de la tarjeta inteligente.
2. El sistema muestra los datos de la plantilla del personal de las ltimas vistas
realizadas por el visitante identificado.
3. El sistema muestra los datos de la plantilla del personal de todo el departamento

del IIT.
4. El usuario selecciona la fila de la persona que se quiere visitar.
5. El sistema registra correctamente la visita definida.
6. El sistema muestra un mensaje de informacin del correcto registro de la visita.
7. El sistema cambia al estado de espera de lectura de tarjeta.
172

Estructuras de datos:
Datos de la tarjeta inteligente:
Cdigo de alumno de la universidad
Nombre del alumno
Apellidos del alumno
Datos de la plantilla del personal
Identificador empleado
Nombre del empleado
Apellidos del empleado
Telfono asociado al despacho del empleado
Planta donde se encuentra el despacho del empleado
Puesto de trabajo del empleado
Extensiones:
1a. El sistema muestra el identificador asignado al visitante sin tarjeta inteligente.
1. El usuario introduce el nombre y apellidos del visitante.
2. El sistema salta al punto 3
173

5a. El sistema no registra correctamente la visita.
1. El sistema muestra un mensaje informando que ha ocurrido un error y no se

ha registrado correctamente la visita.
2. El sistema reinicia el servicio de lectura pasando al estado de espera de

lectura.
7a. El usuario selecciona opcin de salir de la aplicacin.
1. El sistema muestra dilogo de confirmacin
2. El usuario confirma la finalizacin de la aplicacin.
3. El sistema pasa a permanecer al estado de inactividad.
7a2. El usuario no confirma la finalizacin de la aplicacin.
1. El sistema pasa al estado de espera de lectura.
Descripcin de los Casos de Uso de Control de Inventario
Caso de Uso: Registrar Prstamo Sin Reserva
Actor Primario: Usuario
Precondiciones: El lector RFID debe estar conectado al ordenador, y reconocido

por el sistema.
Trigger: El usuario pulsa el botn de Registrar Prstamo para realizar la entrega

en ese momento del recurso
174

Escenario Primario:
1. El usuario rellena todos los campos que definen los datos del registro
instantneo.
2. El usuario confirma los datos del registro instantneo.
3. El sistema comprueba que el usuario ha introducido correctamente los datos del

registro instantneo.
4. El sistema registra correctamente el movimiento.
5. El sistema actualiza correctamente el estado del recurso gestionado.
6. El sistema muestra un mensaje informando que se ha realizado correctamente

los registros asociados al movimiento gestionado.
7. El usuario pulsa el botn de nueva lectura.
8. El sistema salta al estado de espera de lectura.
Datos del registro instantneo:
Duracin en horas del prstamo
Timestamp del da de entrega del recurso
Da de devolucin del recurso
175

Nombre y apellidos del usuario del recurso
Comentario personal del prstamo del recurso
Excepciones:
2a. El usuario no confirma los datos del registro instantneo.
2a1. El sistema pasa al estado de espera de confirmacin de operacin.
3a. El sistema comprueba que los datos del registro instantneo introducidos no son
correctos
.
3a1. El sistema muestra un mensaje informado el error detectado.
3a2. El sistema salta al punto 1.
4a. El sistema no registra correctamente el movimiento.
5a. El sistema actualiza correctamente el estado del recurso gestionado.
7a. El usuario pulsa el botn de finalizar la aplicacin.
176

Caso de Uso: Registrar Prstamo Con Reserva
Actor Primario: Usuario final
Precondiciones: El lector RFID est conectado al sistema, y existe comunicacin

entre ambos.
Trigger: El usuario pulsa el botn de Registrar Prstamo para realizar la entrega

en ese momento del recurso.
Escenario Primario:
1. El sistema muestra los datos del prstamo que se est realizando.
2. El usuario pulsa el botn de Aceptar confirmando el movimiento.
3. El sistema actualiza correctamente el estado del recurso gestionado.
4. El sistema muestra un mensaje informando que se ha realizado correctamente

los registros asociados al movimiento gestionado.
5. El usuario pulsa el botn de nueva lectura.
6. El sistema salta al estado de espera de lectura.
Datos del prstamo:
Duracin en horas del prstamo
177

Timestamp del da de entrega del recurso
Da de devolucin del recurso
Nombre y apellidos del usuario del recurso
Comentario personal del prstamo del recurso
Excepciones:
2a. El usuario no confirma el movimiento.
3a. El sistema actualiza correctamente el estado del recurso gestionado.
5a. El usuario pulsa el botn de finalizar la aplicacin.
Caso de Uso: Registrar Devolucin
Actor Primario: Usuario final.
Precondiciones: El lector RFID debe estar conectado al ordenador donde se

ejecuta la aplicacin, y se garantiza que la comunicacin entre ambos es
correcta.
178

Trigger: El usuario pulsa el botn de Registrar Devolucin cuando se entrega el

recurso al departamento antes de la fecha de devolucin registrada.
Escenario Primario:
1. El sistema comprueba que la fecha de devolucin se corresponde con la fecha

actual.
2. El sistema actualiza correctamente el estado del recurso devuelto.
3. El sistema muestra un mensaje informando del correcto registro de la

devolucin.
4. El usuario pulsa el botn de nueva lectura
Excepciones:
1a. El sistema comprueba que la fecha de devolucin es posterior a la fecha actual.
1a1. El sistema actualiza la reserva asociada.
1a2. El sistema pasa al estado que representa el punto 2.
2a. El sistema no actualiza correctamente el estado de recurso devuelto.
2a1. El sistema muestra el mensaje de error.
2a2. El sistema pasa al estado de confirmacin de operacin.
4a. El usuario pulsa el botn de Salir para finalizar la aplicacin
179

1a1a. El sistema no actualiza con xito la reserva asociada
1a1a1. El sistema muestra el mensaje de error.
1a1a2. El sistema pasa al estado de confirmacin de operacin.
7.2. Manual de Usuario

La estructura que se ha definido para realizar el Manual de Usuario es la siguiente:
1. Introduccin
1.1. Objeto de la aplicacin
1.2. mbito de la aplicacin
1.3. Documentacin relacionada
2. Descripcin general del sistema

2.1. Entorno de trabajo
2.2. Perfiles de usuario
2.3. Funcionamiento del sistema
2.4. Sistemas relacionados
2.5. Ayudas
3. Funcionalidades del sistema

3.1. Funcin de negocio 1
3.1.1. Descripcin de la funcionalidad
3.1.2. Perfiles de los usuarios autorizados
3.1.3. Operativa de la funcin
3.2. Funcin de negocio 2
3.2.1. Descripcin de la funcionalidad
3.2.2. Perfiles de los usuarios autorizados
3.2.3. Operativa de la funcin
180

En el epgrafe 1 se introduce la finalidad del sistema, el mbito o funciones de negocio

que se realizan, y las referencias a otros documentos que pueden ayudar al usuario a
entender y manipular el sistema, como procedimientos de actuacin, normas y
estndares referentes a las funciones recogidas por la aplicacin, aunque debido a la
sencillez que caracteriza a la aplicacin no se considera que sea necesario desarrollar
este ltimo punto.
En el segundo epgrafe se realiza una exposicin general del sistema, describiendo el

entorno de trabajo donde se ejecuta o accede a la aplicacin, haciendo referencia a los
elementos hardware y software ms relevantes. Tambin se especifican los perfiles de
usuario asignando a cada uno de ellos las operaciones que pueden ejecutar.
Dependiendo del tipo de aplicacin, suelen aparecer diferentes tipos de usuario, aunque
el Sistema Control de Accesos slo tiene un nico usuario final que desempea el papel
de administrador y de usuario al mismo tiempo.
Si desde el puesto cliente se pueden acceder a diferentes aplicaciones, es necesario

llevar un control de dnde y cmo se ubican, as como la forma a partir de la cual se
puede lanzar su ejecucin. Por ltimo, se contempla el sistema de ayudas utilizado por
la aplicacin, indicando si es a nivel de ventana, de campo de informacin o existe una
funcin especfica de ayudas por donde puede navegar el usuario.
En el epgrafe 3 se describen las distintas funciones de negocio que pueden realizar

dentro de la aplicacin, describiendo el alcance de la funcionalidad de cada una de ellas,
los perfiles de usuario necesarios para ejecutaras, y la operativo o procedimiento de
actuacin. Este procedimiento se describe realizando un recorrido por los dilogos de la
funcin.
En el epgrafe 4 se pueden incluir una serie de anexos que ayuden al usuario a

comprender y a manejar la aplicacin.
181

As, un glosario de los trminos utilizados en las ventanas y mensajes de la aplicacin,

as como de los acrnimos utilizados, ser de gran utilidad para aquellos usuarios que
por diversos motivos no hayan podido familiarizarse con la operativa.
Tambin es recomendable recoger los problemas e incidencias que se pueden presentar

con mayor frecuencia durante la actividad del sistema, y as describir al usuario la forma
de resolverlos. Dado que anteriormente se ha expuesto el modo de operacin de cada
funcin de negocio de forma individual, no ser necesario incluir como anexo la
descripcin detallada del interfaz de la aplicacin como un epgrafe por separado.
7.2.1. Manual de Usuario de Control de Visita

Se adjunta como Anexo 1
7.2.2. Manual de Usuario de Control de Inventario

Se adjunta como Anexo 2
182

8. Pruebas
183

Tras desarrollar y finalizar las aplicaciones correspondientes a los controles de acceso,

deben realizarse una serie de pruebas para garantizar el correcto funcionamiento de las
mismas, y verificar que se cumplen con los requisitos funcionales determinados en las
etapas de iniciales del proyecto.
As, el objetivo principal de esta etapa es el de someter al sistema desarrollado y a sus

componentes, a una serie de comprobaciones encaminadas a garantizar un nivel de
fiabilidad aceptable. Esta fase es crtica, y debe realizarse con la misma dedicacin y
planificacin con las que se ha desarrollado el resto de proyecto.
Si los resultados son satisfactorios, se proceder a la aceptacin de los mismos y a la

implantacin del sistema en el entorno para el cual ha sido diseado, pero en caso
contrario se tendrn que resolver las anomalas encontradas suponiendo un retraso en la
finalizacin del proyecto ya que se ha de revisar el diseo y la codificacin realizada.
El entorno de pruebas suele configurarse y adaptarse antes de realizar cualquier tipo de

pruebas con el objetivo de simular el entorno final de produccin. Para ello, se utiliza un
ordenador personal que representar la herramienta de trabajo del usuario final del
sistema, que se encontrar conectado a los lectores y donde residirn las aplicaciones
correspondientes a los controles de acceso.
Por otra parte, suelen utilizarse volmenes representativos de informacin para llevar a
cabo cada una de las pruebas, ya que los volmenes de datos reales que va a manejar el
sistema representan un alto grado de ocupacin del servidor donde residen. En cuanto a
la informacin personal a utilizar para realizar las pruebas se correspondern con datos
meramente intuitivos de manera que permitan emular la gestin de los controles de
acceso.
El equipo de pruebas en este caso lo constituye el alumno junto con el director, ya que
ste ltimo podr realizar un mejor control de calidad del sistema final.
184

Durante las etapas de Programacin, Pruebas del Sistema e Implantacin se ejecutan

diferentes pruebas parciales sobre el sistema final, cada una de ellas con objetivos
diversos, aunque en funcin del tipo de software diseado se le suele someter a unas
pruebas u otras.
En la etapa de Pruebas del Sistema se ejecuta el bloque de pruebas ms completo con el

objetivo de comprobar la funcionalidad del sistema y el rendimiento exigido en los
requisitos.
Para ello, previamente se habrn llevado a cabo las pruebas unitarias de cada
componente, y posteriormente se realizarn las pruebas de carga y de rendimiento sobre
el entorno real de produccin. Los tipos de pruebas que se van a realizar son los
siguientes:
Pruebas de Encadenamiento
Comprobado el correcto funcionamiento del software, este tipo de pruebas permiten

garantizar la adecuada comunicacin entre todos los componentes que intervienen en la
gestin de un control de acceso. En este caso se corresponde con la comunicacin
existente entre los lectores y el sistema.
Pruebas de Explotabilidad
Estas pruebas tienen el objetivo de determinar la facilidad que el sistema ofrece para ser
utilizado e explotado en el entorno de produccin. Para ello, se ejecutan las aplicaciones
correspondientes a los controles de acceso siguiendo las instrucciones recogidas en el
Manual de Usuario sobre las entradas, salidas, informes de errores y controles.
185

Pruebas de Recuperacin
En esta caso las pruebas de recuperacin se encuentran localizadas en las operaciones

que se realizan contra la bases de datos, de manera que se tienen en cuenta los
comandos de Rollback y Commit para garantizar la coherencia de las bases de datos
utilizadas en la gestin que realizan cada una de las aplicaciones.
Pruebas de Aceptacin del Usuario
Estas pruebas junto con las de Usabilidad son realizadas por el usuario en su entorno de
trabajo. La finalidad de esta prueba es la de validar el sistema desde el punto de vista
funcional y operativo. Generalmente se utiliza el Manual de Usuario para seguir la
navegacin del sistema en cada una de las funciones de negocio. Esta aceptacin
nicamente certifica la aceptacin del usuario con las aplicaciones desarrolladas, hecho
que supone la implantacin del sistema en el entorno real de produccin. En este
entorno se ejecutarn ms pruebas sobre el sistema comprobando su funcionalidad en el
entorno final de produccin, que determinar la conformidad del usuario con el software
implantado. El usuario ejecutar esta fase de pruebas bajo la supervisin y gua del
autor del proyecto.
Pruebas de Usabilidad
Normalmente las pruebas de aceptacin del usuario se complementan con las pruebas de
usabilidad cuya finalidad es la de verificar la facilidad de uso del sistema que debe
manejar. Estas pruebas se realizarn en el IIT en el entorno de trabajo del usuario final.
Cuando se habla de facilidad de uso se est haciendo referencia al diseo de la interfaz y

al Manual de Usuario. Durante estas pruebas se pude aprovechar para formar al usuario
sobre la utilizacin del sistema, de forma que resulta mucho ms sencillo y claro el
aprendizaje, al realizarse directamente con la persona que ha diseado el sistema.
186

Al preparar el entorno de pruebas para emular el contexto de explotacin del sistema, se

han instalado y configurado tanto el software base como el de aplicacin de acuerdo a
los componentes utilizados. A partir de ello, se realizar el Manual de Instalacin y
Configuracin necesario para configurar el entorno de produccin. El manual
correspondiente al sistema se adjunta como Anexo en la presente documentacin.
Un aspecto importante que se ha de tener en cuenta sobre la tecnologa RFID es que

dependiendo de la posicin con que se ubique la tarjeta que se desea leer sobre el lector,
puede que la operacin no se realice correctamente porque no se estabiliza la
comunicacin entre el lector y el TAG para su lectura. En este caso el sistema recibe el
error generado por el lector y se lo comunica al usuario. Este error de lectura se debe a
que el lector detecta la tarjeta pero el nivel de la seal es demasiado bajo, de forma que
al no ser capaz de realizar su identificacin lo considera un problema generando un
mensaje de error. Este aspecto funcional se describe detalladamente en el Manual de
Usuario de Control de Inventario.
187

9. Implantacin
188

Tras probar la integridad del software del sistema y especificar su instalacin y

configuracin, se ha llevado a cabo la instalacin del sistema en el centro de produccin
donde se va a llevar a cabo su explotacin: se han instalado los drivers y las
aplicaciones correspondientes a los dos controles de acceso en la estacin de trabajo del
usuario final del departamento, configurando adecuadamente los orgenes de acceso a
las bases de datos necesarias.
Instalado el software sin presentar problemas se han realizado dos pruebas adicionales
que se suelen ejecutar en esta etapa del proyecto, y que consolidan la finalizacin
correcta del mismo. Una de ellas tiene como objetivo certificar el correcto
funcionamiento de la aplicacin utilizando los recursos reales del entorno de
explotacin. La otra prueba necesaria es la aceptacin final del usuario, que desde su
puesto de trabajo, y bajo los diferentes perfiles con los que puede utilizar el sistema,
certifica el correcto funcionamiento del sistema.
Superadas ambas pruebas el sistema se encuentra finalmente implantado en el entorno

de produccin garantizando su correcto funcionamiento.
189

10.Conclusiones
190

El Sistema Control de Accesos proporciona diversas ventajas a partir de la ejecucin

conjunta de las dos aplicaciones que lo constituyen, gracias a las tecnologas de control
de accesos empleadas para llevar a cabo su implantacin, las cuales estn basadas en la
utilizacin de tarjetas inteligentes y de radiofrecuencia.
Por un lado, se consigue informatizar el registro de las entradas y salidas del centro del
IIT gracias a la implantacin del subsistema de Control de Visitas. Este sistema a su vez
permite facilitar y agilizar el trabajo realizado por el usuario final, y disminuir en gran
medida el tiempo de espera que afecta considerablemente a la persona que realiza la
visita.
Respecto a la tecnologa RFID los puntos positivos son diversos:
Permite llevar a cabo un monitoreo detallado y automtico de los movimientos

que tienen lugar en el departamento, posibilitando la identificacin rpida del
recurso. Si se dispone de un almacn con un nmero considerable de recursos,
por ejemplo el de una biblioteca, esta tecnologa permitira identificar el estado
de los libros.
Proporciona la posibilidad de administrar inventarios tan efectivamente que

muchas de las tareas manuales que se han realizado hasta el momento pueden
ser eliminadas, los procesos o funciones de negocio pueden ser acelerados y los
errores de despacho reducidos. Por tanto, se mejora considerablemente la gestin
de inventarios.
Permite gestionar el inventario garantizando una organizacin del mismo,

disponer de la traza e historia de los productos, prevenir robos, evitar prdidas
de recursos por desconocimiento de su ubicacin y acelerar las consultas de
inventario.
191

Los cdigos de barras (UPC) seran una alternativa a la tecnologa RFID pero
requieren que se escanee uno por uno los artculos y que la etiqueta sea visible
para poder realizar adecuadamente su lectura, sin embargo los lectores de RFID
pueden escanear simultneamente varios artculos tanto tengan el TAG visible
directamente como que no (lecturas anticolisin), siempre que se cumpla con las
distancias mnimas. Adems, el cdigo de barras tpicamente suele informar de
qu artculo se trata, por ejemplo Cdigos UPC, mientras que la tecnologa
RFID maneja nmeros de identificacin ms largos y permite identificar cada
artculo individualmente y recoger informacin adicional asociada al mismo:
nmero de serie, lote, etc
192

11. Glosario de
Trminos
193

Anlisis: Estudio y modelizacin de una funcin de negocio para ser mecanizada

mediante un sistema de ordenador.
Anlisis de Requisitos: Primera etapa del ciclo de vida del desarrollo de un sistema, una
vez identificadas las necesidades generales.
Atributo: Dato elemental que expresa las caractersticas o propiedades de una entidad o
una relacin.
Burbuja: Proceso representado en un diagrama de flujo de datos mediante un crculo.
Cardinalidad: En una relacin mide la mxima y mnima participacin de las entidades

cuando se observa el conjunto de las ocurrencias de cada una de ellas.
CASE: Computer Arded Software Engineering. Ingeniera del software asistido por
ordenador.
Ciclo de vida: Conjunto ordenado de las etapas por las que transcurre el desarrollo de
un sistema informtico.
Control de Calidad: Actividades encaminadas a detectar y corregir cualquier desviacin

durante el desarrollo del sistema.
Cuaderno de Carga: Especificacin del diseo de un programa.
DER: Diagrama de Entidad-Relacin.
Diagrama de Casos de Uso: La definicin de los casos de uso permite expresar las
facilidades del sistema desde el punto de vista del usuario. Un caso de uso es una
descripcin de un conjunto de caminos de ejecucin relacionados por su
comportamiento durante la interaccin del usuario con el sistema.
194

Diagrama de Clases: Es un modelo de la estructura esttica que proporciona una

descripcin del problema reflejando el mundo real y cmo lo ve el cliente. Su
descomposicin en otros niveles depende de la complejidad del problema y no del
sistema. Debe mostrar las operaciones de las clases as como la dependencia entre ellas,
utilizando tanto la definicin textual como el pseudocdigo.
Diagrama Conceptual: Es el primer nivel en que explosiona el proceso que representa

el sistema en estudio bajo un modelo de procesos. Muestra los procesos esenciales del
sistema.
Diagrama de Contexto: Primer nivel de un modelo de procesos, donde se representan

las entidades externas al sistema y los flujos principales de entrada y salida.
Diagrama del Sistema: Se utiliza para mostrar visualmente la composicin de las

opciones de navegacin por el sistema, de modo que a partir de una ventana inicial se
observen los diferentes dilogos de funciones.
Diagrama de Flujo de Datos (DFD): Representacin grfica de un modelo de procesos

donde aparecen los flujos de datos y sus transformaciones a lo largo del sistema.
Diagrama de Presentacin: Diagrama de formato libre utilizado para mostrar algn

concepto o alguna idea, dentro de las especificaciones de anlisis y de diseo del
sistema.
Diagrama Entidad-Relacin (DER): Representacin grfica de un modelo de datos

donde aparecen las entidades de datos y sus relaciones.
Diccionario de Datos: Conjunto de entradas de datos que constituyen los nombres y

descripciones de todos los elementos utilizados en la especificacin del software del
sistema.
195

Documento de Conceptos del Sistema: Especificacin de las necesidades del cliente,

donde se recogen los objetivos del sistema en estudio.
EDT: Estructura de divisin del trabajo. Es una descomposicin del proyecto en un

conjunto de tareas manejables.
Entidad: Concepto dentro de la organizacin o del negocio que es de gran inters para
el estudio del sistema.
Especificacin: Descripcin detallada del elemento software objeto de anlisis, diseo

o programacin.
Flujo de Datos: Rango de informacin que al entrar en un proceso sufre una

transformacin dando lugar a otra porcin de informacin diferente.
Gestin de Configuracin: Componente de la ingeniera del software que estudia el

control de las versiones de los componentes software y la gestin de cambios a lo largo
del desarrollo.
IIT: Instituto de Investigacin Tecnolgico
Interrogador: Lector. Son dispositivos que activan y / o dan potencia a una etiqueta
electrnica y recuperan la informacin contenida en la misma.
Metodologa: Mtodo sistemtico de abordar la resolucin de un problema, o un

conjunto de mtodos y procedimientos que describen el proceso mediante el cual se
debe abordar las etapas del ciclo de vida del desarrollo software.
Middleware: Es la capa de software que realiza las operaciones de gestin y control de

las comunicaciones entre el cliente y el servidor, o entre un emisor y receptor.
196

Modelo: Representacin del sistema o de algn elemento constituyente del mismo. Los
modelos estn formados por tres elementos: componente grfico, componente de
definicin y componente de especificacin.
Modelo Conceptual de Datos: Representa el conjunto de familias de datos o de

entidades, sus posibles relaciones de acuerdo a las reglas de negocio, y sus
caractersticas o atributos.
Modelo Fsico del Nuevo Sistema: Representa las funciones de negocio del nuevo
sistema y cmo van a ser implantadas sobre una plataforma tecnolgica hardware,
software y de comunicaciones.
Modelo Lgico del Nuevo Sistema: Representa las funciones lgicas en que se
estructura el sistema, determinado qu debe hacer y no cmo se debe implementar sobre
la plataforma tecnolgica.
PFC: Proyecto Fin de Carrera
PSCA: Proyecto Sistema Control de Accesos
Repositorio: Sistema de almacenamiento de una herramienta CASE donde se recogen

las especificaciones de los componentes de acuerdo con el modelo de datos o metadata
de dicho almacn.
RFID (Identificacin por Radio frecuencia): Es un mtodo para identificar artculos

utilizando ondas de radio. La gran ventaja en comparacin con la tecnologa de cdigos
de barras es que el lser debe ver el cdigo para efectuar la lectura correspondiente. Las
ondas de radio no necesitan tener una lnea directa de visin y pueden pasar a travs de
diversos materiales tales como el cartn o el plstico.
TAG: Tarjeta o etiqueta RFID
197

UML: Unified Modeling Language. Metodologa de anlisis y diseo orientado a

objetos.
UPC (Cdigo Universal de producto): Sistema de numeracin y codificacin en barras

de Norteamrica desarrollado a fines de la dcada de sesenta y principios del setenta por
la industria alimenticia de los EUA que se utiliza para la identificacin de productos de
artculos de consumo que son escaneados en un punto de venta minorista.
UPCO: Universidad Pontifica Comillas
198

12. Bibliografa
199

Pginas Web:
RFID Journal:
www.rfidjournal.com
RFID Magazine:
www.rfid-magazine.com
Pgina de RFID de Texas Instruments:

www.ti.com/tiris/default.htm
Pgina de Randall Jackson:

http://rfid.home.att.net/
Enlaces a Webs de fabricantes de tecnologas RFID:

http://members.surfbest.net/eaglesnest/rfidweb.htm
Manual RFID:
http://www.rfid-handbook.de/links/index.html
Sistemas identificacin por radiofrecuencia de Philips:

http://www.semiconductors.philips.com/products/identification/index.html
Sistema de Control de Accesos Libert:

http://www.alfi.it/es/liberte.html
Estndares aprobados RFID:

http://www.rfid-handbook.de/rfid/standardization.html
200

Chips RFID de Temic/Atmel:

http://www.atmel.com/atmel/products/prod26.htm
Algunas aplicaciones interesantes:

http://www.capta.com.mx/solucion/ems_rf_id_tags.htm
Artculos RFID y API de Java

www.sun.com
Software de tarjetas inteligentes

www.opencard.org
Documentos:
Standard Card IC MF1 IC S50
Manuales de Circontrol:
Programacin
Usuario
Protocolo de Comunicaciones
201

A nexo 1
Manual de Usuario
Control de Visitas
202

Captulo
Pgina
1. Introduccin
204
204
205
205
3. Funcionamiento
206
3.1. Gestin de visitas con carnet de alumno
207
3.2. Gestin de visitas sin carnet de alumno
208
3.3. Opcin Consulta
209
4. Ayudas
210
4.1. Error al intentar acceder a la tarjeta
210
4.2. No se ha encontrado ningn lector
210
203

El presente documento se corresponde con el Manual de Usuario de la aplicacin de

Control de Visitas, que recoge una descripcin del funcionamiento del sistema y del
entorno de explotacin, as como un apartado de ayuda para afrontar los problemas ms
usuales que pueden surgir.
1. Introduccin
En este primer apartado del manual se pretende realizar una breve descripcin del
subsistema de Control de Visitas.

El principal objetivo de la aplicacin es el de facilitar la gestin de las visitas que se
reciben en el IIT. Para ello, la aplicacin realiza: la identificacin de la persona que
realiza la visita, la localizacin de la persona visitada, y el proceso de registro de la
visita.

La funcionalidad bsica de la aplicacin consiste en permanecer a la espera de la lectura
de una tarjeta. Cuando el usuario introduce el carnet de un alumno de la Universidad, el
sistema recibir los datos ledos de la tarjeta y los mostrar por pantalla.
Seguidamente, el usuario gestiona la visita determinando a qu persona se desea visitar,

y confirmando el registro final de la vista.
204


A continuacin se realiza una exposicin general del sistema, explicando el entorno de
trabajo donde se ejecuta la aplicacin, describindose los elementos hardware y
software ms importantes.

La aplicacin final reside en el ordenador personal del usuario, ubicado en la entrada del
edificio del departamento.
La aplicacin se comunica de manera constante, siempre que permanezca activa, con un

lector de tarjetas inteligentes que se encuentra conectado al mismo ordenador a travs
de un puerto USB.

universidad, as como de afrontar y comunicar cualquier problema u ocurrencia que
tenga lugar.
El perfil correspondiente al usuario final de la aplicacin no presenta restriccin alguno
a la hora de ejecutarla o de gestionar los movimientos que tengan lugar.
205

3. Funcionamiento del sistema
El interfaz de la aplicacin es el que se adjunta a continuacin:
El sistema se encuentra en espera de gestionar una visita, ya sea con tarjeta inteligente o
no. Las funciones que se proporcionan cuando la aplicacin permanece en dicho estado
son las de salir, consulta y ayuda:
206

3.1. Gestin de visitas con carnet de alumno

La lectura de una tarjeta supone la transmisin de los datos ledos de la misma hacia el
sistema. Cuando este recibe los datos del visitante los muestra por pantalla,
proporcionando al mismo tiempo la informacin del personal al cual ha visitado en las
ltimas ocasiones (si procede) y de toda la plantilla del departamento. Si la persona
identificada ha realizado visitas con anterioridad, es muy probable que la prxima visita
que protagonice sea a la misma persona.
207

Proporcionados los datos iniciales, el usuario debe confirmar la persona que es visitada
para definir finalmente la visita gestionada. Para ello es necesario realizar la seleccin
de la lista de visitas recientes, o bien, de la de todo el personal.
3.2. Gestin de visitas sin carnet de alumno

La aplicacin proporciona la posibilidad de gestionar visitas de personas que por
cualquier motivo no disponen del carnet de alumno de la universidad. En esta situacin
el usuario de la aplicacin debe activar el checkbox de Introducir los datos a mano,
para escribir el nombre y los apellidos de la persona que desea realizar la visita. Cada
vez que se reciba una persona sin carnet se le asignar un identificador unvoco para
poder registrarlo en la base de datos.
Tras la seleccin, el subsistema muestra los datos de toda la plantilla del personal del
departamento con el objetivo de que se indique quien es el visitado.
208

Determinados todos los datos que constituyen una visita, se debe confirmar su registro
pulsando el botn de Registrar Visita.
3.3. Opcin Consulta

El servicio de Consulta permite afrontar informes de las ltimas
visitas realizadas en el departamento.
Mediante esta opcin se abre la aplicacin Excel con un listado de las ltimas visitas
realizadas. Esta informacin procede de los movimientos gestionados en la
correspondiente base de datos del servidor del departamento.
209

4. Ayudas
La aplicacin proporciona una opcin de ayuda destinada a facilitar la gestin de una

visita ante una posible duda. Dicha ayuda se corresponde con un submen en el que
mencionan los diferentes pasos que hay que llevar a cabo para realizar el registro de una
visita.
Adicionalmente, en este punto se recogen los posibles errores que pueden surgir durante
la ejecucin de la aplicacin.
4.1. Error al intentar acceder a la tarjeta

Si se introduce una tarjeta distinta a la de la UPCO o una tarjeta daada, la aplicacin
nos mostrar un mensaje de error.
Si esto ocurre, se deber extraer la tarjeta incorrecta, hacer clic sobre aceptar y
asegurarse de introducir una tarjeta de la universidad.
4.2. No se he encontrado ningn lector

Esto se problema puede deberse a dos motivos: que no haya ningn lector de Tarjetas
Inteligentes instalado correctamente, o que el acceso al lector est bloqueado por otra
aplicacin (por ejemplo no se ha iniciado el servicio de Tarjetas Inteligentes de su
Sistema Operativo).
210

Para resolver el problema se deben tener en cuenta los siguientes puntos:
1. Compruebe que tenga instalado correctamente un lector compatible con el estndar

PCSC10, y con los drivers actualizados.
2. Compruebe que el servicio de Tarjetas Inteligentes est iniciado.
211

A nexo 2
Manual de Usuario
212

Captulo
Pgina
1. Introduccin
215
216
216
216
217
3. Funcionamiento
218
3.1. Gestin de prstamos
220
3.2. Gestin de devoluciones
223
3.3. Botn de Nueva Lectura
226
3.4. Escritura en una tarjeta RFID
226
4. Ayudas
228
4.1. Error al identificar el recurso, aproxime de nuevo la tarjeta
228
4.2. Error de conexin con la base de datos
228
4.3. No se han encontrado recursos registrados
229
4.4. Error en el acceso a la base de datos. Se finaliza la aplicacin
229
4.5. La fecha de devolucin es errnea. Debe ser anterior a XXXX-XX-XX
230
4.6. Error de escritura RFID. Aproxime de nuevo la tarjeta RFID al
230
lector
4.7. El campo Informacin adicional del prstamo debe ser ms
231
corto
4.8. Error al actualizar los recursos de la devolucin. Intntelo de
231
nuevo
4.9. Error al registrar la devolucin
231
213

Captulo
5. Ubicacin de las tarjetas para la lectura y escritura RFID
Pgina
233
214

El presente documento se corresponde con el Manual de Usuario de la aplicacin de

Control de Visitas, que recoge una descripcin del funcionamiento del sistema y del
entorno de explotacin, as como un apartado de ayuda para afrontar los problemas ms
usuales que pueden surgir.
1. Introduccin
En este primer apartado del manual se pretende realizar una breve descripcin del
subsistema de Control de Inventario.

El principal objetivo de Control de Inventario es el de permitir llevar a cabo un
seguimiento de los ordenadores porttiles y de otros recursos de uso comn que
proporciona el IIT a sus empleados. Dicho seguimiento consiste bsicamente en anotar
las fechas y horas de los prstamos y devoluciones de cada equipo.

El presente control de inventario se realiza a partir de la gestin de las entradas y salidas
del material informtico suministrado por el departamento, as como de la identificacin
y el registro de los recursos prestados, y de las personas que deseen utilizarlos.
El tratamiento de las reservas de los recursos se realiza a partir del almacenamiento de

las mismas en la correspondiente base de datos del servidor del departamento, registro
que se lleva a cabo cuando un determinado usuario confirma la reserva a travs de la
aplicacin de Reservas Online ( que no forma parte del presente proyecto).
215


A continuacin se realiza una exposicin general del sistema, explicando el entorno de
trabajo donde se ejecuta la aplicacin, describindose los elementos hardware y
software ms importantes necesarios para llevar a cabo la ejecucin de la aplicacin del
control de acceso.

La aplicacin final reside en el ordenador personal del usuario, ubicado en la entrada del
edificio del departamento.
El subsistema se comunica con el lector RFID siempre que se encuentre en espera de

identificar un recurso o de registrar alguna incidencia referente al estado del recurso en
el TAG RFID. Por tanto, la comunicacin entre ambas entidades no es permanente, sino
que se establece slo cuando sea necesario.
El lector se encuentra conectado al mismo ordenador donde reside la aplicacin a travs

de un puerto USB.

universidad, as como de afrontar y comunicar cualquier problema o incidencia que
tenga lugar. El perfil correspondiente al usuario final de la aplicacin no presenta
restriccin alguna a la hora de ejecutarla o de gestionar los movimientos asociados a los
recursos, debido a que el tratamiento de los datos los valida internamente la aplicacin y
no hay riesgo alguno ante posibles manipulaciones de los prstamos o devoluciones que
se realicen.
216


El presente control de inventario se encuentra integrado con una aplicacin destinada a
registrar las reservas de los recursos del departamento. La aplicacin de recursos se
ejecuta en un entorno Web, donde los usuarios acceden a travs de la red de la
universidad para informarse de la disponibilidad de los recursos y confirmar sus propias
reservas. La aplicacin desarrollada comparte la base de datos con el sistemas de
reservas.
217

3. Funcionamiento del sistema

Al arrancar la aplicacin se mostrar la disponibilidad actual de todos los recursos que
constituyen el inmovilizado prestable del departamento:
La disponibilidad de los recursos se representa mediante un checkbox, de manera que si

se encuentra activo significa que el recurso est disponible. Cuando un recurso sea
prestado se indicar en la tabla de recursos el nombre del usuario que lo tiene.
El sistema permanecer en estado de espera hasta que el lector le comunique que ha

identificado un tarjeta, momento en el que se selecciona en la tabla el recurso
correspondiente.
En este primer paso de identificacin, se mostrar un mensaje informativo si el recurso

tiene asociada alguna incidencia que haya que recordar. Dicha informacin puede ser
referente al prstamo, como por ejemplo que no se ha llevado el ratn o un disco, o bien
puede estar relacionada con algn defecto del propio recurso: por ejemplo que el cable
del cargador est roto.
218

Otro elemento importante del interfaz de usuario es el que indica el tipo de movimiento
que se puede realizar sobre un recurso, Prestar si se trata de la entrega de un recurso,
o Devolver:
Como se puede observar en la imagen anterior, tras la identificacin del recurso y del
tipo de movimiento se muestra la reserva asociada que se va a gestionar. En el ejemplo
que se adjunta como imagen, se ha ledo el TAG del Mvil 1, de forma que se ha
consultado en la base de datos sus posibles reservas, y se ha obtenido que la reserva ms
prxima a la fecha actual tiene como usuario a Pedro Silva, y el prstamo ha de
realizarse el 03/05/2007.
219

Si el recurso, por el contrario, no tiene reservas asociadas se mostrar un mensaje

notificndolo:
3.1. Gestin de prstamos

Se pueden gestionar dos tipos de prstamos: aquellos que tienen reservas asociadas y los
que no. stos ltimos se corresponden con situaciones en los que no hay reservas para
los prximos das, o en los que hay una reserva confirmada pero no para el da actual.
Prstamo con reserva
Se corresponde con la situacin normal en que una persona ha reservado con antelacin
y se dispone a recoger el equipo. Para confirmar la entrega de un recurso se deber
pulsar el botn de Registrar Prstamo:
220

Cuando el prstamo que se ha de gestionar tiene como da de inicio de la reserva el

actual o uno anterior, la aplicacin proporciona una ventana con todos los datos que
definen la entrega del recurso, sin permitir posibles cambios, motivo por el cual
aparecen los campos deshabilitados. La ventana de dilogo que se muestra se
corresponde con la que se muestra a continuacin:
El campo correspondiente a Informacin adicional del prstamo est destinado a

recoger algn tipo de incidencia relacionada con el recurso. Esta funcionalidad se
explicar en el punto 3.4 de este manual.
Prstamo sin reserva
Esta situacin se denomina tambin Reserva instantnea. Como se ha comentado con

anterioridad, el prstamo sin reserva tiene lugar cuando no hay reservas asociadas o
cuando la reserva registrada no tiene como fecha de prstamo la actual.
221

Como en el caso anterior, despus de mostrar el mensaje informativo, si no hay

reservas, o la reserva correspondiente, en el caso de que si exista alguna, el usuario debe
confirmar la gestin del prstamo pulsando el botn de Registrar Prstamo:
Seguidamente, el sistema mostrar una ventana de dilogo cuyo contenido depender de

si hay o no alguna reserva del recurso.
Si no existen reservas asociadas al recurso, la ventana permitir determinar la fecha y

hora de devolucin que se desee:
Igualmente, el usuario de la aplicacin deber indicar a quin se entrega el recurso, un

comentario que justifique el prstamo, y la informacin del estado del prstamo, campo
que se explica en el apartado 3.4.
222

Cuando la entrega del recurso se encuentra condicionada por una reserva que est ya
confirmada, el sistema mostrar una ventana de dilogo que mostrar por defecto la
fecha y hora de devolucin ms tarda con las que se permite llevar a cabo la entrega del
recurso. Esta restriccin se validar cuando el usuario confirme el prstamo despus de
que haya introducido el resto de datos. La ventana correspondiente a esta situacin es la
que se adjunta a continuacin:
3.2. Gestin de devoluciones

El movimiento correspondiente a una devolucin se realiza de manera similar al
prstamo de un recurso.
Despus que el sistema identifique el recurso y el tipo de movimiento, se muestra la

reserva correspondiente a la devolucin que se va a registrar. Por ello, para confirmar la
devolucin se deber pulsar el botn de Registrar Devolucin:
223

A continuacin la aplicacin proporciona un mensaje informando si la operacin de

devolucin se ha registrado correctamente o no, ya que implica realizar una
actualizacin del estado del recurso y del prstamo asociado que se acaba de finalizar.
El mensaje que confirma el correcto registro del movimiento se muestra con la siguiente
imagen que se adjunta:
Por ltimo, despus de registrar el movimiento de devolucin, se proporciona la

posibilidad de escribir en la tarjeta algn problema o deficiencia fsica del recurso que
haya que recordar en posteriores gestiones.
El proceso de escritura en las devoluciones es el siguiente:
1. Se muestra una ventana donde se deber escribir la descripcin del problema.
224

El comentario que se desee escribir no debe ser superior a 16 caracteres debido a las
restricciones de las tarjetas RFID; si se supera se mostrar el siguiente mensaje de error:
2. A travs de otra ventana informativa se solicitar que se aproxime la tarjeta del

recurso al lector para proceder a realizar la escritura del comentario que se ha descrito
en el paso anterior:
Si la escritura se realiz correctamente, el lector emitir un sonido de confirmacin de la

escritura, y el sistema mostrar la tabla de recursos con el estado de disponibilidad
actualizado con la devolucin que se acaba de gestionar: se activa el checkbox
correspondiente al recurso devuelto.
Si por el contrario, se produce un error se muestra el siguiente mensaje:
225

Para resolverlo, se deber pulsar el botn de aceptar hasta que se escuche el sonido
emitido por el lector confirmando la lectura. Si se considera que la tarjeta no se
encuentra bien situada frente al lector, se deber posicionar de nuevo entre los diferentes
intentos hasta conseguir la escritura.
3.3 Botn de Nueva Lectura
Si despus de identificar un recurso no se desea realizar el movimiento correspondiente

se debe pulsar el botn de Nueva Lectura para poder llevar a cabo otra lectura.
3.4. Escritura en una tarjeta RFID.

Cuando se realiza una escritura, el comentario o descripcin a grabar en la tarjeta no
debe superar los 16 caracteres de longitud mxima ya que se excede el tamao del
bloque de memoria donde se va a escribir.
Siempre que se tenga que realizar una escritura en una tarjeta, el sistema solicitar al
usuario que aproxime dicha tarjeta al lector RFID. El mensaje de peticin es el
siguiente:
Cuando se acepte se realiza la escritura.
226

Si la operacin no se completa se muestra un mensaje de error:
Para conseguir que la operacin se realice correctamente se deber comprobar que la

tarjeta se sita adecuadamente sobre el lector, y aceptar de nuevo el intento de escritura.
En el momento en el lector emita un beep significar que la operacin se ha llevado a
cabo satisfactoriamente.
227

4. Ayudas
En este apartado se contemplan los posibles errores que se pueden producir durante la
ejecucin de la aplicacin. Para cada uno de ellos, se proporcionan una serie de pautas
que permiten resolverlos.
4.1. Mensaje de error: Error al identificar el recurso, aproxime de nuevo la tarjeta
1. Compruebe que el lector est conectado al ordenador.
2. Site de nuevo la tarjeta sobre el lector, asegurndose que se encuentra prxima

a la antena. (Ver apartado de Posicin de lectura).
4.2. Error de conexin con la base de datos
1. Comunicar el problema al administrador del sistema.
228

La conexin inicial que se establece al arrancar la ejecucin ha fallado:
1.1. Verificar el estado de la base de datos en el servidor.
1.2. Comprobar el driver de acceso a la base de datos.
4.3. No se han encontrado recursos registrados
1. Comunicar el problema al administrador.
La base de datos con la que trabaja de la aplicacin no es la correcta, o la tabla de

recursos del departamento se encuentra vaca.
1.1. Comprobar que la tabla de recursos est disponible y contiene registros realizando
una consulta directa contra el servidor
4.4. Error en el acceso a la base de datos. Se finaliza la aplicacin
1. Comunicar el problema al administrador.
229

El acceso a la base de datos del personal del departamento ha fallado:
1.1. Verificar el estado de la base de datos card_personal en el servidor.
1.2. Comprobar el driver de acceso a dicha base de datos.
4.5. La fecha de devolucin es errnea. Debe ser anterior a XXXX-XX-XX
La fecha de devolucin introducida al definir los datos de configuracin de la

reserva instantnea debe ser anterior a la fecha y hora en la que hay que entregar el
recurso en el siguiente prstamo confirmado. Por tanto, introduzca:
Fecha de devolucin anterior a la fecha de entrega mostrada en la reserva ms

prxima asociada.
Fecha de devolucin igual a la fecha de entrega pero la hora de devolucin

menor a la de entrega.
4.6. Error de escritura RFID. Aproxime de nuevo la tarjeta RFID al lector
230

Acepte el mensaje informativo, y automticamente se realizar un nuevo intento de

escritura.
4.7. El campo Informacin adicional del prstamo debe ser ms corto
La descripcin o comentario relacionado con un determinado recurso debe tener una

longitud mxima de 16 caracteres. En caso de no satisfacerse este restriccin, se
mostrar este mensaje de error.
4.8. Error al actualizar los recursos de la devolucin. Intntelo de nuevo
Repita de nuevo todo el proceso de devolucin explicado con anterioridad.
4.9. Error al registrar la devolucin
231

Cuando las devoluciones se realizan con antelacin al da que se haba acordado es

necesario actualizar el estado de la reserva asociada, de manera que el equipo queda
marcado como libre, y el sistema puede aceptar nuevas reservas sobre el mismo a partir
del instante e que se realiza la devolucin. Si el proceso de actualizacin falla se lanza
este tipo de error. Por ello, se ha de repetir de nuevo todo el proceso de devolucin
explicado con anterioridad.
232

5. Ubicacin de las tarjetas para la lectura RFID

Para evitar posibles errores de lectura o de escritura derivados por la incorrecta posicin
de la tarjeta sobre el lector, se ha de tener en cuenta que la correcta ubicacin es la que
se muestra en la imagen que se adjunta.
233

A nexo 3
Manual de
Instalacin
234

Captulo
1. Instalacin de la JVM
1.1. Aadir la variable de entorno PATH
2. Gua de instalacin de la aplicacin Control de Visitas
Pgina
236
236
238
2.1. Instalacin del driver del lector de tarjetas
238
2.2. Instalacin del software OpenCard
239
2.3. Instalacin de la aplicacin
244
3. Gua de instalacin de la aplicacin Control de Inventario
244
3.1. Instalacin del driver del lector RFID
244
245
4. Creacin del vnculo con la base de datos
245
235

A continuacin se indican los pasos que se han de seguir para llevar a cabo la
instalacin del sistema en entornos Windows, aunque al tratarse de herramientas
multiplataforma y gratuitas, podran instalarse en otros sistemas operativos.
1. Instalacin de la JVM
Para obtener la JVM hay que dirigirse a la pgina Web www.sun.com y acceder a la
seccin de descargas, donde se puede descargar de manera gratuita la Java 2 Platform
Standard Edition (J2SE). sta se puede descargar como kit de desarrollo, JDK, o
simplemente como entorno de ejecucin, JRE.
Una vez descargado el fichero, hay que ejecutarlo realizando un doble clic sobre el
mismo y seguir los pasos que el asistente de instalacin indicar para completar la
instalacin.
1.1. Aadir la variable de entorno PATH

Con el objetivo de poder ejecutar y
compilar aplicaciones Java desde la
consola de comandos, aadimos a la
variable Path el directorio en el que
se encuentran los archivos binarios
de Java.
Para ello entre en Propiedades del

sistema haciendo clic con el botn
derecho de su ratn sobre el icono
de MI PC o pulse la tecla Windows
seguida de la tecla Pause.
236

A continuacin se debe hacer clic en la pestaa Opciones avanzadas y seguidamente en

el botn Variables de entorno.
Por ltimo hay que crear la nueva variable de usuario indicando el nombre de la
variable Path y el valor de la variable C:\directorio del jdk\bin.
237

2. Gua de instalacin de Control de Visitas

El primer paso, antes de instalar la aplicacin, ser cerciorarse de que se encuentra
instalado en el ordenador donde se va a ejecutar la aplicacin la JVM, el driver del
lector y las libreras de OpenCard.
Si no se tiene instalado algn componente de los mencionados anteriormente, a

continuacin se explica como instalar cada uno de ellos paso a paso.

El primer paso para instalar el driver, proporcionado por el fabricante del lector, es
recomendable copiar los ficheros del mismo en un directorio del sistema destinado para
ello donde sea fcilmente localizable, y su ubicacin coherente a su funcionalidad, por
ejemplo dentro del directorio C:\Control de Visitas.
Copiados los ficheros, se deber conectar el lector al ordenador. Cuando el sistema lo

identifique mostrar una ventana correspondiente al asistente de configuracin de
hardware. En primer lugar preguntar si se desea que se conecte con Windows Update,
seleccionando la opcin negativa.
Seguidamente el asistente solicitar que se indique cmo se van a proporcionar los

drivers del hardware que se desea instalar. La opcin que se ha de seleccionar es la que
se corresponde con Instalar el driver desde una ubicacin especfica, de manera que
en el siguiente paso se deber pulsar sobre l botn de Examinar y determinar la ruta
de acceso a la carpeta donde se copiaron los ficheros.
Finalmente, el sistema comunicar el resultado del proceso de instalacin de nuevo

hardware.
238

2.2. Instalacin del software OpenCard

El primer paso es descargar las libreras de OpenCard (software gratuito y abierto) de la
siguiente pgina Web, www.opencard.org, en la seccin download. Hay que descargar
el fichero installocf.class localizado en el apartado OpenCard Framework All-in-One.
Una vez descargado el fichero, se abrir la consola de comandos y se debe ejecutar lo

siguiente java installOCF.
En caso de que a la hora de ejecutar el comando anterior aparezca un mensaje de error

como el de la siguiente captura, deber aadir en la variable de entorno classpath el
directorio en el que se encuentra, de la siguiente forma:
239

La ejecucin correcta del fichero de OpenCard descargado permitir arrancar el

asistente de instalacin del sw:
Seguidamente, nos pedir la ruta de instalacin y el nombre de un grupo de programas

para colocarlo en el men Inicio.
A continuacin, pedir confirmacin para crear un fichero de configuracin interna, en

donde responderemos de manera afirmativa.
240

Posteriormente, nos solicitar qu protocolo de comunicaciones queremos instalar, a lo

que responderemos PC/SC ya que el estndar Java Card; an no est tan
popularizado como el PC/SC, y por tanto para la realizacin del proyecto se escogi el
estndar PC/SC.
Tras hacer esta eleccin si se diese el caso en que se mostrara un mensaje de error, lo
ignoraremos pulsando OK
241

Mas tarde, se pedir una ruta para guardar los ficheros internos, en donde por defecto
establecer la ruta de las libreras de Java, que no debe ser modificada.
Por ltimo pedir una confirmacin antes de instalar.
Despus de aceptar el comienzo del proceso de instalacin, se mostrar una ventana con
el logotipo de OpenCard que contiene un dilogo que indica el tiempo restante para
finalizar dicha instalacin, es como una barra de progreso.
242

Es posible que durante la instalacin aparezca un mensaje de reemplazo de ficheros con

el mismo nombre pero diferente fecha, en estos casos se coger la opcin que mantenga
el fichero ms actual.
243


Para llevar a cabo la instalacin de la aplicacin tan slo es necesario copiar la carpeta
aplicacin local de Control de Visitas, que se encuentra en el CD que acompaa a este
proyecto, al directorio raz (C:\) de su ordenador.
Debido a que la aplicacin tiene acceso a BBDD va Web, es necesario crear un vnculo
a la base de datos. En el apartado 4 se explica como realizarlo.
3. Gua de instalacin de Control de Inventario

El primer paso, antes de instalar la aplicacin, ser verificar que se encuentra instalada
la JVM y los driver del lector RFID.
Si no se tiene instalado el driver del lector RFID proporcionado por el fabricante, a

continuacin se explica como instalar cada uno de ellos paso a paso.

El primer paso para instalar el driver, es recomendable copiar los ficheros del mismo en
un directorio del sistema destinado para ello donde sea fcilmente localizable, y su
ubicacin coherente a su funcionalidad, por ejemplo dentro del directorio C:\Control de
Inventario.
Copiados los ficheros, se deber conectar el lector al ordenador. Cuando el sistema lo

identifique mostrar una ventana correspondiente al asistente de configuracin de
hardware. En primer lugar preguntar si se desea que se conecte con Windows Update,
seleccionando la opcin negativa.
244

Seguidamente el asistente solicitar que se indique cmo se van a proporcionar los

drivers del hardware que se desea instalar. La opcin que se ha de seleccionar es la que
se corresponde con Instalar el driver desde una ubicacin especfica, de manera que
en el siguiente paso se deber pulsar sobre l botn de Examinar y determinar la ruta
de acceso a la carpeta donde se copiaron los ficheros. Finalmente, el sistema
comunicar el resultado del proceso de instalacin del nuevo hardware.

Para llevar a cabo la instalacin de la aplicacin tan slo es necesario copiar la carpeta
aplicacin local Control de Inventario, que se encuentra en el CD que acompaa a
este proyecto, al directorio raz (C:\) de su ordenador.
Debido a que la aplicacin tiene acceso a BBDD va Web, es necesario crear un DNS.
En el siguiente apartado se explica como realizarlo.
4. Creacin del vnculo con la base de datos
Acceda al Panel de
Control
de
su
ordenador
haga
doble
clic
sobre
Herramientas
administrativas.
245

A continuacin se abrir una carpeta en la que tendr que hacer doble clic sobre
Orgenes de datos (ODBC).
En la siguiente ventana usted deber seleccionar el driver del gestor de bases de datos
correspondiente para su implantacin real.
Las aplicaciones desarrolladas son independientes del gestor de base de datos que se
utilice (Oracle, SQLServer, MySQL, etc.) En la implantacin definitiva se utiliza un
servidor Solaris con SQL, por lo que e necesario habilitar el nombre del servidor, el
nombre de la base de datos
Sin embargo, para preservar la informacin del servidor durante las pruebas y en el
desarrollo del proyecto, se he seleccionado el driver de Access para el acceso local en
modo de pruebas.
246

Para definir el vnculo con Access hay que indicar el nombre del DNS, el directorio en
el cual se encuentra ubicada la base de datos con la que se quiere trabajar y se confirma
pulsando sobre el botn de aceptar.
Las bases de datos necesarias para llevar a cabo la gestin de visitas son dos: card y
card_personal. Por ello, se tendrn que crear dos orgenes de datos, mientras que en
Control de Visitas slo hay que definir la base de datos de equipos.
247

Sistemas de Control de Accesos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistemas de Control de Accesos

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)

PROYECTO FIN DE CARRERA

SISTEMAS DE CONTROL DE ACCESOS

AUTOR: MARTA VELAYOS SARDIA

MADRID, JUNIO 2007

Proyecto Fin de Carrera

Proyecto Fin de Carrera

1. Descripcin general del Sistema

2. Aplicacin de Control de Visitas

Identificar al visitante: A partir de la lectura del carnet de alumno de la

Proyecto Fin de Carrera

Determinar la persona que se quiere

Confirmar el registro de la visita tratada en la base de datos correspondiente.

3. Aplicacin Control de Inventario

Proyecto Fin de Carrera

Control de Visitas: Tecnologa de tarjetas inteligentes

Agilizar el proceso de registro de las visitas, minimizando considerablemente el

Almacenamiento automtico de toda la informacin relativa a la visita: visitante,

Ayudar al usuario final proporcionando informacin relativa a los empleados del

Control de Inventario: Tecnologa RFID

Rpida identificacin de los recursos a partir de la lectura RFID de los TAGs.

Proyecto Fin de Carrera

Proyecto Fin de Carrera

1. General description of the system

2. Access Control Application

This is done by:

Reading of the University student card

Proyecto Fin de Carrera

Determining the person which is

personnel. In this list, the phone

Confirmation the storage of the visit data into database.

Proyecto Fin de Carrera

Visit Control: Smart Card Technology

Acceleration the registration process reducing typing to a minimum (only in case

Automatically storing in a database all the information related to each visit:

Inventory Control: RFID Technology

To carry out a detailed and automated monitoring of the departments shared

Faster and accurate identification of the resource by applying RFID technology.

Proyecto Fin de Carrera

Proyecto Fin de Carrera

1. Plan de Gestin del Proyecto

1.2. Definicin del proyecto

1.3. Diagrama de Actividades

1.4. Descripcin detallada de las Actividades

1.5. Organigrama del equipo de trabajo

1.6. Funcionalidad de los integrantes del equipo de trabajo

1.7. Estimacin y presupuesto

1.8. Planificacin de alto nivel

2. Documento de Conceptos del Sistema

2.1. Objetivos del sistema

2.2. Alcance del sistema

2.3. Tipologa de los usuarios finales

3.1. mbito del proyecto

3.2. Contexto general del sistema

3.3. Evaluacin y anlisis

3.4. Modelo Fsico

3.5. Modelo Lgico

3.6. Modelo Conceptual de datos

4.1. Especificacin de la tecnologa hardware

Proyecto Fin de Carrera

4.1.1.2. Tipos de Tarjetas Inteligentes

4.1.1.3. Sistema de Ficheros

4.1.1.4. Mtodos de Acceso a la TI