View
7
Download
0
Category
Preview:
Citation preview
PROYECTO FIN DE CARRERA
SISTEMAS DE CONTROL DE ACCESOS A EDIFICIOS MEDIANTE TARJETAS
CRIPTOGRÁFICAS Y TARJETAS RFID
AUTOR: MARTA VELAYOS SARDIÑA
MADRID, JUNIO 2007
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
I
RReessuummeenn
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
II
1. Descripción general del Sistema
El proyecto Sistema de Control de Accesos a Edificios tiene como objetivo estudiar y
desarrollar dos tecnologías de control de acceso, basadas en la utilización de tarjetas
inteligentes y tarjetas de radiofrecuencia (RFID). Se ha desarrollado un sistema
destinado al Instituto de Investigación Tecnológico (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. Aplicación de Control de Visitas
La primera aplicación que constituye el sistema final es Control de Visitas, destinada a
registrar las visitas que se realicen en el centro. Este subsisema utiliza la tecnología de
tarjetas inteligentes, de manera que se comunica con un lector LTCX conectado al
ordenador del usuario final a través de un puerto USB. Control de Visitas tiene como
finalidad proporcionar una aplicación que permita al responsable del punto de control
llevar a cabo la gestión de las visitas que tengan lugar. Esta gestión consiste en:
� Identificar al visitante: A partir de la lectura del carnet de alumno de la
Universidad.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
III
� 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
extensión y el despacho donde se puede
localizar el empleado en cuestión, y así
facilitar su localización.
� Confirmar el registro de la visita tratada en la base de datos correspondiente.
3. Aplicación Control de Inventario
Se ha desarrollado la aplicación de Control de Inventario, destinada a llevar a cabo un
seguimiento del estado de los recursos prestables (ordenadores portátiles, cámaras
digitales) que proporciona el departamento a sus empleados. La gestión de los
préstamos y devoluciones de los recursos se ha implantado con la tecnología de
radiofrecuencia, de manera que para realizar este control el sistema se comunica con un
lector RFID, conectado al ordenador donde se ejecuta la aplicación a través de un puerto
USB. La identificación 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 gestión correspondiente
del movimiento asociado. El sistema se encuentra integrado con la aplicación de
“Reservas Online” donde cada empleado puede realizar la reserva del equipo que
necesite durante un periodo determinado.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
IV
4. Conclusión
Se han desarrollado dos aplicaciones de control de acceso, las cuales se han implantado
utilizando dos tecnologías de identificación diferentes. Las ventajas más importantes
que se han conseguido son:
Control de Visitas: Tecnología de tarjetas inteligentes
� Agilizar el proceso de registro de las visitas, minimizando considerablemente el
tiempo de cómputo que supone, al realizar la lectura de las tarjetas con esta
tecnología, incluyendo el caso de que no se disponga del carnet de alumno.
� Almacenamiento automático de toda la información relativa a la visita: visitante,
visitado, hora…
� Ayudar al usuario final proporcionando información relativa a los empleados del
departamento: extensión, despacho…
Control de Inventario: Tecnología RFID
� Llevar a cabo un seguimiento detallado del estado de los recursos del IIT.
� Rápida identificación 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 gestión, y sincronización del sistema con la base de datos de reservas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
V
AAbbssttrr aacctt
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
VI
1. General description of the system
The main aim of Buildings Access Control System’s 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 department’s 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 user’s 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
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
VII
� Determining the person which is
visited: It consist of selecting the
employ’s 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 resource’s 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
VIII
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 doesn’t have an ID card) since ID cards is read using this technology.
� Automatically storing in a database all the information related to each visit:
visitor’s 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
IX
ÍÍ nnddiiccee
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
X
Capítulo
Página
1. Plan de Gestión del Proyecto
1.1. Introducción
1.2. Definición del proyecto
1.3. Diagrama de Actividades
1.4. Descripción detallada de las Actividades
1.5. Organigrama del equipo de trabajo
1.6. Funcionalidad de los integrantes del equipo de trabajo
1.7. Estimación y presupuesto
1.8. Planificación de alto nivel
1
2
2
3
8
12
13
16
23
2. Documento de Conceptos del Sistema
2.1. Objetivos del sistema
2.2. Alcance del sistema
2.3. Tipología de los usuarios finales
2.4. Restricciones
2.5. Antecedentes
24
25
25
28
28
30
3. Análisis de Requisitos
3.1. Ámbito del proyecto
3.2. Contexto general del sistema
3.3. Evaluación y análisis
3.4. Modelo Físico
3.5. Modelo Lógico
3.6. Modelo Conceptual de datos
31
32
35
36
47
63
67
4. Estudio de la Arquitectura
4.1. Especificación de la tecnología hardware
4.1.1. Tarjetas Inteligentes
74
75
75
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
XI
Capítulo
Página
4.1.1.1. ISO 7816
4.1.1.2. Tipos de Tarjetas Inteligentes
4.1.1.3. Sistema de Ficheros
4.1.1.4. Métodos de Acceso a la TI
4.1.1.5. Lector LTCX
4.1.2. Tecnología RFID
4.1.2.1. Funcionamiento
4.1.2.2. Protocolos y Opciones
4.1.2.3. Etiquetas RFID: TAGS
4.1.2.4. Estándar Mifare
4.1.3. Plataforma donde reside el sistema
4.2. Especificación de la tecnología software y de comunicaciones
4.3. Arquitectura final del sistema
4.4. Evaluación Económica
4.5. Elaboración del Plan de Proyecto
75
79
82
82
85
86
88
89
90
92
93
93
94
95
99
5. Diseño Externo
5.1. Requisitos físicos del nuevo sistema
5.1.1. Entono operativo del sistema
5.1.2. Configuración hardware/software
5.2. Desarrollo del Modelo Físico Final
5.2.1. Fronteras de Mecanización
5.2.2. Especificación de Procesos
5.2.3. Diseño de Entradas
5.2.4. Diseño de Salidas
5.2.5. Estimación de Volúmenes de Información
5.2.6. Procesos de Control y de Seguridad
102
103
103
108
111
113
116
121
123
124
128
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
XII
Capítulo
Página
6. Diseño Interno
6.1. Técnicas a utilizar
6.2. Subsistema online
6.2.1. El Diagrama de Cuadros Estructurado (STC)
6.2.2. Derivación del DFD al STC
6.2.3. Consideraciones de diseño
6.3. Diagrama del Sistema
6.4. Cuaderno de Carga
132
134
135
136
139
148
149
150
7. Programación
7.1. Análisis y diseño orientado a objetos
7.1.1. Introducción
7.1.2. Ciclo de desarrollo orientado a objetos
7.1.3. Técnicas OO en las fases de la metodología
7.2. Manual de Usuario
7.2.1. Manual de Usuario de Control de Visitas
7.2.2. Manual de Usuario de Control de Inventario
159
161
161
162
163
180
182
182
8. Pruebas
183
9. Implantación
188
10. Conclusiones
190
11. Glosario de Términos
193
12. Bibliografía
199
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
XIII
Capítulo
Página
Anexo 1
202
Anexo 2
212
Anexo 3 234
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
1
11.. PPllaann ddee GGeesstt iióónn
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
2
1.1. Introducción
El presente documento define el Plan de Gestión del proyecto Sistema de Control de
Accesos, PSCA, contemplando los objetivos y alcance del proyecto, la estructura
jerárquica de las actividades principales describiendo una de ellas, la organización del
equipo de trabajo especificando la funcionalidad de uno de los perfiles, la estimación y
presupuesto, y la planificación determinada para la realización de dicho proyecto.
1.2. Definición del Proyecto
Se desea desarrollar un sistema, destinado al Instituto de Investigación Tecnológico
(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 gestión 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 portátiles 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 tecnología de tarjetas inteligentes, de
forma que cuando se atienda la llegada de una persona en el departamento, se solicitará
su carnet de identificación personal para proceder a realizar el registro correspondiente.
Por último, el Control de Inventario se realizará a partir de la utilización de un lector
de radiofrecuencia (RFID), de manera que cuando se desee registrar un préstamo o una
devolución de alguno de los ordenadores portátiles, proporcionados por el IIT, se deberá
mostrar al lector el TAG RFID que posee el recurso, para realizar el proceso de
identificación del mismo.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
3
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:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
4
A continuación, 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
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
5
• Actividad PSCA03.2
• Actividad PSCA03.3
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
6
• Actividad PSCA03.4
• Actividad PSCA03.5
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
7
• Actividad PSCA03.6
• Actividad PSCA03.7
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
8
1.4. Descripción detallada de las Actividades
En este punto del plan de gestión se proporciona una breve descripción de los paquetes
de trabajo de primer y segundo nivel, según corresponda, que constituyen el desarrollo
completo del presente proyecto.
PSCA01.1 REUNIÓN DE LANZAMIENTO
Primera reunión 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 GESTIÓN DEL PROYECTO
Se corresponde con la elaboración del Plan de Gestión del proyecto que se va a llevar a
cabo. Dicho plan supone una primera aproximación 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 GESTIÓN 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 también la elaboración de la documentación correspondiente a
cada una de las etapas que se vayan finalizando, y que en conjunto constituyen el
documento final.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
9
PSCA03.1 INDETIFICACIÓN DE NECESIDADES
Tarea que se comporta como soporte a la petición que el director del proyecto realiza
para determinar las pautas generales de las necesidades determinadas y del contexto del
sistema. La información recogida durante esta etapa se especifica en un Documento de
Conceptos del Sistema.
PSCA03.2 ANÁLISIS 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 físico del sistema, y a partir de él se deduce el
modelo de procesos lógico el cual recoge las funciones esenciales del negocio
PSCA03.3 ESTUDIO DE LA ARQUITECTURA
El objetivo de esta Actividad es definir la solución de arquitectura técnica que satisface
tanto los requisitos como las restricciones del diseño. La arquitectura debe indicar qué
componentes software, hardware y de comunicaciones han de adquirirse o
desarrollarse.
La solución deberá dar una visión externa del sistema, los requisitos físicos que se
tienen que tener en cuenta, así como los aspectos organizativos, operativos, técnicos y
económicos asociados.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
10
PSCA03.4 DISEÑO EXTERNO
En esta etapa se completa la definición de las especificaciones del sistema a mecanizar,
obteniéndose el modelo físico final de procesos y el modelo lógico de datos, de
acuerdo a la plataforma hardware y software definida en la tarea anterior.
Además, esta Actividad elabora la estrategia que se ha de llevar a cabo en las etapas de
Pruebas e Implantación, la formación de los usuarios y las conversiones necesarias de
hardware y software del sistema actual al nuevo.
PSCA03.5 DISEÑO INTERNO
Esta tarea identifica y diseña los diversos componentes software del sistema,
describiendo detalladamente sus características físicas. 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
tipología de los procesos, y así especificar y diseñar sus componentes.
PSCA03.6 PROGRAMACIÓN
El objetivo de este paquete de trabajo es alcanzar la transformación del sistema en un
conjunto de programas que puedan ser ejecutados satisfactoriamente bajo unos criterios
de calidad. La dificultad se encuentra en cómo realizar la transformación de la mejor
manera posible ya que depende en gran medida del lenguaje de programación y de las
herramientas software disponibles.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
11
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 Diseño 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 IMPLANTACIÓN
Después de probar la integridad del software del sistema y especificada su instalación y
configuración, se debe instalar el software producido en el entorno de trabajo o Centro
de Producción para llevar a cabo la explotación del sistema final. De forma que su
objetivo es el de implementar el nuevo sistema en la producción real.
PSCA04 CIERRE DEL PROYECTO
Esta actividad engloba tanto la reunión de aceptación con el director y con el
coordinador del proyecto, como l elaboración de una copia tanto de la documentación
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 documentación de la
universidad.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
12
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 más importante debido a su mayor grado de implicación en el mismo.
La figura del alumno se corresponde con la persona destinada a estudiar, diseñar 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, relación muy
diferente a la existente con el coordinador, ya que sólo se realizarán 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 aplicación para
consolidar aspectos de diseño o mejoras del mismo, así como otros aspectos no
funcionales.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
13
1.6. Funcionalidad de los integrantes del equipo de trabajo
En el siguiente punto se recoge la funcionalidad que desempeña 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, ayudándole desde el punto de vista técnico y funcional y
motivándole para que cumpla los plazos establecidos. El Director podrá ser un Profesor
de la Escuela de Ingeniería o un ingeniero (o titulado superior) normalmente en
ejercicio de la profesión que haya mostrado interés 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 realización 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 opinión sobre el alumno y el trabajo realizado rellenando el formulario
elaborado al efecto y entregándoselo al correspondiente Coordinador.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
14
En general ningún director podrá dirigir más de 8 proyectos distintos en el mismo curso
académico, las excepciones a esta regla deberán ser autorizadas por el Coordinador
General.
Coordinador del Proyecto: CPFC
Cada Coordinador será responsable de la calificación 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 ningún proyecto asignado.
• Concretar la definición 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).
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
15
• 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 informática, para el examen de
Reválida, el alumno llevará, junto con el material que considere necesario para
realizar la exposición 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
Secretaría General en el momento de realizar la matrícula de Reválida.
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 deberán tener el visto bueno del correspondiente
Coordinador, a más tardar en la última semana del mes de Octubre.
• Cada alumno deberá preparar de común 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 presentación. El Coordinador fijará una fecha para la entrega de la
memoria, siendo en la última semana del mes de Noviembre la más tardía.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
16
• El seguimiento del proyecto se realizará a través de la clase semanal planificada.
Durante estas sesiones el alumno de acuerdo con la programación 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
públicas de avance de su proyecto. En general, se realizarán una exposición de
avance y otra a la finalización del trabajo.
• El alumno debe asistir al menos al 50% de las clases de la asignatura.
1.7. Estimación y Presupuesto
A partir de la jerarquía de Actividades diseñada en el punto 1.3 se va a realizar un
estudio de la asignación de recursos para el desarrollo del proyecto. Dicha asignación
permitirá estimar el presupuesto correspondiente al proceso de diseño del sistema final.
Estimación de recursos
La estimación realizada sólo 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 evolución 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 relación temporal entre las Actividades. Dicha relación
permitirá entender la evolución del progreso de desarrollo de los paquetes de trabajo, al
igual que la definición de las duraciones de cada uno de ellos.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
17
La relación 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 Duración
PSCA01.1 No tiene 1 día (0’033 meses)
PSCA01.2 PSCA01.1 5 días (0’2 meses)
PSCA02 PSCA01.2 270 días (9 meses)
PSCA03.1 PSCA01.2 15 días (0’5 meses)
PSCA03.2 PSCA03.1 15 días (0’5 meses)
PSCA03.3 PSCA03.2 30 días (1 mes)
PSCA03.4 PSCA03.3 15 días (0’5 meses)
PSCA03.5 PSCA03.4 30 días (1 mes)
PSCA03.6 PSCA03.5 75 días (2’5 meses)
PSCA03.7 PSCA03.6 15 días (0’5 meses)
PSCA03.8 PSCA03.7 15 días (0’5 meses)
PSCA04 PSCA02 , PSCA03.8 2 días (0’067 meses)
Se ha considerado que cada semana tiene 7 días laborables, valorándose la duración de
cada Actividad tanto en días como en meses.
Con el objetivo de realizar un estudio detallado de la asignación de recursos, se ha
diseñado primeramente la Red Pert correspondiente a la EDT del proyecto de gestión,
de forma que se pueda calcular cual es el camino crítico y los márgenes de las
Actividades que presenten una cierta flexibilidad entre las fechas de inicio y fin del
proyecto.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
18
La Red Pert a su vez permitirá definir las fechas de inicio y finalización de cada uno de
los paquetes de trabajo, satisfaciendo la relación temporal entre ellas y la fecha de
entrega del proyecto final.
La flexibilidad que presenten determinadas Actividades proporcionará la posibilidad de
cambiar su organización inicial de tal forma que se garantice un desarrollo del proyecto
uniforme desde el punto de vista de la asignación 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 gestión, valorando la duración en días,
es la siguiente:
El camino crítico del proyecto lo constituyen las actividades de gestión: las dos
primeras etapas de inicio y elaboración del Plan de Gestión, la propia Actividad de
Gestión global del proceso de desarrollo y la tarea de Cierre del Proyecto.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
19
La asignación del número 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:
1 2 3 4 5 6 7 8 9 TOT
PSCA01.1
CPFC 1 1
DPFC 3 3
APFC 3 3
PSCA01.2
CPFC
DPFC 2 2
APFC 20 20
PSCA02
CPFC 10 10
DPFC 20 10 10 10 10 10 10 10 90
APFC 10 30 20 20 20 20 20 10 10 160
PSCA03.1
CPFC
DPFC 10 10
APFC 30 30
PSCA03.2
CPFC
DPFC
APFC 30 30
PSCA03.3
CPFC
DPFC 10 10
APFC 80 80
TOTAL 109 140 30 30 30 30 30 20 30 449
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
20
1 2 3 4 5 6 7 8 9 TOT
PSCA03.4
CPFC 1 1
DPFC 10 10
APFC 80 80
PSCA03.5
CPFC
DPFC 5 5 10
APFC 20 60 80
PSCA03.6
CPFC
DPFC 30 30
APFC 50 80 80 210
PSCA03.7
CPFC
DPFC 10 10
APFC 30 30
PSCA03.8
CPFC
DPFC 10 10
APFC 30 30
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 número 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
además del que ha llevado a cabo el alumno.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
21
Para tener una visión general de la evolución de la dedicación 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 duración completa del proyecto:
Se puede observar que entre el primer mes y el tercero hay un incremento constante del
número de horas a trabajar debido a que se pretenden finalizar cinco etapas del
desarrollo más la documentación correspondiente de cada una de ellas.
Tras el primer trimestre se produce un descenso considerable de la dedicación debido a
que se corresponde con el momento de preparación de los exámenes de febrero y de
dedicación para terminar las prácticas finales del primer periodo del curso.
La etapa final del proyecto, correspondiente a los últimos cuatro meses, se caracteriza
por ser mucho más uniforme el esfuerzo que hay que emplear para realizar las tres
últimas etapas del desarrollo.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
22
Calculadas las horas de trabajo a emplear, a continuación 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 además del coste total del equipo de trabajo,
obtenemos el presupuesto inicial estimado para el desarrollo del proyecto:
Recurso Total €
Subtotal Equipo de trabajo: 38010
Lector Inteligente 200
Lector RFID 300
Tags RFID 50
Desplazamiento 300
Comunicaciones 200
Subtotal recursos: 1050
Total Final 39060
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
23
1.8. Planificación de alto nivel
La planificación que determina el desarrollo y evolución del proyecto Sistema de
Control de Accesos, se muestra a continuación:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
24
22.. DDooccuummeennttoo ddee CCoonncceeppttooss
ddeell SSiisstteemmaa
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
25
2.1. Objetivos del sistema
Se desea desarrollar un sistema, destinado al Instituto de Investigación Tecnológico
(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 gestión 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 portátiles 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 definición 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 deberán ser recogidas en la correspondiente base de datos, facilitando
el registro, además de los alumnos que desean ser atendidos por un profesor de dicho
departamento, el de aquellas personas que no disponen de la identificación 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
gestión de la visita actual.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
26
Control de Inventario
Paralelamente, se desea realizar un control de los ordenadores portátiles y de otro tipo
de recursos, como por ejemplo cámaras fotográficas, 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 gestión de las entradas y salidas del material
suministrado, así como de la identificación y registro de las personas que deseen utilizar
o recoger dicho recurso.
Además, el sistema de Control de Inventario debe estar integrado con un sistema de
reservas previamente existente: “Reservas Online”.
Recopilación 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, información referente a las visitas que han sido
registradas con anterioridad, así como de los recursos informáticos que se encuentran
disponibles y la información de reservas para el Control de Inventario.
Cada visitante y personal del IIT quedarán perfectamente definidos mediante una serie
de datos personales que definen su perfil, de acuerdo al diseño de las tablas que
constituyen las BBDD creadas para la gestión deseada.
Del mismo modo, el control que se realizará sobre los ordenadores portátiles permitirá
conocer en cada momento qué recurso está disponible o cuándo ha de ser devuelto y por
quién, de manera que todos los movimientos sobre dicho material quede recogido en la
base de datos para conseguir un seguimiento eficiente de los mismos.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
27
Acceso a la información
Su misión 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 desempeña 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 confirmación para poder registrarlo en la
correspondiente base de datos para poder actualizar el estado del recurso.
Administración y control del entorno
Tiene como objetivo la gestión 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 través de la
ejecución de las aplicaciones correspondientes y de la manipulación de los lectores
utilizados para la lectura de las tarjetas de identificación. Sin embargo, la información
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
utilización del sistema. Es la propia aplicación la que lleva a cabo las operaciones contra
las bases de datos correspondientes y porque éstas residen en un servidor al que sólo 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 recepción del edificio, controlando las llegadas, tanto
de personas como de documentos.
La aplicación residirá en un PC restringido, al cual sólo tienen acceso las personas cuyo
perfil se corresponda con el que se ha comentado anteriormente.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
28
2.3. Tipología de los usuarios finales
Los usuarios del sistema, serán 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 administración y gestión de todo lo que ocurre en cada uno de los
edificios referenciados. Sin embargo, sólo 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, serán las personas que se adecuen al
perfil indicado que tengan que trabajar en el IIT.
2.4. Restricciones
El sistema que se ha de diseñar 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 programación 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 información 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 librerías y funciones adecuadas para que la aplicación Java sea
capaz de realizar la lectura de las tarjetas, y manipular los datos leídos de las mismas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
29
Al mismo tiempo, la aplicación deberá proporcionar dos funciones adicionales:
• Por un lado, la posibilidad de “Introducir datos a mano”, situación que se
corresponde con la llegada de un visitante que no posee su tarjeta en el momento
de la gestión 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.
• Opción 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 tecnología 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 autentificación, se procederá a determinar
el tipo de movimiento que se va a. Si se confirma el préstamo o la devolución, se
registrará la entrada o salida del recurso, según corresponda, y se actualizará su estado
de disponibilidad.
Adicionalmente, se contempla la escritura en el TAG de incidencias que alteren la
utilización de un recurso, bien porque este dañado físicamente, o las condiciones con
que se realiza un préstamo del mismo.
Al mismo tiempo, se ha de tener en cuenta una restricción de tipo económico, ya que los
recursos del proyecto necesarios para implantar el sistema en el IIT están financiados
por la universidad.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
30
2.5. Antecedentes
El departamento del IIT dispone de un proyecto base que contempla la realización del
control de acceso del personal al edificio, de forma que se utilizará como punto de
partida para el diseño 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 día, de manera que no facilita la gestión de las visitas, y
mucho menos, el control de las personas que entran y salen del edificio.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
31
33.. AAnnááll iissiiss ddee RReeqquuiissii ttooss
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
32
3.1. Ámbito del proyecto
Lectura de tarjetas inteligentes
El primer objetivo consiste en conseguir leer información de tarjetas inteligentes para
poder implantar una aplicación de ayuda a los vigilantes de un edificio para realizar el
registro de las visitas (descrita más adelante). Se trata de una aplicación 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 estándar de tarjetas inteligentes que se corresponden con las
tarjetas de identificación que tiene la Universidad. Para alcanzar este objetivo se parte
del código desarrollado en un proyecto fin de carrera del año anterior.
Lectura de tarjetas RFID
Debido a la gran aceptación que esta experimentando la tecnología RFID, cada vez es
más frecuente la utilización de lectores y tarjetas RFID para realizar diferentes tareas,
como por ejemplo la implantación de los controles de acceso.
Las tarjetas RFID se consideran como una alternativa que sustituirá el empleo de
códigos de barras debido a las ventajas que proporciona la tecnología RFID, destacando
entre ellas la mayor longitud de los códigos de identificación, los cuales permiten que a
cada etiqueta se le pueda asignar uno único, mientras que los códigos UPC actuales, se
limitan a un código para identificar a todas la unidades de un producto en particular.
En este sentido los códigos RFID equivalen más al número de serie de un equipo que al
número de referencia del producto, pero un número de serie que sigue un formato
compatible entre todos los fabricantes.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
33
El proyecto Sistema Control de Accesos contempla el diseño de una aplicación, 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 asignación de identificadores
unívocos, así como la introducción de información descriptiva del objeto al cual va a
identificar.
Comunicar el sistema con las bases de datos
Se han de diseñar las bases de datos necesarias para realizar el almacenamiento de la
información recogida en las lecturas de las tarjetas de identificación. Así mismo, las
bases de datos complementarán la funcionalidad de la aplicaciones que se van a diseñar.
Para ello, se dispone de un servidor Solaris/MySQL donde residirán las bases de datos
que requiere el sistema. Debido a que cada aplicación maneja un tipo de información,
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 diseñar 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 diseño 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 aplicación base de control de acceso denominada Control de
Visitas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
34
Un prototipo de dicha aplicación fue desarrollado en otro proyecto fin de carrera, sin
embargo requiere la incorporación de nuevos servicios y la mejora de los ya existentes
para proporcionar de forma eficiente su funcionalidad, así como el perfeccionamiento
del diseño inicial para proporcionar un interfaz lo suficientemente explicativo e
intuitivo. La aplicación se desarrollará bajo el lenguaje de programación 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, permitirán agilizar el trámite de la nueva
visita que realice ya que lo más probable es que solicite ver a las mismas personas que
en ocasiones anteriores.
En la segunda parte del proyecto, se ha optado por el diseño de una aplicación que
permita obtener el máximo rendimiento de las diferentes ventajas que proporciona la
tecnología RFID. Por ello, se contempla la realización de un Control de Inventario
destinado a llevar a cabo un seguimiento de los recursos que proporciona el
departamento, así como la gestión 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
identificación y la gestión 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: préstamos y devoluciones. El
tratamiento de los préstamos determina la necesidad de que esta aplicación RFID se
integre con otro sistema destinado a realizar reservas de recursos con antelación, de
manera que se gestionan tanto préstamos reservados con anterioridad como en un
momento dado.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
35
3.2. Contexto general del sistema
El contexto general del sistema debe contemplar la interacción 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 información de entrada a través de los lectores que se encontrarán
conectados en la estación de trabajo del usuario final, en este caso el bedel del
departamento del IIT.
Seguidamente, el sistema determinará la operación a realizar, en función de los
parámetros de entrada, y si se requiere, solicitará al servidor los datos de gestión,
almacenados con anterioridad, que se proporcionarán como información de salida en el
punto de atención. El sistema también 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 finalización de la operación o lo que
se considere más conveniente.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
36
3.3. Evaluación y análisis
Ante la descripción del problema que se ha realizado en los apartados anteriores, el
siguiente punto que se ha de abordar es el de evaluar la información recogida y
sintetizarla para obtener el modelo de la situación del sistema que se desea alcanzar.
Para ello, se han de estudiar tres aspectos claves:
3.3.1. Flujo de la información
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 través
tanto del lector de tarjetas inteligentes, como del lector RFID. También, el sistema
recogerá información del servidor de base de datos cuando deba mostrar datos
relevantes para continuar con la operación 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 código de retorno que informará sobre
el resultado de la operación que se haya realizado. Sólo se generará flujo de información
de salida como tal, cuando en Control de Inventario se almacenan cada uno de los
movimientos que se gestionan tras su confirmación, o cuando se desea escribir en el
TAG RFID asociado una breve descripción de algún aspecto que haya que recordar del
recurso en futuros préstamos, por ejemplo un deterioro físico de alguno de sus
componentes, o si en un préstamo no se han llevado un elemento que forma parte del
recurso entregado, por ejemplo un periférico como un ratón
3.3.2. Estructura de la información
Se entiende por estructura al contenido de los flujos de información, con el detalle
suficiente como para comprender la actuación del proceso que transforma un flujo en
otro u otros.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
37
Estructura de la Información de Control de Visitas
Los flujos de información 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 código
de identificación, el nombre y los apellidos del alumno.
Nombre: FLUJO-LECTURA
Identificador: PSCAFD. CV 2
* ID-ALUMNO: Código asignado a cada alumno cuando comienza sus estudios en
la Universidad UPCO.
* NOMBRE: Nombre del alumno identificado.
* APELLIDOS: Apellidos del alumno identificado.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
38
Nombre: FLUJO-PERSONAL
Identificador: PSCAFD. CV 3
* ID-EMPLEADO: Identificador asignado a cada uno de los empleados del IIT.
* NOMBRE: Nombre del empleado.
* APELLIDOS: Apellidos del empleado.
* EXTENSIÓN: Extensión telefónica del personal en cuestión.
* PLANTA: Planta del edificio del departamento donde se encuentra el despacho
del empleado.
* PUESTO: Número de despacho del personal al que se hace referencia.
Nombre: FLUJO-VISITAS
Identificador: PSCAFD. CV 4
* ID-EMPLEADO: Identificador asignado a cada uno de los empleados del IIT.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
39
Nombre: FLUJO-REGISTRO-VISITANTE
Identificador: PSCAFD. CV 5
* FECHA-ACTUAL: Fecha de registro de la visita realizada por ID-ALUMNO a
ID-EMPLEADO.
Estructura de la Información de Control de Inventario
Los flujos de información que se generan durante el proceso de gestión de los recursos
del departamento son los que se describen a continuación:
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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
40
Nombre: FLUJO-RECURSO
Identificador: PSCAFD.CI2
* ID-ITEM: Identificador asignado a cada uno de los recursos del departamento
disponibles para ser utilizados por cualquier empleado del mismo.
* CARACTERISTICAS: Descripción explícita de los atributos más relevantes que
definen el recurso.
* DISPOSICIÓN: Estado actual en que se encuentra el recurso, P prestable, o D
pendiente de devolución.
* ID-RFID: Identificador de la tarjeta asignada de manera única a cada uno de los
recursos que se van a gestionar.
Nombre: FLUJO-RESERVA
Identificador: PSCAFD.CI3
* ID: Identificador de la reserva.
* ID-ITEM: Identificador del recurso sobre el que se realiza la reserva.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
41
Nombre: FLUJO-RESERVA (Cont)
Identificador: PSCAFD.CI3
* DESDE-DIA: Día para el cual está previsto realizar la entrega del recurso
reservado, es decir, día en que se lleva a cabo el préstamo.
* DESDE-HORA: Representa la hora del día “DESDE-DIA” en que el usuario
recogerá el recurso.
* HASTA-DIA: Día para el cual está previsto realizar la devolución del recurso que
se ha prestado.
* HASTA-HORA: Representa la hora del día “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 día junto con la hora en que el usuario confirmó la
reserva del recurso.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
42
Nombre: FLUJO-EMPLEADO
Identificador: PSCAFD.CI4
* 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
Identificador: PSCAFD.CI5
* ID-ITEM: Identificador del recurso sobre el que se esta realizando el préstamo.
* ID-EMPLEADO: Identificador de la persona que realiza el préstamo.
* ESTADO: Identifica el tipo de movimiento del préstamo, si es una entrega o una
devolución de un recurso.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
43
Nombre: FLUJO-INST
Identificador: PSCAFD.CI6
Flujo generado cuando una persona solicita un recurso no habiendo reservado con
anterioridad, de forma que se registra el préstamo 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 comunicación con el lector: Cuando se ejecute por primera vez la
aplicación, se procederá a asignar un terminal de comunicación con el lector a
partir de la asignación de un slot particular del mismo.
• Esperar lectura: La aplicación ha de permanecer en espera activa hasta que se
introduzca una tarjeta en el lector para proceder a su identificación.
• 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
44
• 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 teléfono.
• Consultar visitas anteriores: Tras la identificación 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 aplicación proporcionará una opción de
ayuda sobre la funcionalidad de la misma.
• Finalizar la aplicación: se suministrarán dos formas de cerrar la aplicación, bien
a través de la opción de Archivo�Salir, o pulsando sobre el icono de cierre de la
ventana de la misma.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
45
• Registrar visitas adicional: Opción que se activará cuando, por motivos externos,
no se puede ejecutar la aplicación, 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 información 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 aplicación 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
aplicación el identificador del mismo, determinando ésta el recurso al que se está
haciendo referencia.
• Integrar la aplicación con el sistema de Reservas Online para que Control de
Inventario pueda gestionar correctamente, con la información necesaria, aquellos
préstamos que hayan sido reservados con antelación.
• Proporcionar la información de las reservas asociadas a un recurso: Cuando un
recurso sea identificado se mostrará la reserva más próxima al momento actual
del mismo, de forma que si el equipo está libre en ese momento, se podrá
realizar una reserva instantánea teniendo en cuenta la fecha del préstamo de la
siguiente reserva más cercana.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
46
• Registrar el préstamo de un recurso con reserva: La aplicación permitirá el
registro de una entrega tras mostrar la reserva asociada al recurso. En ese caso,
el usuario escogerá la opción de “registrar el préstamo” proporcionando toda la
información relativa al mismo, sin posibilidad de cambios, finalizando el
movimiento en el momento en que el usuario lo confirme.
• Registrar el préstamo 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 préstamo de la siguiente reserva, como se ha
comentado con anterioridad. Por ello, cuando el recurso sea identificado se
mostrará su reserva más cercana, si existe, en cuyo caso se determinará la fecha
mas tardía de devolución de dicho recurso a través de una ventana de diálogo,
donde el usuario deberá de confirmar además otros campos que definen el
préstamo.
• Registrar la devolución 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
antelación, se deberán actualizar los datos de la reserva para marcar el recurso
como libre y que puede ser reservado por otro usuario.
• Recoger información adicional sobe el estado del préstamo: Se ofrece la
posibilidad de recoger información acerca de las condiciones en que se entrega
el recurso, por ejemplo sin ratón, sin maletín…Esta información 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 aplicación: La terminación de la aplicación requiere la intervención
del usuario, de manera que se le ofrece la posibilidad de finalizarla cuando desee
o cuando lo considere necesario.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
47
3.4. Modelo Físico
3.4.1 Modelo Físico 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 configuración del
lector, y a través del cual recibe la información de la tarjeta leída en forma de una
cadena de caracteres. El usuario interactúa con el sistema arrancando y cerrando la
aplicación, así como confirmando el registro de las visitas. A su vez, el usuario es el
responsable de introducir la tarjeta en el lector.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
48
Diagrama de Contexto
El Contexto del sistema se determina mediante un gráfico de presentación, donde
aparece el Sistema de Control de Visitas, el usuario y la entidad externa correspondiente
al lector de tarjetas inteligentes.
A continuación se proporciona una descripción de cada uno de los objetos presentes en
el diagrama anterior (diccionario de datos), de manera que facilite la comprensión 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 envío de información de configuración, ya
sea para establecer el terminal como para apagarlo; y el segundo contexto es para la
transmisión de la información leída de las tarjetas
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
49
Diagrama de Contexto: PSCADFD0
Objeto: Entidad Usuario Identificador : PSCADFD0.E2
El usuario es el responsable de introducir la tarjeta de la persona que realiza la visita, y
de manipular la funcionalidad de la aplicación de control, ya sea para iniciarla y
apagarla, como para confirmar el registro de una visita determinada.
Diagrama de Contexto: PSCADFD0
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.
Diagrama de Contexto: PSCADFD0
Objeto: Orden START Identificador : PSCAO.2
Orden para arrancar la aplicación de Control de Visitas. Es generada por la entidad
USUARIO desde su puesto de trabajo.
Diagrama de Contexto: PSCADFD0
Objeto: Orden EXIT Identificador : PSCAO.3
Orden para finalizar la aplicación, iniciada por el usuario de la misma y no por motivos
de error durante el proceso de registro o de lectura.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
50
Diagrama Conceptual de Nivel 1: PSCADFD1
Objeto: Orden FIN-LECTURA Identificador : PSCAO.1
Orden generada por el sistema cuando la entidad USUARIO quiere finalizar la
aplicación (recepción de un EXIT).
Diagrama Conceptual de Nivel 1: PSCADFD1
Objeto: Orden AVISO-LECTOR-NO-
ENCONTRADO
Identificador : PSCAO.2
Orden que se envía al sistema cuando durante la configuración no se detecta o reconoce
ningún lector de tipo LTCX, probablemente motivado por la falta de instalación de los
drivers del mismo.
Diagrama Conceptual de Nivel 1: PSCADFD1
Objeto: Orden ERROR-LECTURA Identificador : PSCAO.3
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 tecnología, o porque ha
fallado la comunicación con el lector. Se informará al usuario de la existencia de este
error a través de un mensaje por pantalla, de forma que sea él mismo quien se encargue
de finalizar la aplicación.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
51
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, sólo se ha
diseñado un primer nivel debido a que los procesos no requieren explosionarse en otros
de mayor detalle.
La descripción de cada uno de los elementos que constituyen el Diagrama Conceptual
se proporciona a continuación:
Objeto: Proceso 1, Iniciar Servicio TI Identificador: PSCAP.1
Procedimiento destinado a configurar la comunicación con el lector LTCX. Dicha
configuración consiste en determinar un terminal a partir de un slot del mismo, que se
mantendrán durante todo el tiempo de ejecución de la aplicación de control de acceso.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
52
Objeto: Proceso 2, Esperar Lectura Identificador: PSCAP.2
Segundo estado de la ejecución del control de acceso, en la que la aplicación se
encuentra en espera activa de procesar una lectura y realizar su correspondiente registro
en la base de datos. En este estado de la ejecución del control de acceso, el usuario
puede proceder a finalizar la aplicación, bien porque lo desea, o porque se produjo un
error durante la lectura
Objeto: Proceso 3, Mostrar Información Identificador: PSCAP.3
Estado del control de acceso en que se proporciona la información sobre la
identificación de la persona que realiza la visita, a quién 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 identificación. 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 Identificador: PSCAP.4
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 través de su tarjeta de alumno.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
53
Objeto: Proceso 5, Consultar Personal Identificador: PSCAP.5
Proporciona información 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 Identificador: PSCAP.6
Etapa durante la fase de ejecución en la que se configuran los datos que definen la visita
que se desea registrar. Cuando el usuario confirme los datos proporcionados a través del
interfaz de la aplicación, se procederá a realizar un registro del visitante y de la visita
asociada al mismo.
Objeto: Proceso 7, Apagar Lector Identificador: PSCAP.7
Finalizar la comunicación con el lector LTCX, procediendo a su apagado.
3.4.2. Modelo Físico 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 comunicación entre ambos se caracteriza por no ser
constante, es decir, sólo intercambian información entre sí cuando se desea identificar
un recurso o cuando se escriben las condiciones del préstamo en el TAG RFID.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
54
El usuario además de arrancar y cerrar la aplicación, es responsable de iniciar el registro
de los movimientos de recursos que tengan lugar. Dicho inicio se realiza con la
identificación del recurso seguido de asignación de la reserva correspondiente
determinando si se trata de una entrega o de una devolución.
Si se va a efectuar una entrega o devolución, según corresponda, el usuario deberá
indicárselo a aplicación pulsando el botón que se haya habilitado para tal fin, siendo la
propia aplicación quien se encargue de verificar las condiciones del préstamo y de
registrar el movimiento que se ha gestionado.
Diagrama de Contexto
El gráfico de presentación del Sistema Control de Inventario queda definido por el
propio sistema, junto con el usuario y el lector RFID.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
55
Con el objetivo de facilitar la comprensión del contexto del sistema se realiza a
continuación una breve descripción de los objetos que intervienen en el Diagrama de
Contexto anterior, y que forman parte del diccionario de datos del sistema final.
Diagrama de Contexto: PSCADFD0
Objeto: Entidad Lector RFID Identificador : PSCADFD0.E1
El lector de RFID se encuentra conectado al sistema a través de un cable USB. La
comunicación entre ambos sólo se establecerá cuando el sistema permanezca en estado
de espera o cuando se desee registrar las condiciones del préstamo en el TAG RFID.
Cuando el sistema se encuentre en estado de espera, bien al inicio de la aplicación o
porque se haya solicitado una nueva lectura, se enviará la orden de SOLICITUD, más
concretamente de lectura, de manera que en un nivel más bajo, el lector permanecerá a
la espera de detectar un TAG, y proceder a su identificación 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
56
Diagrama de Contexto: PSCADFD0
Objeto: Entidad Usuario Identificador : PSCADFD0.E2
El usuario es el elemento del sistema que interactúa constantemente con él. Es el
responsable de aproximar el TAG RFID al lector, de realizar la gestión del movimiento
definiendo los parámetros del mismo, y de confirmarlo para llevar a cabo su registro en
la base de datos correspondiente.
Diagrama de Contexto: PSCADFD0
Objeto: Orden START Identificador : PSCAO.1
Orden para arrancar la aplicación de Control de Inventario. Es generada por la entidad
USUARIO desde su puesto de trabajo.
Diagrama de Contexto: PSCADFD0
Objeto: Orden EXIT Identificador : PSCAO.2
Orden para finalizar la aplicación, iniciada por el usuario de la misma y no por motivos
de error durante el proceso de registro o de lectura.
Diagrama de Contexto: PSCADFD0
Objeto: Orden SOLICITUD Identificador : PSCAO.3
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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
57
Diagrama de Contexto: PSCADFD0
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 envía el
sistema constituyendo el flujo de datos TRAMA.
• ESCRIBIR: El sistema envía esta orden cuando desee escribir en la memoria
interna de la tarjeta.
Diagrama de Contexto: PSCADFD0
Objeto: Orden OPERACION Identificador : PSCAO.4
Orden generada por la entidad USUARIO para determinar el siguiente estado del
sistema. Esta orden tiene tres posibles valores:
• REGISTRAR: Opción 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 devolución de un recurso, de manera que
cuando la aplicación informe de dicho estado, se habilita la opción
correspondiente para que confirme el movimiento, y así poder actualizar la base
de datos de acuerdo a la gestión realizada.
• LEER: El USUARIO solicita una nueva lectura, de forma que el sistema cambia
al estado de espera para identificar un nuevo recurso
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
58
Diagrama Conceptual de Nivel 1
El Diagrama Conceptual correspondiente al Sistema Control de Inventario se define en
más 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 definición del diagrama se determina en dos niveles, siendo el nivel 2 el
correspondiente a la explosión del proceso de Registrar Movimiento.
En el nivel de detalle 1 se puede observar el ciclo de vida de la gestión de un
determinado recurso. Dicho nivel se muestra a continuación:
Las descripciones de los procesos de nivel 1 de detalle que completan el diccionario de
datos son las siguientes:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
59
Objeto: Proceso 1, Mostrar estado actual
de los recursos
Identificador : PSCAP.1
Cada vez que se inicia por primera vez la aplicación, o se finaliza la gestión de un
movimiento, se muestra la disposición 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.
Objeto: Proceso 2, Esperar Lectura Identificador: PSCAP.2
Estado lógico en el que se encuentra el sistema cuando no gestiona ningún movimiento.
Dicho estado permite atender una nueva petición 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 aplicación al lector
RFID, responsable de detectar una nueva tarjeta, que tras su identificación y lectura se la
transmite al sistema en forma de TRAMA, recuperando de nuevo el control de la
aplicación.
Objeto: Proceso 3, Identificar Recurso Identificador: PSCAP.3
Después que el lector haya realizado la correspondiente lectura del TAG detectado,
envía al sistema el identificador y los datos leídos del mismo. Cuando el sistema recibe
la TRAMA, lo primero que realiza es la identificación del código recibido. Si éste se
corresponde con alguno de los recursos del departamento se procederá a registrar el
movimiento en cuestión, pero si no se corresponde con ninguno el sistema solicitará una
nueva lectura cambiando de nuevo al estado de “Esperar Lectura”.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
60
Objeto: Proceso 4, Mostrar reserva
asociada
Identificador : PSCAP.4
Seguidamente a la identificación del recurso, se determina el tipo de movimiento que se
va a gestionar, si entrega o devolución de un recurso, y tras ello se proporciona la
reserva correspondiente más próxima a la fecha actual.
Si el recurso está disponible, se mostrará la reserva más cercana a la fecha actual,
considerando para ello la fecha de realización del préstamo.
Si el recurso no está disponible, se proporcionará la reserva asociada al préstamo que se
va a gestionar como devolución del recurso.
Objeto: Proceso 5, Registrar movimiento Identificador: PSCAP.5
Realiza el registro en la base de datos del movimiento que se ha gestionado, de manera
que la información almacenada sea coherente con el estado actual de los recursos y de
sus correspondientes reservas.
Diagrama Conceptual de Nivel 2
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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
61
Las descripciones de cada uno de los procesos que constituyen el diagrama anterior y
que completan el diccionario de datos del diseño del sistema, se proporcionan a
continuación:
Objeto: Proceso 1, Confirmar movimiento Identificador : PSCAP.5.1
Estado en el que se encuentra el sistema después de mostrar la información 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 confirmaría que la reserva que se ha
mostrado corresponde con el tipo de movimiento que se está gestionando.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
62
Objeto: Proceso 2, Registrar préstamo Identificador: PSCAP.5.2
El movimiento se corresponde con la entrega de un préstamo, de forma que cuando el
USUARIO confirme que desea registrarlo se deberá de mostrar una ventana de diálogo
con los datos necesarios que definen el préstamo.
Objeto: Proceso 3, Registrar préstamo
instantáneo
Identificador : PSCAP.5.3
El registro del préstamo se corresponde con la entrega de un recurso no reservada. Por
ello, la ventana de diálogo deberá de mostrar la fecha de devolución más tardía respecto
de la fecha de realización del próximo préstamo, 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
préstamo y se actualizará toda la información correspondiente al estado de los recursos y
del movimiento que se acaba de gestionar.
Objeto: Proceso 4, Registrar préstamo con
reserva
Identificador : PSCAP.5.4
El registro del préstamo a realizar tiene una reserva asociada. Cuando el USUARIO
confirme el movimiento se mostrará una ventana de diálogo que informa sobre los datos
de la reserva que se está llevando a cabo, sin proporcionar posibilidad a cambios.
Tras la confirmación del USUARIO se registrará el movimiento en la base de datos,
actualizando el estado del recurso prestado.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
63
Objeto: Proceso 5, Registrar devolución Identificador: PSCAP.5.5
El movimiento a gestionar se corresponde con la devolución de un recurso. La
aplicación internamente verificará si dicha devolución se realiza en el día acordado o se
corresponde con una fecha más temprana a la registrada, en cuyo caso deberá de
actualizarse la duración de su reserva para permitir el préstamo 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 Identificador: PSCAP.5.6
Estado en el que se encuentra el sistema tras la gestión de un recurso. Se espera que el
USUARIO seleccione una nueva lectura, o en caso contrario, finalice la aplicación
saliendo del sistema.
3.5. Modelo Lógico
El objetivo del modelo lógico 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 físicos, que aparecen en el modelo físico.
3.5.1. Modelo Lógico de Control de Visitas
En el modelo físico se han definido siete procesos, considerando los aspectos físicos
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. También contempla de manera
independiente la obtención de los dos flujos de información 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
64
Como se ha comentado con anterioridad, el diseño del modelo lógico requiere la
selección de los procesos más importantes, desde el punto de vista del funcionamiento
del negocio, y la eliminación de los aspectos físicos. Por ello, el modelo lógico
correspondiente al subsistema de Control de Visitas sólo 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 cómo se realiza la lectura, si es
necesario realizar una configuración de la comunicación, o si se encuentra en espera
activa de lecturas.
El proceso Obtener Información Visita contempla la información que es necesaria
proporcionar al usuario para que pueda determinar los datos correspondientes a la visita
que se va a registrar.
En el modelo físico se desglosó en tres puntos claramente diferenciados, mientras que
en el modelo lógico se divide en dos: la identificación del visitante procedente del
proceso 1, y el resto se proporciona en el segundo proceso ya que se considera como
homogénea, 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 información es el
mismo.
A su vez, Obtener Información Visitas es responsable de recibir la confirmación de la
visita tratada, y de registrarla en la correspondiente base de datos.
El diagrama que representa el Modelo Lógico de Control de Visitas, descrito con
anterioridad, se muestra a continuación:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
65
3.5.2. Modelo Lógico de Control de Inventario
El modelo lógico de un sistema no debe representar la forma (el cómo) en que éste
realiza los servicios que se ofrecen al usuario final. Por este motivo, se han definido los
procesos más importantes del Modelo Físico de Control de Inventario que permiten
representar qué hace el sistema, eliminando aquellos procesos que pertenecen más al
ámbito físico.
El diagrama lógico final del Sistema de Control de Inventario consta de 5 procesos que
en conjunto explican el proceso de gestión 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
66
Siempre que el sistema no este procesando una determinada tarea, se encontrará en un
estado de espera, el cual implica la comunicación con el lector para solicitar la lectura
de un TAG RFID. Lógicamente, a pesar de que el lector opere en un nivel inferior al de
la aplicación, también permanece esperando a realizar la lectura de una tarjeta. El
cambio de estado del sistema es motivado por la identificación y lectura de un TAG,
información 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
sistemática: 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 gestión finaliza cuando el usuario confirma el movimiento, hecho que
determina la actualización 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,
repitiéndose de nuevo todo el proceso anterior.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
67
3.6. Modelo Conceptual de datos
La información de los flujos de datos, almacenes, registros, y atributos del modelo
lógico permiten identificar las entidades de datos del sistema. El modelo conceptual de
datos determina cuáles son las familias o entidades de datos del negocio, sus relaciones
y atributos más 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 precisión, 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-relación
En el subsistema Control de Visitas se definen dos entidades sobre las que se almacena
información relevante, y a las que se puede identificar de manera unívoca: Visitante y
Empleado, cuya asociación da lugar a la relación Visita. Por lo que el modelo de
entidad-relación correspondiente a Control de Visitas es el siguiente:
Un visitante puede realizar una o más 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 físicas, ya que son entidades que se
corresponden con entes externos en la realidad.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
68
ENTIDAD: VISITANTE IDENTIFICADOR: PSCAMCD.CVE1
Descripción:
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
identificación del mismo para definir la visita que se va a realizar, y así poder
registrarla.
Composición:
ENTIDAD: EMPLEADO IDENTIFICADOR: PSCAMCD.CVE2
Descripción:
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 día.
Composición:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
69
RELACIÓN: VISITA IDENTIFICADOR: PSCAMCDCV.R1
Descripción:
Una visita queda representada a partir de las entidades de Visitante y Empleado, los
cuales son los objetos físicos 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.
Composición:
Diseño de Tablas
Con el objetivo de garantizar que los datos están organizados con la menor redundancia
posible y minimizando la probabilidad de anomalías en la actualización de los datos, se
han definido tres tablas:
• USUARIOS: Recoge los datos de cada uno de los empleados del departamento.
• VISITANTES: Alberga la información que define a cada persona que realiza
una visita.
• LOG_VISITAS: Almacena todas las visitas que se registran en el departamento.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
70
3.6.2. Modelo Conceptual de datos de Control de Inventario
Modelo entidad-relación
El modelo entidad-relación correspondiente al Sistema Control de Inventario está
formado por dos entidades: recurso y empleado, ya que responde a la situación 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 interacción directa entre las dos
entidades.
La relación “Reserva” surge de la necesidad que tiene un empleado de reservar un
recurso para un determinado día, una serie de horas o de días. Esta relación permite
controlar los préstamos que se han de realizar a lo largo de cada jornada laboral.
Además, es la responsable de contextualizar las condiciones del préstamo: duración,
motivo…
La segunda relación, “Préstamo”, representa básicamente el movimiento: un empleado
recibe o devuelve un determinado recurso. No existe ninguna relación entre “Reserva” y
“Préstamo” ya que un recurso se puede prestar si estar reservado.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
71
A continuación se realiza una descripción del conjunto de objetos que constituyen el
modelo conceptual de datos, y que completan el diccionario de datos del diseño del
sistema.
ENTIDAD: EMPLEADO IDENTIFICADOR: PSCAMCDCI.E1
Descripción:
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 día.
Composición:
ENTIDAD: RECURSO IDENTIFICADOR: PSCAMCDCI.E2
Descripción:
Representa a cada uno de lo bienes materiales que constituyen el inventario que el
departamento del IIT deja a disposición de sus empleados.
Composición:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
72
RELACIÓN: RESERVA IDENTIFICADOR: PSCAMCDCI.R1
Descripción:
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 día, además de gestionar adecuadamente cada préstamo
o devolución, garantizando la coherencia con la realidad.
Composición:
RELACIÓN: PRÉSTAMO IDENTIFICADOR: PSCAMCDCI.R2
Descripción:
Un préstamo representa el tipo de movimiento que se gestiona: bien la entrega de un
recurso, o una devolución. Esta relación permitirá llevar a cabo un control de los
movimientos que realmente se realicen cada día.
Composición:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
73
Diseño 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 gestión 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.
• Préstamos: Registra todos los movimientos que se llevan a cabo sobre un
determinado recurso.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
74
44.. EEssttuuddiioo ddee llaa AArr qquuii tteeccttuurr aa
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
75
4.1. Especificación de la tecnología 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 tecnologías, así como de las
características de cada uno de los lectores.
4.1.1. Tarjetas Inteligentes
4.1.1.1. ISO 7816
La Organización Internacional de estándares (ISO) dictamina en su estándar número
7816 toda la información de regulación y control de normas acerca de las Tarjetas
Inteligentes de contacto.
El estándar ISO7816 está dividido en cuatro apartados diferentes:
1. ISO7816-1: Características físicas del circuito integrado.
En este apartado se estudian las características físicas de las tarjetas inteligentes de
contacto. A continuación, se describen las más importantes:
• Luz Ultra Violeta: Cualquier protección contra cualquier nivel de rayos UV, será
responsabilidad del fabricante de la tarjeta.
• Rayos X: La exposición de cualquiera de los dos lados de la tarjeta a una dosis
de 0.1 Gy relativo a una radiación de energía media de rayos X de 70 a 140 KV
(dosis acumulativa por año) no deberá causar mal funcionamiento de la tarjeta.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
76
• 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 Mecánica: La tarjeta deberá resistir daños sobre su superficie, por presión
causada por una bola de acero de 1.5mm de diámetro en la cuál se aplica una
fuerza de 1.5 N.
• Resistencia eléctrica: Toda la resistencia eléctrica medida entre dos puntos
cualquiera de los pines, no deberá sobrepasar los 0.5 Ohm, con cualquier valor
común de 50 uA a 300 mA.
• Campo magnético: El chip de la tarjeta no deberá ser dañada por campos de
estática magnética de 79500 A.tr/m.
• Electricidad estática: El chip de la tarjeta no deberá ser dañado por descargas
eléctricas de 1500 V y de 100 pF y tendrá 1500 Ohms.
También se contemplan aspectos como la inflexión máxima de la tarjeta o los distintos
tamaños permitidos:
• Inflexión máxima de la tarjeta:
Largo de la tarjeta
Deformación (f): 2 cm
Periodicidad: 30 Inflexiones por minuto
Ancho de la tarjeta
Deformación (f): 1 cm.
Periodicidad: 30 Inflexiones por minuto
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
77
• Tamaños:
2. ISO7816-2 define las dimensiones y la posición de los contactos.
Esta parte define el número, función y posición de los contactos eléctricos. El circuito
integrado (ICC) tiene 8 contactos eléctricos.
A continuación se adjunta una tabla que contiene la definición de los 8 contactos acorde
con la ISO 7816-2:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
78
3. ISO7816-3 define las señales eléctricas y los protocolos de transmisión.
Como protocolos de transmisión se contemplan hasta 16, pero sólo se utilizan dos:
• T=0: Protocolo asíncrono orientado a carácter. Es el más usado (por ejemplo
GSM), aunque se requieren dos transacciones para recibir datos.
• T=1: Protocolo asíncrono orientado a bloque de datos. En este caso solo se
requiere de una transacción 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 específicas y/o adicionales de la ISO.
• Lenguaje de comunicación con la tarjeta JavaCard, PCSC10 ...
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
79
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 información. El segundo es el tipo de contacto que tiene la tarjeta para
entrada y salida.
1. Clasificación 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 lógica con que
modifican internamente los datos que pueden almacenar, aunque se podrían dividir en
sólo dos grupos: tarjetas de memoria, que son el modelo más simple y más económico
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 más 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 más simple y más económico de implementar.
Un ejemplo de uso de estas tarjetas son las tarjetas de cabinas telefónicas, estas vienen
con un importe grabado de fábrica y al realizar la llamada, la cabina va disminuyendo el
importe por cada minuto de uso.
Tarjetas de memoria con lógica 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
80
Tarjetas con procesador y memoria
Este tipo de tarjetas tienen un chip microprocesador que puede contener un microcódigo
que define una estructura de comando, una estructura de archivos y una estructura de
seguridad. Estas tarjetas pueden añadir, borrar y, de alguna manera, manipular
información en su memoria. Pueden ser vistas como un computador en miniatura con un
puerto de entrada/salida, sistema operativo y disco duro.
2. Clasificación por el tipo de contacto
Existen fundamentalmente dos tipos de tarjetas en función de cómo se realice la
comunicación entre el lector y la tarjeta, tarjetas de contacto y tarjetas sin contacto,
aunque también se pueden encontrar tarjetas híbridas 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 eléctricos pueda ser leída. En la primera imagen puede observarse los 8
contactos con los que está formada una Tarjeta Inteligente definidos en la ISO 7816-2.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
81
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 transmisión en la capa lógica y física. La
comunicación entre el lector y la tarjeta se realiza a través de señales electromagnéticas
sin necesidad de ningún tipo de contacto.
Una de las ventajas que presenta este tipo de tarjetas es que no existen contactos
externos, por lo que es más 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 comunicación se establece por ondas de
radio. Muchas tarjetas sin contacto también obtienen la energía para su microchip
interno a través del campo electromagnético creado por el lector.
Este tipo de tarjetas se estudiarán con más detalla en el punto correspondiente a la
Tecnología RFID.
Tarjetas híbridas
Como una categoría derivada están las tarjetas que envuelven las dos categorías que
emplean contacto y las que no. Una tarjeta híbrida tiene dos microchips, cada uno con
su respectiva interfaz para contacto y transmisión por radio.
Los dos chips no están conectados, pero para muchas aplicaciones, este híbrido 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
82
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 raíz 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 según la normativa ISO, la
“0x3F00”.
• Fichero Dedicado (DF): Estos ficheros podríamos 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 aplicación 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 tamaño debe ser fijado cuando este es
creado, por lo que un estudio previo de la estructura de ficheros es esencial.
4.1.1.4. Métodos de Acceso a la Tarjeta Inteligente
Las librerías de OpenCard permiten la comunicación, por medio de un lector, entre una
Tarjeta Inteligente y una aplicación Java. Estas librerías nos ofrecen dos métodos 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 según el protocolo de la aplicación (APDU), y el otro método es más
abstracto ya que se realiza por medio de unas clases de Java.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
83
Este último conjunto de clases(CardTerminal, CardFile, etc…) permite interactuar con
el lector a partir de la utilización de los métodos que las constituyen proporcionándole
los parámetros necesarios para obtener la información de la tarjeta leída. Para poder
utilizar este forma de comunicación hay que asegurarse de que la Tarjeta Inteligente que
se va a utilizar soporta este acceso. Para llevar a la práctica el Control de Visitas se
utilizará el primer método, debido a que la tarjeta de Comillas no soporta el segundo
método 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 instrucción, por ejemplo si esta es conforme a la ISO
7816 ó es una instrucción en propiedad. También sirve para indicar si se está utilizando
privacidad a la hora de enviar el mensaje.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
84
El valor correspondiente a INS, de un byte indica el comando a emplear:
Los bytes P1 y P2 indican parámetros específicos del comando, y su presencia en el
comando es obligatoria.
El campo LC indica la longitud del comando, del tamaño de un byte. También puede
espesar en bytes la longitud del campo de datos opcional.
La referencia de Datos Opcionales se utilizaría 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
información de estado, y adicionalmente un campo opcional.
Tanto en los APDU de comando como en las de respuesta, los parámetros que se envíen
siempre se encontrarán expresados en cantidades basadas en el sistema hexadecimal.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
85
4.1.1.5. Lector de tarjetas inteligentes: LTCX
Aspectos técnicos 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. Además
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 estándar USB CCID, de manera
que el lector no requiere de software añadido (drivers) en sistemas
operativos Linux, Mac OS y Windows, que ya contemplan este estándar en sus
distribuciones.
Otra característica relevante es que se garantiza la compatibilidad y funcionalidad futura
del lector, ya que su tecnología permitirá actualizaciones de forma remota. Es
importante señalar que esta actualización del lector se ha desarrollado teniendo
especialmente en cuenta el futuro uso del DNI electrónico, optimizándolo para ello.
También se encuentra disponible en versión serie (RS232).
Las características técnicas del lector son las siguientes:
• Dispositivo lector y grabador de tarjeta chip conectado al ordenador.
• Instalación en modo Plug and Play para el sistema operativo Windows.
• Diseño de reducidas dimensiones y de poco peso, que facilita su portabilidad y
ubicación.
• Base plana para su posible sujeción a otros dispositivos externos, como por
ejemplo el teclado, el ordenador, etc.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
86
• Carcasa de PVC ligero y resistente a golpes.
• Diseñado especialmente para su utilización en entornos de certificación con
firma digital.
• Provisto de una CPU CMOS de 8 bits.
• Consta de dos LEDS señalizadotes: uno verde y otro rojo.
• Alimentación 5V DC del propio ordenador.
• Soporta velocidades de comunicación entre 9600bps y 115200bps
Tarjetas soportadas
Soporta las tarjetas más utilizadas actualmente en el mercado:
• Tarjetas asíncronas protocolo T=0 (GSM, VisaCash, Euro6000, Tarjeta
Criptográfica, etc.)
• Tarjetas asíncronas protocolo T=1 (German Geldkarte)
• Tarjetas de memoria del tipo SLE4442 (referencia C3P2K)
• Cualquier otro tipo de tarjeta bajo demanda.
4.1.2. Tecnología 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 tecnología RFID.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
87
Un sistema RFID consiste en un tag RFID incorporado en cada objeto que se desea
controlar, por ejemplo un ordenador portátil, y en un aparato lector fijo o portátil que lee
dichos TAGS. Estos componentes utilizan ondas de radio frecuencia para intercambiar
información, lecturas o escrituras. Una vez leído el TAG, los datos puede transmitirse
por las redes estándares a las base de datos, o pueden requerirse para notificar a un
controlador programable para que ejecute alguna acción, como por ejemplo registrar la
entrada o salida de un recurso del edificio donde se encuentra instalado el sistema.
Básicamente un SISTEMA RFID los constituyen los siguientes elementos:
• Uno o más Tags (transponder) que incluye un chip semiconductor y una antena.
• Uno o más dispositivos de Lectura/escritura (interrogadores o lectores).
• Dos a más antenas, una en el tag y otra en el dispositivo de Lectura/Escritura
• Un software de Aplicación y una estación de trabajo (Host).
Para poder llevar a cabo la transmisión de datos entre la tarjeta y el lector RFID se
deben encontrar próximos y trabajar en el mismo rango de frecuencia.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
88
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 batería para su
alimentación (por ejemplo el control de autopistas), y los pasivos, que se alimentan por
el campo magnético 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 más.
2. El campo de radiofrecuencia genera una corriente eléctrica sobre la bobina
de recepción del dispositivo. Esta señal es rectificada y de esta manera se alimenta el
circuito.
3. Cuando la alimentación llega a ser suficiente el circuito transmite sus datos.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
89
4. El interrogador detecta los datos transmitidos por la tarjeta como una
perturbación del propio nivel de la señal.
La señal recibida por el interrogador desde la tarjeta está a un nivel de -60 db por debajo
de la portadora de transmisión. El rango de lectura para la mayoría de los casos está
entre los 30 y 60 centímetros de distancia entre interrogador y tarjeta.
Las variables críticas en un sistema RFID son las siguientes: el rango de frecuencia de
la comunicación, el tamaño de la información contenida en el tarjeta, la velocidad a la
que se establece la comunicación con el TAG, la forma física del TAG, la capacidad del
sistema para comunicarse “simultáneamente” con múltiples TAGS, y la robustez de la
comunicación respecto a las posibles interferencias existentes entre el lector y la tarjeta.
Los factores a tener en cuenta para implantar la tecnología RFID consideran los niveles
legales y regulados de emisión permitida en el país de uso, si se incluye o no una batería
en el propio TAG para mejorar su comunicación con el lector, y la frecuencia de
portadora de RF utilizada para transportar la información entre el TAG y el lector.
4.1.2.2. Protocolos y opciones
Normalmente el sistema de modulación utilizado es modulación de amplitud (AM) con
codificación tipo Manchester NRZ. Para conseguir mayor alcance y más inmunidad al
ruido eléctrico, se utilizan sistemas más sofisticados: en algunos casos se divide la
frecuencia del reloj de recepción.
La mayor parte de los TAGS tienen una memoria EEPROM donde se almacenan datos.
En algunos casos llevan datos grabados de fábrica y en otros también hay datos que
puede grabar el usuario. Cada vez es más habitual, implantar sistemas que utilizan
encriptación de clave pública para conseguir mayor seguridad ante posibles escuchas
maliciosas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
90
Por otro lado podemos encontrar sistemas anticolisión que permiten leer varias tarjetas
al mismo tiempo. En caso de que varias tarjetas estén en el rango de alcance del
interrogador y empiecen a transmitir al mismo tiempo, se produce una colisión.
El interrogador detecta la colisión y manda parar la transmisión de las tarjetas durante
un tiempo. Después irán respondiendo cada una por separado después 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 alimentación o no:
Pasivas: Caracterizadas por no tener fuente de alimentación propia. La mínima corriente
eléctrica, inducida en la antena por la señal de escaneo de radiofrecuencia, proporciona
suficiente energía al circuito integrado CMOS de la etiqueta para poder transmitir una
respuesta. Debido a las limitaciones de energía, la respuesta de una etiqueta pasiva
RFID es necesariamente breve, normalmente apenas un número de identificación. La
falta de una fuente de alimentación propia hace que el dispositivo pueda ser bastante
pequeño. Las etiquetas pasivas, en la práctica tienen distancias de lectura que varían
entre unos 10 milímetros hasta cerca de 6 metros dependiendo del tamaño 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 además una pequeña
batería. Esta batería permite al circuito integrado de la etiqueta estar constantemente
alimentado. Además, elimina la necesidad de diseñar una antena para recoger potencia
de una señal entrante. Por ello, las antenas pueden ser optimizadas para la señal de
backscattering. Las etiquetas RFID semi-pasivas responden más rápidamente dado que
su razón de lectura es mayor que las con las etiquetas pasivas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
91
Activas: Tienen una fuente de energía, lo que le permite alcanzar rangos mayores,
albergar memorias más grandes que las etiquetas pasivas, e incrementar la capacidad de
poder almacenar información adicional enviada por el transmisor-receptor. Muchas
etiquetas activas tienen rangos prácticos de diez metros, y una duración de batería de
hasta varios años. Por ejemplo los TAGs de las autopistas.
Por otro lado, las etiquetas RFID también se clasifican según 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
regulación estándar para su utilización.
• 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 número de serie de
la tarjeta, y por otro lado se cuenta con una memoria adicional, que está disponible para
otros datos que pueden ser añadidos o actualizados en otras ocasiones.
Lectura de las Etiquetas
Los lectores de RFID o “interrogadores”, utilizan ondas de radio para leer la
información almacenada en la etiqueta. El lector puede ordenar a la etiqueta transmitir
la información que tiene almacenada, o bien la etiqueta puede transmitir la información
que contiene de manera periódica.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
92
Los lectores pueden ser portátiles o fijos, aunque también pueden estar integrados en
otros equipos, como por ejemplo en terminales handheld. Con el objetivo de mantener
cierta privacidad, la información 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 aplicación que utilizará los datos del tag identificado,
para llevar a cabo las funciones del sistema implantado dicha aplicación recibe el
nombre de Object Name Service (ONS)
4.1.2.4. Estándar Mifare
Los TAGS RFID que se utilizarán 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 específica de almacenamiento.
Una tarjeta que cumple con el estándar MIFARE está conformada por 16 sectores,
donde cada sector posee 4 bloques de 16 bytes.
El bloque cero del sector cero es de sólo lectura, donde se almacena la información del
número serial de la tarjeta o Card ID, datos del fabricante e información de control. Los
bloques finales de cada sector (3, 7, 11,..,63) almacenan los datos de configuración de
cada sector.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
93
Estos datos de configuración incluyen las claves de acceso A y B como también las
condiciones de acceso al sector. Este bloque recibe el nombre de Sector Trailer.
A continuación se presenta un esquema de la distribución de la memoria de las tarjetas
inteligentes que cumplen con el estándar 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 conectarán el lector
de tarjetas inteligentes, y el lector RFID, a través de dos puertos USB.
4.2. Especificación de la tecnología software y de comunicaciones
El software necesario para que las aplicaciones se puedan ejecutar en la máquina del
usuario final es el siguiente:
• Los drivers de cada uno de los lectores, que se encontrarán en una ubicación
específica en dicho ordenador.
• La máquina virtual de Java, JVM, elemento necesario para que se pueda llevar
a la práctica cualquier programa Java.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
94
Las comunicaciones necesarias para implantar el Sistema Control de Accesos son
básicamente las de acceso al Servidor de BBDD que se encuentra localizado en el
departamento del IIT.
4.3. Arquitectura final del sistema
La arquitectura del sistema está formada por cinco niveles claramente diferenciados
entre sí, a través 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 continuación, se
procede a describir cada uno de los niveles:
• Tarjetas: Constituye la entrada de datos en el sistema, actividad indispensable
para la etapa de identificación de cada uno de los dos controles que se realizan.
En el caso RFID, las tarjetas también son destino de información, ya que cuando
se registra algún movimiento de un recurso se escribe en el TAG
correspondiente un texto de observaciones.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
95
• Lectores: Son los dispositivos que se comunican con las tarjetas de
identificación, y son responsables de retransmitir la información leída en cada
lectura al sistema, para que éste último la procese.
• Middleware: Nivel intermedio destinado a traducir la información que recibe de
los dispositivos, y a retransmitir la conversión de dicha información a la
aplicación 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 desempeña el perfil de estado intermedio, ya que por un lado se comunica
con el lector RFID, y por otro con la aplicación 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 aplicación 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, registrándolos, 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. Evaluación Económica
La viabilidad económica considera tanto la inversión en el proyecto, como el gasto que
supone. Un estudio detallado del factor económico se realiza en base al llamado
Análisis 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
96
Con los costes y beneficios cuantificados se define la rentabilidad del proyecto mediante
consideraciones de amortización: tiempo requerido para recuperar el dinero invertido en
el proyecto. Sin embargo, debido a las características particulares del presente proyecto
como proyecto fin de carrera, no corresponde la realización de este aspecto al no existir
inversión alguna. Aun así, se proporcionará el estudio de amortización que le
correspondería como proyecto real.
Todos estos cálculos requieren un conocimiento sobre el valor actual del dinero, su
tendencia en el futuro, y otros aspectos monetarios que influyen en un análisis de este
tipo. Por este motivo, el Análisis de Coste/Beneficio resulta laborioso de realizar debido
a los criterios variables que se han de aplicar, por las características del sistema que se
está diseñando, el tamaño y complejidad del proyecto, y la recuperación esperada de la
inversión (ROI). Sin embargo, desde el punto de vista del estudio de diferentes
alternativas, para determinar qué solución supone más coste para el proyecto, es
suficiente con tener en cuenta sólo los beneficios tangibles. Dichos beneficios son:
1. Costes de implantación.
• 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 producción, una vez desarrollado
el sistema. Particularizando en este proyecto, no se cuenta con este coste si
consideramos como métrica 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
97
Tras la instalación, se llevan a cabo las pruebas pertinentes para confirmar y
garantizar el correcto funcionamiento de las aplicaciones.
• Costes de formación: Enseñar 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 formación para la utilización de las
herramientas finales: se le enseñará personalmente la metodología de cómo
manejar el sistema.
2. Costes de adquisición de tecnología.
• Coste del hardware: Coste del equipo para el nuevo sistema, considerando los
costes de instalación y mobiliario. Por ello, en este coste se debe tener en cuenta
la adquisición 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 cálculo, bases de datos,
sistemas operativos, cambios de versión de herramientas…En 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 acompañados por sus correspondientes
drivers.
• Coste de las comunicaciones: Instalación de redes locales, unidades de control
de transmisión o equipos de comunicación 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: sólo necesita comunicarse
con el servidor de base de datos para gestionar correctamente los flujos de datos
de entrada y de salida que se generarán en cada uno de los controles
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
98
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 explotación 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 energía 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 Evaluación 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 parámetro, obteniéndose como suma de
cada uno de ellos, el valor del coste total de la solución tecnológica que se ha elegido.
Cuando no pueden barajarse datos numéricos más o menos fiables, no cabe la
posibilidad de establecer la viabilidad económica del proyecto, pero sí se puede realizar
una estimación 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 más de una.
En muchas ocasiones, en lugar de valorar numéricamente cada uno de los factores, se
les asigna un valor simbólico: ++ 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 Evaluación de Costes correspondiente al proyecto que se está diseñando es
la siguiente :
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
99
Alternativa € (euros)
Costes de Implantación
Costes de Desarrollo 38010
Costes de puesta en marcha 1000
Costes de Formación 20
Costes de Tecnología
Costes del Hardware 550
Costes del Software 0
Costes de Comunicaciones 0
Costes Operacionales
Costes del C.P.D 0
Costes de Mantenimiento y
mejora 0
Costes Totales 39580
4.5. Elaboración del Plan de Proyecto
Definida ya la tecnología hardware, software y de comunicaciones que se ha elegido
utilizar, se procede a realizar la planificación general del resto de etapas: Diseño
Externo, Diseño Interno, Programación, Pruebas e Implantación.
Con la información y conocimiento que se tiene del proyecto en este momento, resulta
más segura y fiable una planificación detallada de cada una de las etapas que quedan
por realizar. Por tanto, debe actualizarse la planificación general realizada al comienzo
del proyecto, y adecuarla a las condiciones actuales establecidas por la solución a
desarrollar. Aún así pueden producirse cambios sustanciales a lo largo del desarrollo de
una etapa. Por este motivo, el proceso de planificación es una tarea cíclica y permanente
durante el desarrollo del proyecto. A continuación, se muestran el ciclo de planificación
del proyecto:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
100
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 específica el objetivo de cada una de ellas, considerando al mismo tiempo sus
duraciones para garantizar que la finalización del proyecto se encuentra dentro del plazo
previsto.
La revisión 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 están relacionados con el tiempo, ya que si no se cumplen con las
expectativas determinadas para cada etapa se deberá reestructurar la planificación.
La metodología de desarrollo que se está siguiendo es lineal aunque evidentemente la
revisión del plan definido sea cíclica 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 ejecución de tales actividades, y la duración de
cada una. A continuación se muestra el plan de actividades:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
101
La secuenciación de las actividades es lineal, de forma que no se admiten alteraciones
en la planificación en las mismas ya que determinan un camino crítico en el proceso de
desarrollo que se ha de realizar a partir de este momento. La finalización de las cuatro
actividades en conjunto se llevaría a cabo el día 151, considerando como día de inicio el
comienzo de la etapa de Diseño Externo. Además, se ha de tener en cuenta la actividad
de Gestión del Proyecto definida en el Plan de Gestión del apartado 1, ya que se su
realización es constante a lo largo de todo el desarrollo del proyecto. La duración de las
actividades en este punto se ha estimado en semanas, ya que permite estimar con más
facilidad el trabajo que queda por realizar así como el tiempo existente para llevarlo a
cabo con el objetivo de satisfacer la planificación 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 información se
encuentra recogida en la tabla de asignación de recursos que se estimó en el comienzo
del proyecto en el Plan de Gestión del mismo.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
102
55.. DDiisseeññoo EExxtteerr nnoo
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
103
A partir de la plataforma tecnológica elegida en el Estudio de la Arquitectura, en esta
fase se completarán los requisitos físicos del sistema final, se diseñarán las entradas y
salidas, se completará la especificación de los procesos del modelo, y se elaborará el
modelo lógico de datos, a partir de los volúmenes manejados por el sistema. Con el
objetivo de completar la definición del modelo físico, se le dota de procesos de control,
de seguridad y auditabilidad, necesarios para una instalación mecanizada.
Y como el conocimiento del nuevo sistema aumentará considerablemente en esta etapa,
se podrá definir la estrategia a seguir en los planes de formación al usuario, la
conversión de los datos, las pruebas del sistema e implantación, como parte del ciclo
vida a recorrer.
5.1. Requisitos físicos del nuevo sistema
A partir de las necesidades hard/soft definidas en la etapa anterior para la solución
elegida, se debe completar detalladamente la plataforma hardware y software para la
puesta en marcha del sistema. Estos requisitos físicos se expresan bajo los conceptos de:
entorno operativo del sistema y configuración hardware/software.
5.1.1. Entorno Operativo del Sistema
Se especifican aspectos clave del diseño del sistema, como los descritos a continuación.
• 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 diseñar interfaces con otras aplicaciones o sistemas que dialogan con
éste. Además se debe especificar cómo van a llevarse a cabo las respectivas tomas de
datos para la entrada al sistema: quiénes van a realizarlas, con qué seguridad se va a
contar, qué información se va a introducir.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
104
Si acudimos al modelo lógico de procesos obtenido en la etapa de Análisis 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
Control de Inventario
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
105
• Mantenimiento de Ficheros
Los ficheros maestros del sistema que representan el código de la aplicación residirán
en el ordenador del usuario, en un directorio específico 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 residirán en el servidor del departamento, responsable
de albergar todos los registros de control que se efectúen cada día. 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.
• Generación 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 imprimirán ante situaciones consideradas relevantes para encaminar
adecuadamente la ejecución del programa, y como listados, generados a partir de las
visitas registradas (fichero Excel de las visitas de los tres últimos días). Los mensajes de
información que se proporcionarán en ambos controles de acceso se clasifican de la
siguiente manera:
Error:
Éstos a su vez, pueden ser tecnológicos, cuando hay un fallo en la comunicación con el
lector, bien porque no se encuentre conectado correctamente, o bien porque la
transmisión no se ha completado adecuadamente. También pueden ser errores de
aplicación, 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
106
También se consideran avisos de este tipo los fallos derivados de las lecturas de la base
de datos cuando es necesario mostrar información del estado actual de los recursos del
departamento, o de las reservas y visitas registradas con anterioridad.
Confirmación:
Avisos informativos del correcto registro de la visita o del movimiento de inventario, ya
sea de entrada como de salida.
• Control de información y de seguridad del sistema
La ejecución de las aplicaciones de los diferentes controles de acceso es responsabilidad
del usuario final, trabajador interino de la universidad Comillas. Dicha ejecución no está
sujeta a ningún control de seguridad, sin embargo sí esta respaldada por la
autentificación inicial cuando el usuario arranca el ordenador por primera vez, ya que
para encenderlo debe de introducir su contraseña 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 contraseña, para poder realizar la conexión con el mismo.
La transmisión de los datos entre los lectores y el sistema no está cifrada ni sometida a
ningún control de seguridad, excepto cuando se escribe en un TAG RFID. Dicha
escritura se realiza bajo un algoritmo simple de codificación de la información textual
(de caracteres), cuando se quiere recoger el nombre y el primer apellido del responsable
del recurso, y no caracteres numéricos, como es el caso del identificador de dicha
persona.
Además, el acceso a una tarjeta RFID requiere la utilización de una clave determinada
para poder acceder a la información que almacena en sus bloques, de forma que supone
un punto de seguridad adicional del sistema.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
107
• 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 máximo
de respuesta. En este caso, el tiempo máximo queda definido por el acceso a la base de
datos que corresponda, ya que la comunicación con los lectores constituye una mínima
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 sólo dependerá de los accesos a la base de datos. El tiempo de
ejecución queda definido por las lecturas a la base de datos, más el tiempo de gestión
del control de acceso, más el acceso al servidor para registrar la visita o el movimiento
de reserva o devolución.
La arquitectura que presenta el Sistema Control de Accesos a edificios es fácilmente
portable, ya que se puede migrar a otro entorno de desarrollo instalando simplemente
los drivers de los lectores y los archivos de codificación 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 comunicación entre todos
ellos, y también con el servidor de base de datos. A su vez, se puede ampliar la
funcionalidad del sistema proporcionando más servicios que los que se exponen en el
proyecto actual.
• Condiciones de operación
El horario operativo de explotación 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 llevarán a cabo en cualquier
momento que se corresponda con los contextos ya descritos con anterioridad: una nueva
visita, o un préstamo/devolución de un recurso.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
108
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
información, 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 implantación
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 estratégico desde donde se
gestionarán todas las visitas, préstamos y devoluciones de recursos.
La implantación 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 deberán estar conectados). Seguidamente se copiarán los ficheros de código
que constituyen las aplicaciones de los controles de acceso en un directorio específico
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
automáticamente el entorno de ejecución y su inicio. Dichos ejecutables se ubicarán en
el entorno de trabajo del usuario final (Véase Anexo 3).
5.1.2 Configuración hardware/software
De acuerdo con la solución elegida en el Estudio de la Arquitectura se completa la
especificación de los elementos hardware y software que van a constituir la plataforma
del sistema.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
109
La especificación se plantea mediante un gráfico para la configuración hardware y otro
para la configuración software. En el primero de ellos se recogen los elementos básicos
que van a formar la plataforma y sus interconexiones de comunicación. En el segundo,
se representan los ficheros maestros, las bases de datos y productos software que estarán
soportados bajo la plataforma hardware
Gráfico de Configuración hardware
Gráfico de Configuración software
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
110
ESPECIFICACIONES HARDWARE DEL SISTEMA
Servidor de Base de Datos
• 8 CPUs
• 8GB RAM
• 250GB HD
Lector de tarjetas inteligentes
• CPU CMOS de 8 bits
• Alimentación 5V DC del propio ordenador.
• Soporta velocidades de comunicación entre 9600bps y 115200bps
• Puerto USB/Serial
Lector RFID
• Antena Incluida.
• Frecuencia de Operación 125KHz.
• Conector USB.
• Led de operación y led de lectura incorporado.
• Lectura de tarjetas a una distancia entre 5 y 9 cm.
• Alimentación requerida: 5V/80 mA.
PC Usuario
• 512MB de RAM
• Procesador 2,5MHz
• 100GB de HD
• Puertos serie y USB
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
111
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 código fuente
• Drivers ODBC
5.2. Desarrollo del Modelo Físico Nuevo
Durante la etapa de Análisis de Requisitos se han diseñado los modelos físicos actual y
lógico actual, con el objetivo de conocer la situación 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 lógico correspondiente al sistema que se está desarrollando
sin pensar aún en su mecanización.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
112
En la fase de Estudio de la Arquitectura se ha definido una solución técnica y
organizativa, basada ya en una plataforma hardware y software. En el anterior punto, se
ha completado la especificación 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 lógico del sistema para transformarlo
en un modelo físico que contemple la plataforma tecnológica escogida.
El DFD del modelo físico tenderá a convertir qué hace el sistema por cómo lo hace
utilizando dicha plataforma. Para desarrollar este modelo deben realizarse diferentes
actividades:
• Establecer las fronteras de mecanización: qué procesos deben realizarse
manualmente y cuáles mediante ordenador.
• Determinar los diferentes tipos de procesos y especificarlos por lotes, on-line,
servicio…
• Diseñar las entradas y salidas del sistema: ventanas y formularios.
• Estimar volúmenes de información e identificar las transacciones críticas para
desarrollar el modelo lógico de datos a partir del modelo conceptual.
• Definir los controles y seguridad del sistema para su explotación: procesos de
control y seguridad.
Todas las actividades constituyen el modelo físico del nuevo sistema, y serán estudiadas
una a una en esta sección.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
113
5.2.1. Fronteras de Mecanización
La implantación del sistema sobre la plataforma tecnológica se especificó en la etapa de
Estudio de la Arquitectura, fase en la que se determinaron las características técnicas,
organizativas y operativas de la solución a desarrollar. A partir de ello, se determinan
qué procesos se llevarán a cabo manualmente y cuales se automatizarán, apareciendo
ambos tipos en el modelo físico final del sistema ya que si no, la función de negocio
quedaría incompleta. A continuación se muestran los procesos clasificados según su
modo de ejecución, de los dos tipos de controles de acceso:
PROCESO MODO DE EJECUCIÓN
Control de Visitas
Iniciar Servicio RFID Automático
Identificar Automático
Consultar Reservas Automático
Confirmar Movimiento Automático
Realizar Reserva Automático
Actualizar Recursos Manual
Registrar Préstamos Manual
Consultar Personal Automático
PROCESO MODO DE EJECUCIÓN
Control de Inventario
Obtener Estado Actual
de los Recursos Automático
Esperar Lectura Manual
Identificar Recurso Automático
Obtener Reserva
Asociada Automático
Registrar Movimiento Manual
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
114
La tarea de definir el modelo físico final se realizará a partir del modelo lógico diseñado
en la etapa de Análisis de Requisitos representando mediante una línea discontinua las
fronteras entra unos procesos y otros. Dichas líneas se denominan interfaz hombre-
máquina debido a que aparecen básicamente en las entradas y salidas del sistema.
A continuación se muestra el DFD correspondiente al modelo lógico mostrando las
fronteras de mecanización:
Control de Visitas
En el DFD del modelo lógico se representa el proceso 1 seleccionado mediante una
línea discontinua indicando que será automatizado, mientras que el proceso 2 requiere la
intervención del usuario del sistema de forma que se ejecutará manualmente.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
115
Control de Inventario
Las únicas etapas en las que es necesaria la intervención del usuario son al solicitar una
lectura y al confirmar un movimiento, de forma que el resto de procesos que constituyen
la gestión de un recurso se ejecutan de manera automática
En el diagrama correspondiente al Control de Inventario, la frontera de mecanización
resulta bastante clara y precisa, mientras que en el Control de Visitas puede encaminar a
una ambigüedad contextual por una falta de precisión.
Por ello, si se tiene en cuenta cómo se lleva a cabo la obtención de la información de
una visita probablemente existan procesos que no se ejecutan de forma manual, sino que
en función del la fase en la que se encuentre el control de acceso se ejecutará un proceso
u otro, según proceda, automáticamente. Por este motivo, es conveniente diseñar el
modelo con más detalle realizando la conversión del qué al cómo: modelo físico.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
116
5.2.2. Especificación de Procesos
En el diccionario de datos se definen todos los procesos originados en el modelo lógico.
A partir de las fronteras de mecanización, se añade una característica más a estos
procesos: manual o automático, ya que la definición realizada de los mismos se orientó
hacia la lógica de negocio más que hacia el contexto informático o de programación.
Por ello, se revisan de nuevo las descripciones de los procesos con el objetivo de
mejorar la miniespecificación actual de cada uno de ellos, considerando que el proceso
será iniciado por el usuario o automáticamente según corresponda.
Las nuevas miniespecificaciones se realizarán a partir de las ya existentes, que fueron
definidas en la etapa de Análisis de Requisitos para cada uno de los dos controles de
acceso que se están diseñando.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
117
Objeto: Proceso 1, Iniciar Servicio TI
Tipo: Automático
Identificador : PSCAP.1
Control de Visitas
Procedimiento destinado a configurar la comunicación con el lector LTCX. Dicha
configuración consiste en determinar un terminal a partir de un slot del mismo, que se
mantendrán durante todo el tiempo de ejecución de la aplicación de control de acceso.
Objeto: Proceso 2, Esperar Lectura
Tipo: Automático
Identificador : PSCAP.2
Control de Visitas
Segundo estado de la ejecución del control de acceso, en la que la aplicación se
encuentra en espera activa de procesar una lectura y realizar su correspondiente registro
en la base de datos. En este estado de la ejecución del control de acceso, el usuario
puede proceder a finalizar la aplicación, bien porque lo desea, o porque se produjo un
error durante la lectura
Objeto: Proceso 3, Mostrar Información
Tipo: Automático
Identificador : PSCAP.3
Control de Visitas
Estado del control de acceso en que se proporciona la información sobre la
identificación de la persona que realiza la visita, a quién 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 identificación. 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
118
Objeto: Proceso 4, Consultar Visitante
Tipo: Automático
Identificador : PSCAP.4
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 través de su tarjeta de alumno.
Objeto: Proceso 5, Consultar Personal
Tipo: Automático
Identificador : PSCAP.5
Control de Visitas
Proporciona información 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
Identificador : PSCAP.6
Control de Visitas
Etapa durante la fase de ejecución en la que se configuran los datos que definen la visita
que se desea registrar. Cuando el usuario confirme los datos proporcionados a través del
interfaz de la aplicación, se procederá a realizar un registro del visitante y de la visita
asociada al mismo.
Objeto: Proceso 7, Apagar Lector
Tipo: Manual
Identificador : PSCAP.7
Control de Visitas
Finalizar la comunicación con el lector LTCX, procediendo a su apagado.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
119
Objeto: Proceso 1, Mostrar estado actual
de los recursos
Tipo: Automático
Identificador : PSCAP.1
Control de Inventario
Cada vez que se inicia por primera vez la aplicación, o se finaliza la gestión de un
movimiento, se muestra la disposición 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.
Objeto: Proceso 2, Esperar Lectura
Tipo: Manual
Identificador : PSCAP.2
Control de Inventario
Estado lógico en el que se encuentra el sistema cuando no gestiona ningún movimiento.
Dicho estado permite atender una nueva petición 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 aplicación al lector
RFID, responsable de detectar una nueva tarjeta, que tras su identificación y lectura se la
transmite al sistema en forma de TRAMA, recuperando de nuevo el control de la
aplicación.
Objeto: Proceso 3, Identificar recurso
Tipo: Automático
Identificador : PSCAP.3
Control de Inventario
Después que el lector haya realizado la correspondiente lectura del TAG detectado,
envía al sistema el identificador y los datos leídos del mismo. Cuando el sistema recibe
la TRAMA, lo primero que realiza es la identificación del código recibido.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
120
Objeto: Proceso 3, Identificar recurso (Cont)
Tipo: Automático
Identificador : PSCAP.3
Control de Inventario
Si éste se corresponde con alguno de los recursos del departamento se procederá a
registrar el movimiento en cuestión, pero si no se corresponde con ninguno el sistema
solicitará una nueva lectura cambiando de nuevo al estado de “Esperar Lectura”.
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 identificación. 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, Obtener reserva
asociada
Tipo: Automático
Identificador : PSCAP.4
Control de Inventario
Seguidamente a la identificación del recurso, se determina el tipo de movimiento que se
va a gestionar, si entrega o devolución de un recurso, y tras ello se proporciona la
reserva correspondiente más próxima a la fecha actual.
Si el recurso está disponible, se mostrará la reserva más cercana a la fecha actual,
considerando para ello la fecha de realización del préstamo.
Si el recurso no está disponible, se proporcionará la reserva asociada al préstamo que se
va a gestionar como devolución del recurso.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
121
Objeto: Proceso 5, Registrar movimiento
Tipo: Automático
Identificador : PSCAP.5
Control de Inventario
Realiza el registro en la base de datos del movimiento que se ha gestionado, de manera
que la información almacenada sea coherente con el estado actual de los recursos y de
sus correspondientes reservas.
Los movimientos gestionados se corresponden con entregas, ya reservadas o no, y
devoluciones de recursos, cuando finaliza la validez del préstamo.
Además de las especificaciones, se debe de determinar la categoría de todos los
procesos. La categoría de un proceso establece su naturaleza, en función de la
arquitectura elegida. En este caso todos los procesos ofrecen un servicio particular que
en conjunto permite realizar la gestión de un control de acceso determinado.
Por último, los procesos deben estar definidos con una frecuencia de operación, la cual
determina en qué periodos de tiempo se debe ejecutar el proceso. Cada uno de los
controles de acceso se ejecutará todos los días de manera aleatoria, dependiendo de la
asiduidad con que se reciban las entidades a controlar, ya sean visitas como el
tratamiento de los préstamos o devoluciones de los recursos del departamento.
5.2.3. Diseño de Entradas
En esta etapa se realiza el diseño 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 navegación entre más de una ventana, sino que los diferentes flujos de
información se irán mostrando cuando proceda en la misma.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
122
Ventana Control de Visitas
Es posible que durante la etapa de programación se realicen cambios en el diseño del
interfaz de forma dinámica, 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
123
Ventana Control de Inventario
5.2.4. Diseño de Salidas
Los flujos de datos que salen del sistema hacia las entidades externas se pueden
considerar como salidas hacia el exterior, y podrán 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 aplicación quien confirme la visita para proceder a su registro en
la base de datos.
Por otro lado, el Control de Inventario tiene además situaciones en las que se
proporciona un formulario para completar el movimiento de un recurso, ya sea un
préstamo no reservado con anterioridad o una devolución temprana respecto a la fecha
de devolución registrada.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
124
5.2.5. Estimación de Volúmenes de Información
La estimación de volúmenes 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 físicas de éstas.
Las transacciones que supongan mayor número de accesos a la base de datos serán las
más críticas, de forma que se deberá prestar más cuidado con el objetivo de no
sobrecargar el sistema. Aún así, no se considera un problema como tal ya que no
existirán dos ejecuciones de las mismas características en paralelo.
También este estudio de volúmenes indicará si los procesos definidos en el modelo
lógico están bien diseñados respecto a los flujos de información con los que trabajan.
Para que el modelado sea físico y se pueda implantar en una máquina, se debe
considerar el modo más rentable y eficaz de acceso a los datos y de procesado de los
mismos.
El segundo objetivo determinado es el de obtener información acerca de las diferentes
entidades del modelo de datos, con la finalidad de realizar un buen diseño 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 ocupación en disco.
Para realizar el análisis se parte del modelo lógico o físico de procesos, del modelo de
datos, del ciclo de vida de las entidades y de los diseños de entrada y salida. Un primer
análisis se puede realizar configurando una Matriz de Procesos/Entidades:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
125
Control de Visitas
PROCESOS/ENTIDAD VISITANTE EMPLEADO VISITA SISTEMA
Iniciar Servicio TI C
Esperar Lectura C
Mostrar Información L L
Consultar Visitante L
Consultar Personal L
Obtener Visita Actual A A A
Apagar Lector C
Control de Inventario
PROCESOS/ENTIDAD RECURSO EMPLEADO PRESTAMO RESERVA SISTEMA
Mostrar estado actual
de los recursos L L
Esperar Lectura C
Identificar recurso C, L
Mostrar reserva
asociada L L
Registrar movimiento A A A E
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
126
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
información a través del sistema, constituyendo una actividad o función específica para
el negocio que se está diseñando.
El método 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 operación que se ha de realizar a través del sistema, combinándola
adecuadamente a la interacción externa del usuario final. Por tanto este método tiene en
cuenta el proceso lógico y el operador físico que lo realiza, pero no los datos que se
están manejando.
Control de Visitas
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
127
Los procesos 3, 4 y 5 tienen un cometido homogéneo, 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 operación crítica, de manera que si se tiene en cuenta una
perspectiva de futuro se podrían ejecutar más de una transacción de este tipo en paralelo
si se desea llevar a la práctica controles de acceso en varios puntos del edificio, en este
caso, de la universidad.
El proceso 6 es el único que realiza una operación 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 práctica así como la escritura en el log, de forma que es coherente
que se considere como una transacción independiente de la ya descrita con anterioridad.
Control de Inventario
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
128
Los procesos 1,3 y 4 son de lectura, realizan consultas contra la base de datos con el
objetivo de obtener la información necesaria para poder realizar adecuadamente la
gestión de un recurso. Por ello, los tres procesos anteriores se pueden considerar en
conjunto como una misma transacción.
El proceso “Registrar movimiento” supone la escritura del préstamo gestionado en la
base de datos, y la actualización del estado del recurso que se ha entregado o devuelto.
Por este motivo, al tratarse de operaciones críticas que pueden alterar la coherencia e
integridad de la información almacenada, este proceso se ha de gestionar como una
transacción independiente.
5.2.6. Procesos de Control y de Seguridad
En el modelo de procesos diseñado en la etapa de Análisis de Requisitos no se tuvieron
en cuenta los posibles controles del proceso de explotación 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 operación del sistema. Más concretamente,
podemos relacionar dichos procesos con el ámbito de la informática.
En este punto del proyecto ya se conoce con más detalle el nuevo sistema, de manera
que a continuación se procede a introducir y especificar en el modelo los controles de
operación y de seguridad, ya que se sabe cómo se van a mecanizar las tareas que se han
definido en los apartados anteriores. Todos estos procesos de control y de seguridad se
incluirán dentro de los procesos existentes ya que el alcance del proyecto es bastante
limitado y los procesos sólo se ejecutarían 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 demás
debido a que realizan otras funciones adicionales como consecuencia de los controles
que lleven a la práctica, de forma que se incluyen en el modelo físico del sistema. Para
realizar un análisis completo del control del sistema, se deben estudiar los procesos de:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
129
• Controles destinados a preservar la integridad de los datos
• Seguridad de la información y del acceso
• Auditabilidad del sistema por el usuario o por el administrador
• Procedimientos de recuperación de la información
• Historización de la información
Debido a las características 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 recuperación y de historización tan
exhaustivos al no manejar grandes volúmenes de datos de manera continua en el tiempo.
Tampoco se necesitan editar informes de análisis que muestren el correcto
funcionamiento del sistema, ni realizar actividades de auditabilidad. A continuación 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 comparación 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 serán las circunstancias
detectadas en un momento dado durante el periodo de explotación del sistema.
Las medidas estudiadas y seleccionadas para garantizar la integridad de los datos son las
siguientes:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
130
1. Control de los registros leídos 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 número de
registros insertados o presentados. Si no se cumple esta igualdad, algún registro
habrá sido despreciado, ignorado, o lo que es más grave, perdido.
2. Diseñar algoritmos que relacionen registros leídos, tratados y rechazados. Es
posible definir ecuaciones o algoritmos donde, de acuerdo al proceso realizado,
el número de registros leídos debe ser el mismo que la suma de los grabados más
los rechazados.
3. Controles de las lecturas y escritura realizadas contra la base de datos donde
residen los registros de información 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 información
Engloba los procesos o procedimientos de seguridad de uso, seguridad de los datos,
privacidad de la información 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
categorías:
1. Seguridad de los datos en su gestión, asegurando que los datos de salida desde el
sistema, sean utilizados por aquellos a los que van dirigidos.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
131
2. Seguridad de la confidencialidad de la información, garantizando que
únicamente las personas que están autorizadas pueden acceder a la información
de carácter personal, de acuerdo con la legalidad vigente.
3. Seguridad del propio sistema proporcionando la disponibilidad del sistema ante
caídas provocadas por el hardware o software.
4. Asegurar el acceso al sistema desde un terminal.
Aún así, se deberá sopesar el esfuerzo del diseño y de programación 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
132
66.. DDiisseeññoo II nntteerr nnoo
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
133
En esta fase de identifican y diseñan los diversos componentes software del sistema,
describiendo detalladamente sus especificaciones físicas. Dependiendo de la
arquitectura elegida correspondiente al sistema final, estos componentes pueden ser de
una naturaleza muy diferente.
Teniendo en cuenta el Modelo Físico de Procesos diseñado en la etapa de Diseño
Externo, donde cada proceso ha sido catalogado como de naturaleza de servicio, se
reunirán todas las funciones de negocio de nivel más detallado en función de su
tipología, y se estructurará el sistema en un conjunto de subsistemas. Generalmente los
subsistemas están formados por procesos de diferente naturaleza, pero en este proyecto
el sistema está definido por procesos de la misma naturaleza: de servicio.
También se deben considerar las ventanas y formularios que se han diseñado en la etapa
anterior, para garantizar la coherencia del diseño. Para aquellos subsistemas de tipo
cliente-servidor se tendrán que identificar y diseñar los módulos o programas cliente y
los programas de servicio, al igual que las transacciones (es la tipología que se
corresponde más fielmente a la del sistema que se está desarrollando).
Una vez diseñada la función de negocio y estructurada en sus componentes de
programación, se realizará una especificación de cada uno de ellos, denominada
Cuaderno de Carga.
Dicha especificación recoge todos los elementos de diseño que debe tener en cuenta el
programador para codificar cada programa, cómo son los ficheros de entrada y salida,
los diseños 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 programación
como para llevar a cabo la etapa de pruebas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
134
Antes de iniciarse la programación se debe finalizar el diseño de la base de datos y
demás ficheros para que los programas se codifiquen utilizando la configuración
establecida, y mediante las pruebas correspondientes comprobar la correcta ejecución de
éstos.
Finalmente, a partir de la estrategia definida para cada uno de los planes de pruebas y de
formación, se deben diseñar los elementos software necesarios para llevarlos a la
práctica, y especificarse cada uno de los planes mediante las actividades a realizar, los
recursos a utilizar, y la planificación a seguir.
6.1. Técnicas a utilizar
Se cuentan con diversas técnicas para el diseño de componentes software de una
función de negocio. Las metodologías estructuradas basan su diseño de modelo de
procesos en la técnica de Diagrama de Flujo de Datos, por lo que los diseños de
funciones realizados sobre ellos permiten estructurarlos y diseñarlos paralelamente. De
esta manera existe una continuidad en el diseño, que de otro modo supondría abandonar
el modelo físico de procesos ya realizado para inventar el diseño detallado de la
función. Por este motivo, y considerando que las funciones de negocio serán On-line,
cualquier componente puede diseñarse basándose en los DFDs. Básicamente la técnica
que se va a utilizar consiste en realizar la conversión 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 derivación del DFD
físico de cada función hacia el diagrama de cuadros estructurado o Structured Chart.
Éste es un diagrama que permite mostrar la jerarquía existente entre los módulos
principales y subordinados, de manera que cada uno realice una única tarea y se muestre
como un componente al que se le llama enviándole unos parámetros y devolviendo un
resultado.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
135
Dependiendo de las características del diseño, éstos módulos pueden empaquetarse o
encapsularse en rutinas reutilizables, módulos funcionales o librerías de funciones
(DLLs o clases .java). Para comprender y diseñar el diálogo de la aplicación con el
usuario final, a veces resulta conveniente utilizar los Diagramas de Flujo de Aplicación,
pero en este caso no se considera necesario por la sencillez de la navegación 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 petición del usuario, constituyen el
subsistema online. Estas funciones han sido diseñadas en el modelo físico de procesos,
donde sus componentes son flujos de datos, almacenes y procesos. Mediante la
derivación del DFD de la función hacia un Diagrama de Cuadros Estructurado o STC,
estos componentes darán lugar a los ficheros, ventanas, y módulos de programa que se
diseñarán y especificarán unitariamente.
El método a seguir consiste en tomar toda la información de cada función disponible en
el modelo físico y derivarla al diagrama STC, mediante dos métodos posibles de
derivación y la creatividad de la persona que desempeña el perfil de diseñador. Por
último, se encapsula la función en una transacción o librería.
El diseño del software orientado a objetos utiliza otros paradigmas diferentes al
subsistema online, dadas sus características propias de herencia, encapsulamiento y
polimorfismo: diagramas UML. Por ello, se ha decidido diseñar el sistema utilizando las
dos metodologías: en OO porque uno de los requisitos del proyecto es que se programe
en Java, y también 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 través de una LAN, se comuniquen con una aplicación que
se encuentre ubicada por ejemplo en el servidor o en otra estación de trabajo a la actual.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
136
6.2.1. El diagrama de Cuadros Estructurado (STC)
El STC es un diagrama jerárquico donde los elementos son módulos con información
sobre su acoplamiento respecto a otros módulos: datos y control. Un módulo es un
programa con una función única, que puede ser llamado por otros módulos y a su vez
puede llamar a otro, mediante el paso de parámetros o flujos de información 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 máquina donde reside el sistema o del exterior, provocados por las acciones del
usuario final sobre su interfaz.
De esta forma, cuando se diseñaron las ventanas o el interfaz, se tuvieron en cuenta los
diferentes eventos que podían tener lugar durante la ejecución de la aplicación, y la
actuación o respuesta que el sistema deberá realizar en cada situación. Ahora es el
momento de solapar la navegación del sistema con la lógica de negocio (servicios).
El modelo de diseño utiliza tres elementos, de manera similar a los modelos de
procesos:
• Estructuras de cuadros o diagrama STC (componente gráfico)
• Repositorio o diccionario (componentes de definición)
• Miniespecificaciones (componentes de especificación)
La técnica STC se basa en tres conceptos: descomposición, jerarquía e independencia.
La descomposición:
• División de las funciones de negocio, en módulos ejecutables.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
137
• Fácil de mantener, al obtener una alta modularidad del software
• Minimiza la duplicidad del código
• Posibilita la reutilización del código
La jerarquía:
• Facilita el diseño basado en componentes: presentación, negocio y datos.
• Módulos altos, responsables de realizar la coordinación y el control del proceso.
• Módulos bajos, encargados de realizar las operaciones.
La independencia:
• Un módulo es un componente software: procedimientos, datos.
• Un módulo no debe preocuparse de la estructura de otro: son cajas negras.
El diagrama STC utiliza una sencilla paleta para realizar su diseño, aunque varia en
función de la herramienta CASE que se utilice. Los símbolos esenciales son los
siguientes:
• El rectángulo identifica un módulo genérico, que se localizará en un
determinado nivel dentro de la jerarquía. De esta forma, existirán módulos
padres o jefes, y módulos hijos o subordinados, de acuerdo con la jerarquía de
control del proceso que se desee establecer.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
138
• Un rectángulo con una flecha en semicírculo en su base, representa a un módulo
iterativo, de forma que una vez que es llamado permanecerá en ejecución hasta
que se detenga su módulo principal.
• Un rectángulo con un rombo en su base representa un módulo de decisión, de
modo que la secuencia de ejecución de los módulos subordinados es un único
camino entre varios. Generalmente este camino será tomado en función del flujo
de control o de información que reciba.
• Un rectángulo con dos líneas paralelas representa un módulo reutilizable en
diferentes funciones de negocio, de manera que será diseñado una sola vez, y
llamado tantas veces como sea necesario.
• Para expresar la utilización de diferentes dispositivos de E/S se suelen utilizar
diversos símbolos, siendo los más comunes y genéricos los que se muestran en
los organigramas tradicionales. Este icono representa cualquier soporte de
entrada y salida, debido a que será el componente de definición del modelo el
que determine la unidad física que se utiliza. En este caso se corresponderán con
los lectores que se instalarán para realizar los dos controles de acceso.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
139
• Las flechas con dirección dispuestas sobre la estructura jerárquica del diagrama
representan los flujos de información. Estos flujos son los datos de negocio que
manipulan los módulos. Estas mismas flechas en vídeo 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, finalización
correcta, caracteres de control de dispositivos…
El diagrama STC establece una jerarquía en la dependencia de los módulos principales
y sus subordinados. Un STC debe interpretarse de arriba hacia abajo y de izquierda a
derecha.
6.2.2. Derivación del DFD al STC
A partir del diseño físico de la función de negocio recogida en el modelo de procesos,
aplicamos el método de derivación de transformación para conseguir organizar dicha
derivación como una transacción online, donde existe un programa principal que
identifica dicha transacción o función. Para ello deben considerarse los siguientes
puntos:
1. Disponer o dibujar el DFD de último nivel
El DFD que se utilizará para realizar la derivación al diagrama STC es el que se diseñó
en la etapa de Análisis de Requisitos, el cual proporciona información sobre lo que hace
el sistema y cómo.
Para que el estudio sea mucho más detallado, se realizará la derivación 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
140
Control de Visitas
Control de Inventario
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
141
2. Identificar el centro de transformación (CT)
Los centros de transformación identificados en cada uno de los controles de acceso se
muestran con una línea roja discontinua.
Control de Visitas
Control de Inventario
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
142
3. Realizar la primera aproximación al STC
A partir de la localización del CT, se realiza una primera aproximación de la estructura
del diagrama. Generalmente cada función derivada requiere de un módulo principal, que
identificará la transacción. Este módulo se encargará de recibir la llamada del menú de
la aplicación, y coordinar la ejecución del proceso cediendo el control a sus módulos
subordinados.
Además el módulo principal será el que deba configurar las variables de entorno o
globales de la función, así como la petición de recursos al sistema para poder llevar a
cabo la ejecución de la transacción. Bajo éste módulo, siempre aparecerá una estructura
donde a la izquierda estarán los módulos del camino o camino de entrada, a la derecha
los módulos que configuran el camino o los caminos de salida, y en el centro, el módulo
o módulos que constituyen el centro de transformación.
Puede ocurrir que se cuenten con varios caminos de entrada o salida, en cuyo caso se
establecerá directamente la jerarquía de los caminos, o un módulo intermediario que se
encargue de controlar a los diferentes caminos de entrada o salida, bajo el cual se
subordinarán los caminos.
Los módulos intermediarios de entradas y salidas son responsables de controlar los
procesos de los caminos subordinados.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
143
La primera aproximación correspondiente a los DFDs de las aplicaciones que realizan
los dos controles de acceso son las siguientes:
Control de Visitas
Control de Inventario
4. Refinar la estructura con criterios de diseño
Una vez obtenida la estructura de aproximación, 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 transformación hacia el exterior. Esto
significa que las burbujas de los caminos de entrada quedarán representadas como
módulos subordinados, donde el último de ellos se corresponderá con el de más bajo
nivel o de lectura, debido a que el diagrama se recorre de arriba hacia abajo y de
izquierda a derecha.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
144
Las burbujas de los caminos de salida se organizan en módulos subordinados en el
mismo sentido que en el DFD.
Además 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 gestión del movimiento del control de
acceso.
Respecto a los flujos de datos se mantienen su estructura y ubicación, justamente en los
mismos lugares donde aparecen en el DFD, ya que son los módulos 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 permitirán 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 añadido las señales de control que se
transmiten entre el sistema y el lector, con el objetivo de gestionar y controlar el
correcto funcionamiento de la aplicación, 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 continuación se muestra para cada control de acceso el diagrama STC final diseñado
a partir de las consideraciones que se han ido comentando a lo largo del desarrollo del
presente punto.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
145
Control de Visitas
Control de Inventario
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
146
5. Verificar la estructura final encapsulando módulos 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 módulos en los diferentes programas, dando lugar a las
diferentes transacciones que definirán el sistema final. Esta operación se debe realizar
teniendo en cuenta las pautas que se han descrito en al apartado 6.2.3. , referentes al
tamaño de los programas, la reutilización del código, la ubicación físico…
El módulo principal se corresponde con un módulo de control de la transacción, y
permanecerá como programa de control. La función de entrada, constituida por los
módulos encargados de recoger los flujos de datos de entrada, se encapsulará en un
único programa que será ejecutada en la máquina del usuario final, al igual que el resto
de módulos. El módulo principal será el responsable de controlar el estado de la
aplicación al iniciar su funcionalidad con una lectura, y a la hora de tratar los accesos a
través de las correspondientes llamadas a los demás módulos: el de acceso a la base de
datos, y el módulo que se comunica con el lector.
La función de negocio, por ejemplo Obtener Información 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 módulo de
Obtener Información representa el Centro de Transformación del Control de Visitas.
Por otro lado, los módulos de salida de ambos controles de acceso se gestionarán desde
el módulo principal, de forma que los primeros serán los responsables de informar al
usuario el resultado de la gestión 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
147
Control de Visitas
Control de Inventario
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
148
6.2.3. Consideraciones de diseño
El software se caracteriza por una serie de características que se deben tener en cuenta
cuando se quiere decidir cómo encapsular los programas, con el objetivo de conseguir
las ventajas más apropiadas para el diseño que se está realizando. Las aplicaciones
presentan requerimientos muy diferentes, por lo que hay que conocer al máximo detalle
el software que se está generando.
Dos propiedades que delimitan la división del sistema en subsistemas o módulos son el
tamaño y la complejidad. Es decir, decidir si interesa construir un programa con muchas
o pocas instrucciones. En este caso, la ejecución de los controles de accesos se realiza a
partir de ficheros de código cuyo tamaño no es grande debido a que el alcance del
mismo está acotado para el departamento de la universidad, y por tanto la funcionalidad
también. Debido al pequeño tamaño de los ficheros, permitirá evitar problemas de
diseño, de pruebas y sobre todo de mantenimiento.
A lo anterior, hay que añadirle que se evita el problema de falta de memoria para llevar
a cabo la ejecución de las aplicaciones, de modo que el tiempo de ejecución de los
mismos no se ven afectados por este problema. Aún así, hay que tener en cuenta que la
tecnología bytecode de Java presenta algún retardo en la gestión de eventos que se ven
compensados por los rápidos accesos a la base de datos.
Los ficheros de código se ubicarán en el ordenador del usuario final que se encuentra
localizado en la entrada del edificio del departamento del IIT. En este caso, al contar
sólo con una máquina servidora no existen problemas derivados de la distribución de la
carga a través 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 código. En este
caso, dado que dicha función de negocio se ha estructurado sobre el modelo físico de
procesos, siempre se puede descomponer en un conjunto de programas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
149
El factor de reutilización siempre debe tenerse en cuenta a la hora de encapsular los
programas. En este aspecto, las tecnologías orientadas a objetos han superado a los
paradigmas estructurados. Y la premisa seguida es muy razonable: se encapsulan
aquellos módulos que puedan ser reutilizados por otros componentes.
Otro elemento a tener en cuenta es el diseño basado en componentes, donde la lógica de
presentación suele estar en las estaciones cliente, o los servidores Web, la lógica de
aplicación en los servidores de aplicaciones, y la lógica de datos en los servidores de
bases de datos. En el presente sistema, la lógica de presentación y de aplicación se
encuentra en la máquina del usuario final, pero gestionadas por diferentes módulos, o
patrones de diseño. Al encapsular el software se tiene que considerar dónde se va a
ejecutar el programa, de manera que se pueda distribuir coherentemente con la función
de negocio a desempeñar en cada máquina o sistema.
En cuanto al diseño, existen dos factores que se deben tener en cuenta para determinar
la modularidad del software: el acoplamiento, o dependencias, que pueda existir entre
diferentes módulos, lo cual es negativo, y la cohesión, dependencia funcional, entre los
elementos de un módulo, factor que se pretende maximizar.
6.3. Diagrama del Sistema
Este tipo de diagramas son utilizados para mostrar visualmente las diferentes opciones
de navegación por el sistema, de manera que a partir de la ventana principal se observen
las diferentes funciones de negocio del mismo.
Cada diálogo 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
150
Se debe tener en cuenta en todo momento el tipo de usuario final que será el responsable
de utilizar la aplicación, de forma que el diseño debe ser sencillo e intuitivo con el
objetivo de que el usuario se pueda familiarizar sin problemas con los programas.
Control de Visitas
Control de Inventario
6.4. Cuaderno de Carga
Los Cuadernos de Carga recogen toda la información de diseño del programa, ya sea
online o de tipo batch. A continuación se describen los Cuadernos de Carga de los dos
controles de acceso que constituyen el sistema que se está desarrollando.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
151
6.4.1. Cuaderno de Carga de Control de Visitas
1. Descripción de archivos
El programa se codificará en Java, de forma que los archivos tendrán la extensión de
.java (junto con sus correspondientes ficheros de compilación denominados .class).
Adicionalmente, se proporciona la posibilidad de recoger en un fichero Excel todas las
visitas que se hayan tratado durante los últimos tres días.
2. Descripción del tratamiento o lógica de negocio
INICIAR SERVICIO TI Identificador: PROCV.01
Al arrancar por primera vez la aplicación, se establecerá la comunicación inicial entre el
sistema y el lector TI, con el objetivo de configurar el canal de transmisión para las
lecturas que se realicen a posteriori.
ESPERAR LECTURA Identificador: PROCV.02
Seguidamente el sistema pasará a un estado de espera de lectura, hasta que reciba la
notificación, 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 opción de registrar la visita sin realizar una
lectura como tal.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
152
IDENTIFICAR TARJETA Identificador: PROCV.03
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 INFORMACIÓN Identificador: PROCV.04
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 opción que estará
localizada en la ventana principal.
OBETENER VISITA ACTUAL Identificador: PROCV.05
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 Identificador : PROCV.06
La confirmación del usuario supone la inserción en la base de datos de los registros:
• Visitante: identificador, nombre, apellidos
• Visita: identificador visitante, identificador empleado, hora
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
153
MOSTRAR SOLUCIÓN Identificador: PROCV.07
Después 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 través de un menú, la opción de salir del
programa, de ayuda y de realizar el volcado del fichero de recuperación.
3. Estructura del programa: Pseudocódigo
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
154
4. Diseño 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 continuación:
TABLA: USUARIOS IDENTIFICADOR: TABLACV.1
TABLA: VISITANTES IDENTIFICADOR: TABLACV.2
TABLA: LOG_VISITAS IDENTIFICADOR: TABLACV.3
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
155
6.4.2. Cuaderno de Carga de Control de Inventario
1. Descripción de archivos
La aplicación será programada en Java, de forma que el código fuente con extensión
.Java (junto con el compilado .class) residirá en una carpeta especial. Además, en dicha
carpeta se ubicarán también las DLLs necesarias para la comunicación con el lector
RFID.
2. Descripción del tratamiento o lógica de negocio
Mostrar estado actual de los recursos Identificador: PSCAP.1
Cada vez que se inicia por primera vez la aplicación, o se finaliza la gestión de un
movimiento, se muestra la disposición 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.
Esperar Lectura Identificador: PSCAP.2
Estado lógico en el que se encuentra el sistema cuando no gestiona ningún movimiento.
Dicho estado permite atender una nueva petición 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 aplicación al lector
RFID, responsable de detectar una nueva tarjeta, que tras su identificación y lectura se la
transmite al sistema en forma de TRAMA, recuperando de nuevo el control de la
aplicación.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
156
Identificar Recurso Identificador: PSCAP.3
Después que el lector haya realizado la correspondiente lectura del TAG detectado,
envía al sistema el identificador y los datos leídos del mismo. Cuando el sistema recibe
la TRAMA, lo primero que realiza es la identificación del código recibido. Si éste se
corresponde con alguno de los recursos del departamento se procederá a registrar el
movimiento en cuestión, pero si no se corresponde con ninguno el sistema solicitará una
nueva lectura cambiando de nuevo al estado de “Esperar Lectura”.
Mostrar reserva asociada Identificador: PSCAP.4
Seguidamente a la identificación del recurso, se determina el tipo de movimiento que se
va a gestionar, si entrega o devolución de un recurso, y tras ello se proporciona la
reserva correspondiente más próxima a la fecha actual.
Si el recurso está disponible, se mostrará la reserva más cercana a la fecha actual,
considerando para ello la fecha de realización del préstamo.
Si el recurso no está disponible, se proporcionará la reserva asociada al préstamo que se
va a gestionar como devolución del recurso.
Registrar movimiento Identificador: PSCAP.5
Realiza el registro en la base de datos del movimiento que se ha gestionado, de manera
que la información almacenada sea coherente con el estado actual de los recursos y de
sus correspondientes reservas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
157
Se ha decidido añadir un aspecto funcional a la utilidad de RFID: en cada uno de los
registros de un préstamo escribir en la tarjeta las condiciones con que se realiza éste por
ejemplo sin maletín, sin disco…Dicha escritura será controlada para no superar la
longitud máxima de 16B del bloque del TAG donde se almacenará el comentario.
3. Estructura del programa: Pseudocódigo
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
158
4. Diseño 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 gestión de la entrega o devolución de los recursos. El
formato de los registros de éstas se describe a continuación:
TABLA: PRÉSTAMOS IDENTIFICADOR: TABLACI.1
TABLA: ITEMS IDENTIFICADOR: TABLACI.2
TABLA: RESERVAS IDENTIFICADOR: TABLACI.3
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
159
77.. PPrr ooggrr aammaacciióónn
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
160
El objetivo de esta etapa es alcanzar la transformación del sistema en un conjunto de
programas que se ejecuten satisfaciendo los requisitos marcados bajo unos criterios de
seguridad. La dificultad reside en cómo realizar la transformación de la mejor forma
posible, debido a que va a depender de los lenguajes de programación que se utilicen, de
las herramientas y utilidades software disponibles, y del responsable de la
programación.
Como ya se ha comentado en las primeras etapas, no sólo es necesario realizar un buen
diseño, sino también conseguir un sistema tangible de calidad, con resultados
económicos, 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
módulo del programa funciona correctamente de acuerdo a los criterios establecidos. No
basta con una compilación 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
ejecución, de manera que en el caso de que se tengan que afrontar anomalías, 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 decisión de qué acción realizar.
Además de codificar los programas, de acuerdo a los Cuadernos de Carga diseñados en
la etapa del Diseño Interno, deben desarrollarse los procedimientos catalogados o scripts
de ejecución, que constituyen los programas de control de ejecución de las funciones de
negocio o transacciones.
En base a los programas desarrollados y los procedimientos de control, se confeccionan
los manuales o guías de usuario y de explotación del sistema. El sistema quedará
definido por dos manuales de usuario y de explotación, debido a que esta formado por
las dos aplicaciones que llevan a la práctica los controles de acceso al edificio del
departamento del IIT.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
161
7.1. Análisis y diseño orientado a objetos
Dado que los programas serán codificados utilizando el lenguaje de programación Java,
se ha optado por realizar el Ciclo de desarrollo orientado a objetos.
7.1.1. Introducción
Las metodologías orientadas a objetos y de Análisis Estructurado se diferencian en el
énfasis que se aplica a los distintos componentes del modelado. Las técnicas de
orientación a objetos (OO) se encuentran dominadas por los modelos de clases y de
objetos. Estas técnicas representan la realidad a través de objetos, de clases de objetos,
de sus relaciones y de sus características propias o atributos, ofreciendo un contexto
para comprender el comportamiento dinámico y funcional del sistema. Por el contrario,
el Análisis Estructurado acentúa la descomposición funcional, proporcionando un
conjunto de funciones al usuario final.
Los métodos de Booch y OMT (Object Modeling Technique) se desarrollaron de
manera independiente entre sí, reconociéndose como métodos de orientación a objetos.
El desarrollo de UML (Unified Modeling Language) se inició en Octubre de 1994
cuando Grady Booch y Jim Rumbaugh unificaron los dos métodos anteriores de OO.
Las motivaciones que impulsaron el desarrollo de un lenguaje de modelización
unificado son las siguientes:
• Eliminar las diferencias entre los métodos de OO para evitar posibles
confusiones entre los usuarios.
• Unificar la semántica y notaciones simbólicas definiendo estándares universales.
• Mejorar los métodos existentes aportando mayor funcionalidad a los anteriores,
y nuevas formas de resolver la problemática más usual o habitual.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
162
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 metodología estructurada,
utilizando para ello las técnicas y herramientas OO. Por tanto, un proyecto de desarrollo
software OO se inicia con la identificación de Necesidades y la Definición de
Requisitos. A partir de este punto, se desarrolla un primer incremento basado en las
metodologías de Análisis, Arquitectura, Diseño, Programación, Pruebas e Implantación.
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 número de
incrementos que se deben llevar a cabo para diseñar el sistema se deben definir en la
etapa de Identificación de Necesidades, donde se acuerda con el cliente el número de
incrementos y las entregas con nueva funcionalidad que se realizarán 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 más 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 críticas: aquellas clases que son esenciales
para el funcionamiento del sistema, y así posibilitar su reutilización.
• Desarrollo de prototipos: consiste en el diseño de una versión parcial o básica
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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
163
En la práctica, las fases de análisis de requisitos, de validación y de aceptación se llevan
a cabo a través de reuniones constantes con el director del proyecto. Dichas reuniones
definen el desarrollo incremental de la codificación del sistema, pero no del estudio y
diseño del mismo. Por este motivo, se realiza el diseño detallado del sistema de acuerdo
a la metodología estructurada sin considerar la tecnología de programación que se va a
utilizar (presente documento), y por otro lado, se lleva a cabo la codificación del sistema
de acuerdo al ciclo de vida de la metodología de orientación a objetos en la etapa de
programación del desarrollo estructurado del proyecto.
7.1.3. Técnicas OO en las fases de la metodología
Las fases del ciclo de vida cuyas actividades técnicas se encuentran influenciadas por
las técnicas de OO a utilizar son las de Análisis de Requisitos y de Programación.
Técnicas de orientación a objetos en la etapa de Análisis de Requisitos
La etapa de Análisis de Requisitos se debe completar con técnicas OO para realizar el
modelado del sistema. Estás técnicas se encuentran orientadas a la recopilación de
información 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
Diseño, por lo que se comienza con unos diagramas básicos que se irán refinando a
medida que se obtiene más información del sistema.
En una primera iteración 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 aplicación. Al final de este proceso de análisis se obtiene un modelo del sistema tanto
desde la perspectiva estructural (descripción estática) como desde la de comportamiento
(descripción dinámica). Por tanto, los objetivos a cubrir en esta etapa son:
• Descomponer funcionalmente las operaciones complejas en clases del dominio.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
164
• Organizar el sistema en partes manejables.
• Determinar el comportamiento dinámico esencial de las clases cuyo
comportamiento es fundamental para la lógica de negocio y control del sistema
en su totalidad.
Diagrama de Clases: modelo estático
Es un modelo de estructura estática, por lo que la información que representa no
depende del factor tiempo. Proporciona una descripción del problema reflejando la
realidad. Su descomposición en otros niveles depende de la complejidad del problema y
no del sistema.
El diagrama de clases es una técnica de modelización, por lo que requiere de un
componente gráfico y un componente de definición de sus atributos y de su
comportamiento. Debe describir las operaciones de las clases, así como la dependencia
entre ellas, utilizando tanto la definición textual como el pseudocódigo. 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 después de haber ejecutado con éxito una clase.
• Las excepciones: Las diferentes situaciones especiales o anómalas que pueden
tener lugar durante la ejecución del programa, y que deben tenerse en cuenta
para garantizar la continuidad del servicio.
• Los parámetros. Argumentos de entrada y salida.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
165
• Los algoritmos: Los métodos utilizados por las clases.
• Los resultados: Son las salidas resultantes de la ejecución de una clase.
Este modelo determinará la jerarquía de herencia para todas las clases generadas, así
como las relaciones entre ellas.
Diagrama de Clases inicial de Control de Visitas
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
166
Diagrama de Clases inicial de Control de Inventario
Definición de Casos de Uso
La definición de los casos de uso permite mostrar la funcionalidad del sistema desde el
punto de vista del usuario. Un caso de uso es una descripción de un conjunto de
caminos de ejecución relacionados a través de su comportamiento, durante la
interacción del usuario con el sistema.
Estos caminos son el resultado de los estímulos 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 más precisa. Sin embargo en esta fase no se suelen
utilizar los diagramas de secuencia.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
167
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 aplicación de Visitas.
Las diferentes situaciones o contextos que pueden existir durante la ejecución de la
aplicación, se contemplarán en la definición detallada del escenario primario del caso de
uso como extensiones del mismo.
Casos de Uso de Control de Inventario
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
168
Técnicas de orientación a objetos en la etapa de Diseño
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 programación
elegido, en este caso Java.
Por tanto, los diagramas diseñados con anterioridad serán los mismos que los utilizados
en ésta pero llevando a cabo un refinamiento y un diseño 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 estático:
� Definir todas las clases del sistema
� Diseñar 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 jerarquía de herencia para todas las clases del sistema
� Describir completamente los métodos utilizados en las clases
• Refinamiento dinámico:
� Describir detalladamente la interacción de las clases que poseen un
comportamiento dinámico
� Especificar los eventos y estados de las clases con comportamiento dinámico
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
169
� Completar el modelo de clases contemplando los cambios realizados durante
el modelado dinámico (nuevas clases, operaciones, atributos, etc.)
Por ello, los diagramas utilizados en esta etapa deberán de hacer referencia a los
diagramas sobre los que se realiza el refinamiento, diseñados con anterioridad.
Diagrama de Clases Detallado
Como se ha comentado con anterioridad, el diagrama de clases representa una visión
estática del sistema. Se puede representar con varios niveles de detalle, de manera que
se añadirá al diagrama inicial el resto de clases necesarias para definir el sistema
completamente.
Diagrama de Clases Detallado de Control de Visitas
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
170
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 diseña un
diagrama de este tipo, se debe considerar además de la funcionalidad del sistema, el uso
que le va a dar el usuario final. Cada caso de uso constituye una recopilación de
sucesos, cuyo evento inicial lo provoca una entidad externa o actor, especificando la
interacción 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 Análisis 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
171
El diagrama debe de estar acompañado por una descripción específica de los casos de
uso fundamentales que constituyen la funcionalidad del sistema. La descripción de cada
uno de ellos debe ser lo más completa posible, a pesar de que los diagramas en esta fase
se hayan refinado respecto a su versión inicial si fuese necesario. Para cada caso de uso
debe especificarse:
• Una breve descripción del caso de uso, indicando su empleo, su modo de
funcionamiento y frecuencia de utilización.
• Una descripción 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 ejecución correcta del caso de uso.
• Las excepciones: corresponden a los situaciones anómalas que pueden ocurrir en
cualquier momento, durante la ejecución normal del caso de uso. En el caso de
que existan, se debe especificar cuándo suceden, cómo se detectan y el
tratamiento que se debe realizar con ellas.
A continuación, 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 indicarán las estructuras de
datos utilizadas, así como las posibles extensiones que pueden tener lugar durante la
ejecución del control de acceso.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
172
Descripción del Caso de Uso de Control de Visitas
Caso de Uso: Registrar Visita
• Actor: Usuario final
• Precondiciones: El sistema debe haber detectado correctamente la conexión del
lector de tarjetas inteligentes, y comprobar la comunicación entre ambos.
• Trigger: Introducir una tarjeta de la universidad o activar la opción 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 información del correcto registro de la visita.
7. El sistema cambia al estado de espera de lectura de tarjeta.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
173
• Estructuras de datos:
� Datos de la tarjeta inteligente:
Código 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
Teléfono 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
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
174
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 opción de salir de la aplicación.
1. El sistema muestra diálogo de confirmación
2. El usuario confirma la finalización de la aplicación.
3. El sistema pasa a permanecer al estado de inactividad.
7a2. El usuario no confirma la finalización de la aplicación.
1. El sistema pasa al estado de espera de lectura.
Descripción de los Casos de Uso de Control de Inventario
Caso de Uso: Registrar Préstamo Sin Reserva
• Actor Primario: Usuario
• Precondiciones: El lector RFID debe estar conectado al ordenador, y reconocido
por el sistema.
• Trigger: El usuario pulsa el botón de Registrar Préstamo para realizar la entrega
en ese momento del recurso
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
175
• Escenario Primario:
1. El usuario rellena todos los campos que definen los datos del registro
instantáneo.
2. El usuario confirma los datos del registro instantáneo.
3. El sistema comprueba que el usuario ha introducido correctamente los datos del
registro instantáneo.
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 botón de nueva lectura.
8. El sistema salta al estado de espera de lectura.
• Estructuras de datos:
� Datos del registro instantáneo:
Duración en horas del préstamo
Timestamp del día de entrega del recurso
Día de devolución del recurso
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
176
Nombre y apellidos del usuario del recurso
Comentario personal del préstamo del recurso
• Excepciones:
2a. El usuario no confirma los datos del registro instantáneo.
2a1. El sistema pasa al estado de espera de confirmación de operación.
3a. El sistema comprueba que los datos del registro instantáneo 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.
4a1. El sistema muestra un mensaje informado el error detectado.
4a2. El sistema pasa al estado de espera de confirmación de operación.
5a. El sistema actualiza correctamente el estado del recurso gestionado.
5a1. El sistema muestra un mensaje informado el error detectado.
5a2. El sistema pasa al estado de espera de confirmación de operación.
7a. El usuario pulsa el botón de finalizar la aplicación.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
177
Caso de Uso: Registrar Préstamo Con Reserva
• Actor Primario: Usuario final
• Precondiciones: El lector RFID está conectado al sistema, y existe comunicación
entre ambos.
• Trigger: El usuario pulsa el botón de Registrar Préstamo para realizar la entrega
en ese momento del recurso.
• Escenario Primario:
1. El sistema muestra los datos del préstamo que se está realizando.
2. El usuario pulsa el botón 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 botón de nueva lectura.
6. El sistema salta al estado de espera de lectura.
• Estructuras de datos:
� Datos del préstamo:
Duración en horas del préstamo
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
178
Timestamp del día de entrega del recurso
Día de devolución del recurso
Nombre y apellidos del usuario del recurso
Comentario personal del préstamo del recurso
• Excepciones:
2a. El usuario no confirma el movimiento.
2a1. El sistema pasa al estado de espera de confirmación de operación.
3a. El sistema actualiza correctamente el estado del recurso gestionado.
3a1. El sistema muestra un mensaje informado el error detectado.
3a2. El sistema pasa al estado de espera de confirmación de operación.
5a. El usuario pulsa el botón de finalizar la aplicación.
Caso de Uso: Registrar Devolución
• Actor Primario: Usuario final.
• Precondiciones: El lector RFID debe estar conectado al ordenador donde se
ejecuta la aplicación, y se garantiza que la comunicación entre ambos es
correcta.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
179
• Trigger: El usuario pulsa el botón de Registrar Devolución cuando se entrega el
recurso al departamento antes de la fecha de devolución registrada.
• Escenario Primario:
1. El sistema comprueba que la fecha de devolución 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
devolución.
4. El usuario pulsa el botón de nueva lectura
• Excepciones:
1a. El sistema comprueba que la fecha de devolución 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 confirmación de operación.
4a. El usuario pulsa el botón de Salir para finalizar la aplicación
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
180
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 confirmación de operación.
7.2. Manual de Usuario
La estructura que se ha definido para realizar el Manual de Usuario es la siguiente:
1. Introducción
1.1. Objeto de la aplicación
1.2. Ámbito de la aplicación
1.3. Documentación relacionada
2. Descripción 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. Función de negocio 1
3.1.1. Descripción de la funcionalidad
3.1.2. Perfiles de los usuarios autorizados
3.1.3. Operativa de la función
3.2. Función de negocio 2
3.2.1. Descripción de la funcionalidad
3.2.2. Perfiles de los usuarios autorizados
3.2.3. Operativa de la función
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
181
En el epígrafe 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 actuación, normas y
estándares referentes a las funciones recogidas por la aplicación, aunque debido a la
sencillez que caracteriza a la aplicación no se considera que sea necesario desarrollar
este último punto.
En el segundo epígrafe se realiza una exposición general del sistema, describiendo el
entorno de trabajo donde se ejecuta o accede a la aplicación, haciendo referencia a los
elementos hardware y software más relevantes. También se especifican los perfiles de
usuario asignando a cada uno de ellos las operaciones que pueden ejecutar.
Dependiendo del tipo de aplicación, suelen aparecer diferentes tipos de usuario, aunque
el Sistema Control de Accesos sólo tiene un único usuario final que desempeña 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 dónde y cómo se ubican, así como la forma a partir de la cual se
puede lanzar su ejecución. Por último, se contempla el sistema de ayudas utilizado por
la aplicación, indicando si es a nivel de ventana, de campo de información o existe una
función específica de ayudas por donde puede navegar el usuario.
En el epígrafe 3 se describen las distintas funciones de negocio que pueden realizar
dentro de la aplicación, describiendo el alcance de la funcionalidad de cada una de ellas,
los perfiles de usuario necesarios para ejecutaras, y la operativo o procedimiento de
actuación. Este procedimiento se describe realizando un recorrido por los diálogos de la
función.
En el epígrafe 4 se pueden incluir una serie de anexos que ayuden al usuario a
comprender y a manejar la aplicación.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
182
Así, un glosario de los términos utilizados en las ventanas y mensajes de la aplicación,
así como de los acrónimos utilizados, será de gran utilidad para aquellos usuarios que
por diversos motivos no hayan podido familiarizarse con la operativa.
También 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 operación de cada
función de negocio de forma individual, no será necesario incluir como anexo la
descripción detallada del interfaz de la aplicación como un epígrafe 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
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
183
88.. PPrr uueebbaass
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
184
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 crítica, y debe realizarse con la misma dedicación y
planificación con las que se ha desarrollado el resto de proyecto.
Si los resultados son satisfactorios, se procederá a la aceptación de los mismos y a la
implantación del sistema en el entorno para el cual ha sido diseñado, pero en caso
contrario se tendrán que resolver las anomalías encontradas suponiendo un retraso en la
finalización del proyecto ya que se ha de revisar el diseño y la codificación 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 producción. 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 residirán las aplicaciones
correspondientes a los controles de acceso.
Por otra parte, suelen utilizarse volúmenes representativos de información para llevar a
cabo cada una de las pruebas, ya que los volúmenes de datos reales que va a manejar el
sistema representan un alto grado de ocupación del servidor donde residen. En cuanto a
la información personal a utilizar para realizar las pruebas se corresponderán con datos
meramente intuitivos de manera que permitan emular la gestión 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
185
Durante las etapas de Programación, Pruebas del Sistema e Implantación se ejecutan
diferentes pruebas parciales sobre el sistema final, cada una de ellas con objetivos
diversos, aunque en función del tipo de software diseñado se le suele someter a unas
pruebas u otras.
En la etapa de Pruebas del Sistema se ejecuta el bloque de pruebas más completo con el
objetivo de comprobar la funcionalidad del sistema y el rendimiento exigido en los
requisitos.
Para ello, previamente se habrán llevado a cabo las pruebas unitarias de cada
componente, y posteriormente se realizarán las pruebas de carga y de rendimiento sobre
el entorno real de producción. 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 comunicación entre todos los componentes que intervienen en la
gestión de un control de acceso. En este caso se corresponde con la comunicación
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 producción. 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
186
• Pruebas de Recuperación
En esta caso las pruebas de recuperación 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 gestión que realizan cada una de las aplicaciones.
• Pruebas de Aceptación 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
navegación del sistema en cada una de las funciones de negocio. Esta aceptación
únicamente certifica la aceptación del usuario con las aplicaciones desarrolladas, hecho
que supone la implantación del sistema en el entorno real de producción. En este
entorno se ejecutarán más pruebas sobre el sistema comprobando su funcionalidad en el
entorno final de producción, que determinará la conformidad del usuario con el software
implantado. El usuario ejecutará esta fase de pruebas bajo la supervisión y guía del
autor del proyecto.
• Pruebas de Usabilidad
Normalmente las pruebas de aceptación 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 realizarán en el IIT en el entorno de trabajo del usuario final.
Cuando se habla de facilidad de uso se está haciendo referencia al diseño de la interfaz y
al Manual de Usuario. Durante estas pruebas se pude aprovechar para formar al usuario
sobre la utilización del sistema, de forma que resulta mucho más sencillo y claro el
aprendizaje, al realizarse directamente con la persona que ha diseñado el sistema.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
187
Al preparar el entorno de pruebas para emular el contexto de explotación del sistema, se
han instalado y configurado tanto el software base como el de aplicación de acuerdo a
los componentes utilizados. A partir de ello, se realizará el Manual de Instalación y
Configuración necesario para configurar el entorno de producción. El manual
correspondiente al sistema se adjunta como Anexo en la presente documentación.
Un aspecto importante que se ha de tener en cuenta sobre la tecnología RFID es que
dependiendo de la posición con que se ubique la tarjeta que se desea leer sobre el lector,
puede que la operación no se realice correctamente porque no se estabiliza la
comunicación 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 señal es demasiado bajo, de forma que
al no ser capaz de realizar su identificación lo considera un problema generando un
mensaje de error. Este aspecto funcional se describe detalladamente en el Manual de
Usuario de Control de Inventario.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
188
99.. II mmppllaannttaacciióónn
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
189
Tras probar la integridad del software del sistema y especificar su instalación y
configuración, se ha llevado a cabo la instalación del sistema en el centro de producción
donde se va a llevar a cabo su explotación: se han instalado los drivers y las
aplicaciones correspondientes a los dos controles de acceso en la estación de trabajo del
usuario final del departamento, configurando adecuadamente los orígenes 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 finalización
correcta del mismo. Una de ellas tiene como objetivo certificar el correcto
funcionamiento de la aplicación utilizando los recursos reales del entorno de
explotación. La otra prueba necesaria es la aceptación 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 producción garantizando su correcto funcionamiento.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
190
1100.. CCoonncclluussiioonneess
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
191
El Sistema Control de Accesos proporciona diversas ventajas a partir de la ejecución
conjunta de las dos aplicaciones que lo constituyen, gracias a las tecnologías de control
de accesos empleadas para llevar a cabo su implantación, las cuales están basadas en la
utilización 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 implantación 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 tecnología RFID los puntos positivos son diversos:
• Permite llevar a cabo un monitoreo detallado y automático de los movimientos
que tienen lugar en el departamento, posibilitando la identificación rápida del
recurso. Si se dispone de un almacén con un número considerable de recursos,
por ejemplo el de una biblioteca, esta tecnología permitiría 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 gestión
de inventarios.
• Permite gestionar el inventario garantizando una organización del mismo,
disponer de la traza e historia de los productos, prevenir robos, evitar pérdidas
de recursos por desconocimiento de su ubicación y acelerar las consultas de
inventario.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
192
• Los códigos de barras (UPC) serían una alternativa a la tecnología RFID pero
requieren que se escanee uno por uno los artículos y que la etiqueta sea visible
para poder realizar adecuadamente su lectura, sin embargo los lectores de RFID
pueden escanear simultáneamente varios artículos tanto tengan el TAG visible
directamente como que no (lecturas anticolisión), siempre que se cumpla con las
distancias mínimas. Además, el código de barras típicamente suele informar de
qué artículo se trata, por ejemplo Códigos UPC, mientras que la tecnología
RFID maneja números de identificación más largos y permite identificar cada
artículo individualmente y recoger información adicional asociada al mismo:
número de serie, lote, etc…
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
193
1111.. GGlloossaarr iioo ddee TTéérr mmiinnooss
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
194
Análisis: Estudio y modelización de una función de negocio para ser mecanizada
mediante un sistema de ordenador.
Análisis 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 características o propiedades de una entidad o
una relación.
Burbuja: Proceso representado en un diagrama de flujo de datos mediante un círculo.
Cardinalidad: En una relación mide la máxima y mínima participación de las entidades
cuando se observa el conjunto de las ocurrencias de cada una de ellas.
CASE: Computer Arded Software Engineering. Ingeniería del software asistido por
ordenador.
Ciclo de vida: Conjunto ordenado de las etapas por las que transcurre el desarrollo de
un sistema informático.
Control de Calidad: Actividades encaminadas a detectar y corregir cualquier desviación
durante el desarrollo del sistema.
Cuaderno de Carga: Especificación del diseño de un programa.
DER: Diagrama de Entidad-Relación.
Diagrama de Casos de Uso: La definición de los casos de uso permite expresar las
facilidades del sistema desde el punto de vista del usuario. Un caso de uso es una
descripción de un conjunto de caminos de ejecución relacionados por su
comportamiento durante la interacción del usuario con el sistema.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
195
Diagrama de Clases: Es un modelo de la estructura estática que proporciona una
descripción del problema reflejando el mundo real y cómo lo ve el cliente. Su
descomposición 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 definición textual como el pseudocódigo.
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 composición de las
opciones de navegación por el sistema, de modo que a partir de una ventana inicial se
observen los diferentes diálogos de funciones.
Diagrama de Flujo de Datos (DFD): Representación gráfica de un modelo de procesos
donde aparecen los flujos de datos y sus transformaciones a lo largo del sistema.
Diagrama de Presentación: Diagrama de formato libre utilizado para mostrar algún
concepto o alguna idea, dentro de las especificaciones de análisis y de diseño del
sistema.
Diagrama Entidad-Relación (DER): Representación gráfica 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 especificación del software del
sistema.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
196
Documento de Conceptos del Sistema: Especificación de las necesidades del cliente,
donde se recogen los objetivos del sistema en estudio.
EDT: Estructura de división del trabajo. Es una descomposición del proyecto en un
conjunto de tareas manejables.
Entidad: Concepto dentro de la organización o del negocio que es de gran interés para
el estudio del sistema.
Especificación: Descripción detallada del elemento software objeto de análisis, diseño
o programación.
Flujo de Datos: Rango de información que al entrar en un proceso sufre una
transformación dando lugar a otra porción de información diferente.
Gestión de Configuración: Componente de la ingeniería del software que estudia el
control de las versiones de los componentes software y la gestión de cambios a lo largo
del desarrollo.
IIT: Instituto de Investigación Tecnológico
Interrogador: Lector. Son dispositivos que activan y / o dan potencia a una etiqueta
electrónica y recuperan la información contenida en la misma.
Metodología: Método sistemático de abordar la resolución de un problema, o un
conjunto de métodos 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 gestión y control de
las comunicaciones entre el cliente y el servidor, o entre un emisor y receptor.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
197
Modelo: Representación del sistema o de algún elemento constituyente del mismo. Los
modelos están formados por tres elementos: componente gráfico, componente de
definición y componente de especificación.
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
características o atributos.
Modelo Físico del Nuevo Sistema: Representa las funciones de negocio del nuevo
sistema y cómo van a ser implantadas sobre una plataforma tecnológica hardware,
software y de comunicaciones.
Modelo Lógico del Nuevo Sistema: Representa las funciones lógicas en que se
estructura el sistema, determinado qué debe hacer y no cómo se debe implementar sobre
la plataforma tecnológica.
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 almacén.
RFID (Identificación por Radio frecuencia): Es un método para identificar artículos
utilizando ondas de radio. La gran ventaja en comparación con la tecnología de códigos
de barras es que el láser debe ver el código para efectuar la lectura correspondiente. Las
ondas de radio no necesitan tener una línea directa de visión y pueden pasar a través de
diversos materiales tales como el cartón o el plástico.
TAG: Tarjeta o etiqueta RFID
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
198
UML: Unified Modeling Language. Metodología de análisis y diseño orientado a
objetos.
UPC (Código Universal de producto): Sistema de numeración y codificación en barras
de Norteamérica desarrollado a fines de la década de sesenta y principios del setenta por
la industria alimenticia de los EUA que se utiliza para la identificación de productos de
artículos de consumo que son escaneados en un punto de venta minorista.
UPCO: Universidad Pontifica Comillas
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
199
1122.. BBiibbll iiooggrr aaff ííaa
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
200
Páginas Web:
RFID Journal:
www.rfidjournal.com
RFID Magazine:
www.rfid-magazine.com
Página de RFID de Texas Instruments:
www.ti.com/tiris/default.htm
Página de Randall Jackson:
http://rfid.home.att.net/
Enlaces a Webs de fabricantes de tecnologías RFID:
http://members.surfbest.net/eaglesnest/rfidweb.htm
Manual RFID:
http://www.rfid-handbook.de/links/index.html
Sistemas identificación 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
Estándares aprobados RFID:
http://www.rfid-handbook.de/rfid/standardization.html
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
201
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
Artículos 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:
� Programación
� Usuario
� Protocolo de Comunicaciones
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
202
AAnneexxoo 11
MM aannuuaall ddee UUssuuaarr iioo ““ CCoonnttrr ooll ddee VViissii ttaass””
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
203
Capítulo
Página
1. Introducción
204
2. Descripción general del sistema
2.1. Entorno de trabajo
2.2. Perfiles de usuario
204
205
205
3. Funcionamiento
3.1. Gestión de visitas con carnet de alumno
3.2. Gestión de visitas sin carnet de alumno
3.3. Opción “Consulta”
206
207
208
209
4. Ayudas
4.1. “Error al intentar acceder a la tarjeta”
4.2. “No se ha encontrado ningún lector”
210
210
210
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
204
El presente documento se corresponde con el Manual de Usuario de la aplicación de
Control de Visitas, que recoge una descripción del funcionamiento del sistema y del
entorno de explotación, así como un apartado de ayuda para afrontar los problemas más
usuales que pueden surgir.
1. Introducción
En este primer apartado del manual se pretende realizar una breve descripción del
subsistema de Control de Visitas.
1.1. Objeto de la aplicación
El principal objetivo de la aplicación es el de facilitar la gestión de las visitas que se
reciben en el IIT. Para ello, la aplicación realiza: la identificación de la persona que
realiza la visita, la localización de la persona visitada, y el proceso de registro de la
visita.
1.2. Ámbito de la aplicación
La funcionalidad básica de la aplicación 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 leídos 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
205
2. Descripción general del sistema
A continuación se realiza una exposición general del sistema, explicando el entorno de
trabajo donde se ejecuta la aplicación, describiéndose los elementos hardware y
software más importantes.
2.1. Entorno de trabajo
La aplicación final reside en el ordenador personal del usuario, ubicado en la entrada del
edificio del departamento.
La aplicación se comunica de manera constante, siempre que permanezca activa, con un
lector de tarjetas inteligentes que se encuentra conectado al mismo ordenador a través
de un puerto USB.
2.2. Perfiles de usuario
Los usuarios del sistema, serán 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 u ocurrencia que
tenga lugar.
El perfil correspondiente al usuario final de la aplicación no presenta restricción alguno
a la hora de ejecutarla o de gestionar los movimientos que tengan lugar.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
206
3. Funcionamiento del sistema
El interfaz de la aplicación es el que se adjunta a continuación:
El sistema se encuentra en espera de gestionar una visita, ya sea con tarjeta inteligente o
no. Las funciones que se proporcionan cuando la aplicación permanece en dicho estado
son las de salir, consulta y ayuda:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
207
3.1. Gestión de visitas con carnet de alumno
La lectura de una tarjeta supone la transmisión de los datos leídos de la misma hacia el
sistema. Cuando este recibe los datos del visitante los muestra por pantalla,
proporcionando al mismo tiempo la información 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 próxima visita
que protagonice sea a la misma persona.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
208
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 selección
de la lista de visitas recientes, o bien, de la de todo el personal.
3.2. Gestión de visitas sin carnet de alumno
La aplicación proporciona la posibilidad de gestionar visitas de personas que por
cualquier motivo no disponen del carnet de alumno de la universidad. En esta situación
el usuario de la aplicación 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 unívoco para
poder registrarlo en la base de datos.
Tras la selección, el subsistema muestra los datos de toda la plantilla del personal del
departamento con el objetivo de que se indique quien es el visitado.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
209
Determinados todos los datos que constituyen una visita, se debe confirmar su registro
pulsando el botón de “Registrar Visita”.
3.3. Opción “Consulta”
El servicio de “Consulta” permite afrontar informes de las últimas
visitas realizadas en el departamento.
Mediante esta opción se abre la aplicación Excel con un listado de las últimas visitas
realizadas. Esta información procede de los movimientos gestionados en la
correspondiente base de datos del servidor del departamento.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
210
4. Ayudas
La aplicación proporciona una opción de ayuda destinada a facilitar la gestión 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 ejecución de la aplicación.
4.1. “Error al intentar acceder a la tarjeta”
Si se introduce una tarjeta distinta a la de la UPCO o una tarjeta dañada, la aplicación
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 ningún lector”
Esto se problema puede deberse a dos motivos: que no haya ningún lector de Tarjetas
Inteligentes instalado correctamente, o que el acceso al lector está bloqueado por otra
aplicación (por ejemplo no se ha iniciado el servicio de Tarjetas Inteligentes de su
Sistema Operativo).
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
211
Para resolver el problema se deben tener en cuenta los siguientes puntos:
1. Compruebe que tenga instalado correctamente un lector compatible con el estándar
PCSC10, y con los drivers actualizados.
2. Compruebe que el servicio de Tarjetas Inteligentes esté iniciado.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
212
AAnneexxoo 22
MM aannuuaall ddee UUssuuaarr iioo ““ CCoonnttrr ooll ddee II nnvveennttaarr iioo””
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
213
Capítulo
Página
1. Introducción
215
2. Descripción general del sistema
2.1. Entorno de trabajo
2.2. Perfiles de usuario
2.3. Sistemas relacionados
216
216
216
217
3. Funcionamiento
3.1. Gestión de préstamos
3.2. Gestión de devoluciones
3.3. Botón de “Nueva Lectura”
3.4. Escritura en una tarjeta RFID
218
220
223
226
226
4. Ayudas
4.1. “Error al identificar el recurso, aproxime de nuevo la tarjeta”
4.2. “Error de conexión con la base de datos”
4.3. “No se han encontrado recursos registrados”
4.4. “Error en el acceso a la base de datos. Se finaliza la aplicación”
4.5. “La fecha de devolución es errónea. Debe ser anterior a XXXX-XX-XX”
4.6. “Error de escritura RFID. Aproxime de nuevo la tarjeta RFID al
lector”
4.7. “El campo “Información adicional del préstamo” debe ser más
corto”
4.8. “Error al actualizar los recursos de la devolución. Inténtelo de
nuevo”
4.9. “Error al registrar la devolución”
228
228
228
229
229
230
230
231
231
231
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
214
Capítulo
Página
5. Ubicación de las tarjetas para la lectura y escritura RFID 233
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
215
El presente documento se corresponde con el Manual de Usuario de la aplicación de
Control de Visitas, que recoge una descripción del funcionamiento del sistema y del
entorno de explotación, así como un apartado de ayuda para afrontar los problemas más
usuales que pueden surgir.
1. Introducción
En este primer apartado del manual se pretende realizar una breve descripción del
subsistema de Control de Inventario.
1.1. Objeto de la aplicación
El principal objetivo de “Control de Inventario” es el de permitir llevar a cabo un
seguimiento de los ordenadores portátiles y de otros recursos de uso común que
proporciona el IIT a sus empleados. Dicho seguimiento consiste básicamente en anotar
las fechas y horas de los préstamos y devoluciones de cada equipo.
1.2. Ámbito de la aplicación
El presente control de inventario se realiza a partir de la gestión de las entradas y salidas
del material informático suministrado por el departamento, así como de la identificación
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 través de la
aplicación de “Reservas Online” ( que no forma parte del presente proyecto).
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
216
2. Descripción general del sistema
A continuación se realiza una exposición general del sistema, explicando el entorno de
trabajo donde se ejecuta la aplicación, describiéndose los elementos hardware y
software más importantes necesarios para llevar a cabo la ejecución de la aplicación del
control de acceso.
2.1. Entorno de trabajo
La aplicación 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 comunicación entre ambas entidades no es permanente, sino
que se establece sólo cuando sea necesario.
El lector se encuentra conectado al mismo ordenador donde reside la aplicación a través
de un puerto USB.
2.2. Perfiles de usuario
Los usuarios del sistema, serán 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. El perfil correspondiente al usuario final de la aplicación no presenta
restricción 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 aplicación y
no hay riesgo alguno ante posibles manipulaciones de los préstamos o devoluciones que
se realicen.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
217
2.3. Sistemas relacionados
El presente control de inventario se encuentra integrado con una aplicación destinada a
registrar las reservas de los recursos del departamento. La aplicación de recursos se
ejecuta en un entorno Web, donde los usuarios acceden a través de la red de la
universidad para informarse de la disponibilidad de los recursos y confirmar sus propias
reservas. La aplicación desarrollada comparte la base de datos con el sistemas de
reservas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
218
3. Funcionamiento del sistema
Al arrancar la aplicación 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 identificación, se mostrará un mensaje informativo si el recurso
tiene asociada alguna incidencia que haya que recordar. Dicha información puede ser
referente al préstamo, como por ejemplo que no se ha llevado el ratón o un disco, o bien
puede estar relacionada con algún defecto del propio recurso: por ejemplo que el cable
del cargador esté roto.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
219
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 identificación 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 leído el TAG del Móvil 1, de forma que se ha
consultado en la base de datos sus posibles reservas, y se ha obtenido que la reserva más
próxima a la fecha actual tiene como usuario a Pedro Silva, y el préstamo ha de
realizarse el 03/05/2007.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
220
Si el recurso, por el contrario, no tiene reservas asociadas se mostrará un mensaje
notificándolo:
3.1. Gestión de préstamos
Se pueden gestionar dos tipos de préstamos: aquellos que tienen reservas asociadas y los
que no. Éstos últimos se corresponden con situaciones en los que no hay reservas para
los próximos días, o en los que hay una reserva confirmada pero no para el día actual.
Préstamo con reserva
Se corresponde con la situación normal en que una persona ha reservado con antelación
y se dispone a recoger el equipo. Para confirmar la entrega de un recurso se deberá
pulsar el botón de “Registrar Préstamo”:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
221
Cuando el préstamo que se ha de gestionar tiene como día de inicio de la reserva el
actual o uno anterior, la aplicación 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 diálogo que se muestra se
corresponde con la que se muestra a continuación:
El campo correspondiente a “Información adicional del préstamo” está destinado a
recoger algún tipo de incidencia relacionada con el recurso. Esta funcionalidad se
explicará en el punto 3.4 de este manual.
Préstamo sin reserva
Esta situación se denomina también “Reserva instantánea”. Como se ha comentado con
anterioridad, el préstamo sin reserva tiene lugar cuando no hay reservas asociadas o
cuando la reserva registrada no tiene como fecha de préstamo la actual.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
222
Como en el caso anterior, después 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 gestión del préstamo pulsando el botón de “Registrar Préstamo”:
Seguidamente, el sistema mostrará una ventana de diálogo 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 devolución que se desee:
Igualmente, el usuario de la aplicación deberá indicar a quién se entrega el recurso, un
comentario que justifique el préstamo, y la información del estado del préstamo, campo
que se explica en el apartado 3.4.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
223
Cuando la entrega del recurso se encuentra condicionada por una reserva que está ya
confirmada, el sistema mostrará una ventana de diálogo que mostrará por defecto la
fecha y hora de devolución más tardía con las que se permite llevar a cabo la entrega del
recurso. Esta restricción se validará cuando el usuario confirme el préstamo después de
que haya introducido el resto de datos. La ventana correspondiente a esta situación es la
que se adjunta a continuación:
3.2. Gestión de devoluciones
El movimiento correspondiente a una devolución se realiza de manera similar al
préstamo de un recurso.
Después que el sistema identifique el recurso y el tipo de movimiento, se muestra la
reserva correspondiente a la devolución que se va a registrar. Por ello, para confirmar la
devolución se deberá pulsar el botón de “Registrar Devolución”:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
224
A continuación la aplicación proporciona un mensaje informando si la operación de
devolución se ha registrado correctamente o no, ya que implica realizar una
actualización del estado del recurso y del préstamo 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, después de registrar el movimiento de devolución, se proporciona la
posibilidad de escribir en la tarjeta algún problema o deficiencia física 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 descripción del problema.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
225
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 través 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 confirmación de la
escritura, y el sistema mostrará la tabla de recursos con el estado de disponibilidad
actualizado con la devolución 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:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
226
Para resolverlo, se deberá pulsar el botón 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 Botón de “Nueva Lectura”
Si después de identificar un recurso no se desea realizar el movimiento correspondiente
se debe pulsar el botón 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 descripción a grabar en la tarjeta no
debe superar los 16 caracteres de longitud máxima ya que se excede el tamaño 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 petición es el
siguiente:
Cuando se acepte se realiza la escritura.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
227
Si la operación no se completa se muestra un mensaje de error:
Para conseguir que la operación se realice correctamente se deberá comprobar que la
tarjeta se sitúa adecuadamente sobre el lector, y aceptar de nuevo el intento de escritura.
En el momento en el lector emita un beep significará que la operación se ha llevado a
cabo satisfactoriamente.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
228
4. Ayudas
En este apartado se contemplan los posibles errores que se pueden producir durante la
ejecución de la aplicación. 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. Sitúe de nuevo la tarjeta sobre el lector, asegurándose que se encuentra próxima
a la antena. (Ver apartado de Posición de lectura).
4.2. “Error de conexión con la base de datos”
1. Comunicar el problema al administrador del sistema.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
229
La conexión inicial que se establece al arrancar la ejecución 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 aplicación no es la correcta, o la tabla de
recursos del departamento se encuentra vacía.
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 aplicación”
1. Comunicar el problema al administrador.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
230
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 devolución es errónea. Debe ser anterior a XXXX-XX-XX”
La fecha de devolución introducida al definir los datos de configuración de la
reserva instantánea debe ser anterior a la fecha y hora en la que hay que entregar el
recurso en el siguiente préstamo confirmado. Por tanto, introduzca:
• Fecha de devolución anterior a la fecha de entrega mostrada en la reserva más
próxima asociada.
• Fecha de devolución igual a la fecha de entrega pero la hora de devolución
menor a la de entrega.
4.6. “Error de escritura RFID. Aproxime de nuevo la tarjeta RFID al lector”
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
231
Acepte el mensaje informativo, y automáticamente se realizará un nuevo intento de
escritura.
4.7. “El campo “Información adicional del préstamo” debe ser más corto”
La descripción o comentario relacionado con un determinado recurso debe tener una
longitud máxima de 16 caracteres. En caso de no satisfacerse este restricción, se
mostrará este mensaje de error.
4.8. “Error al actualizar los recursos de la devolución. Inténtelo de nuevo”
Repita de nuevo todo el proceso de devolución explicado con anterioridad.
4.9. “Error al registrar la devolución”
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
232
Cuando las devoluciones se realizan con antelación al día que se había 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 devolución. Si el proceso de actualización falla se lanza
este tipo de error. Por ello, se ha de repetir de nuevo todo el proceso de devolución
explicado con anterioridad.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
233
5. Ubicación de las tarjetas para la lectura RFID
Para evitar posibles errores de lectura o de escritura derivados por la incorrecta posición
de la tarjeta sobre el lector, se ha de tener en cuenta que la correcta ubicación es la que
se muestra en la imagen que se adjunta.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
234
AAnneexxoo 33
MM aannuuaall ddee II nnssttaallaacciióónn
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
235
Capítulo
Página
1. Instalación de la JVM
1.1. Añadir la variable de entorno PATH
236
236
2. Guía de instalación de la aplicación Control de Visitas
2.1. Instalación del driver del lector de tarjetas
2.2. Instalación del software OpenCard
2.3. Instalación de la aplicación
238
238
239
244
3. Guía de instalación de la aplicación Control de Inventario
3.1. Instalación del driver del lector RFID
3.2. Instalación de la aplicación
244
244
245
4. Creación del vínculo con la base de datos
245
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
236
A continuación se indican los pasos que se han de seguir para llevar a cabo la
instalación del sistema en entornos Windows, aunque al tratarse de herramientas
multiplataforma y gratuitas, podrían instalarse en otros sistemas operativos.
1. Instalación de la JVM
Para obtener la JVM hay que dirigirse a la página Web www.sun.com y acceder a la
sección 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 ejecución, JRE.
Una vez descargado el fichero, hay que ejecutarlo realizando un doble clic sobre el
mismo y seguir los pasos que el asistente de instalación indicará para completar la
instalación.
1.1. Añadir la variable de entorno PATH
Con el objetivo de poder ejecutar y
compilar aplicaciones Java desde la
consola de comandos, añadimos 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 botón
derecho de su ratón sobre el icono
de MI PC o pulse la tecla Windows
seguida de la tecla Pause.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
237
A continuación se debe hacer clic en la pestaña Opciones avanzadas y seguidamente en
el botón 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
238
2. Guía de instalación de Control de Visitas
El primer paso, antes de instalar la aplicación, será cerciorarse de que se encuentra
instalado en el ordenador donde se va a ejecutar la aplicación la JVM, el driver del
lector y las librerías de OpenCard.
Si no se tiene instalado algún componente de los mencionados anteriormente, a
continuación se explica como instalar cada uno de ellos paso a paso.
2.1. Instalación del driver del lector de tarjetas
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 fácilmente localizable, y su ubicación 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 configuración de
hardware. En primer lugar preguntará si se desea que se conecte con Windows Update,
seleccionando la opción negativa.
Seguidamente el asistente solicitará que se indique cómo se van a proporcionar los
drivers del hardware que se desea instalar. La opción que se ha de seleccionar es la que
se corresponde con “Instalar el driver desde una ubicación específica”, de manera que
en el siguiente paso se deberá pulsar sobre l botón 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 instalación de nuevo
hardware.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
239
2.2. Instalación del software OpenCard
El primer paso es descargar las librerías de OpenCard (software gratuito y abierto) de la
siguiente página Web, www.opencard.org, en la sección 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á añadir en la variable de entorno “classpath” el
directorio en el que se encuentra, de la siguiente forma:
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
240
La ejecución correcta del fichero de OpenCard descargado permitirá arrancar el
asistente de instalación del sw:
Seguidamente, nos pedirá la ruta de instalación y el nombre de un grupo de programas
para colocarlo en el menú Inicio.
A continuación, pedirá confirmación para crear un fichero de configuración interna, en
donde responderemos de manera afirmativa.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
241
Posteriormente, nos solicitará qué protocolo de comunicaciones queremos instalar, a lo
que responderemos “PC/SC” ya que el estándar “Java Card”; aún no está tan
popularizado como el PC/SC, y por tanto para la realización del proyecto se escogió el
estándar PC/SC.
Tras hacer esta elección si se diese el caso en que se mostrara un mensaje de error, lo
ignoraremos pulsando “OK”
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
242
Mas tarde, se pedirá una ruta para guardar los ficheros internos, en donde por defecto
establecerá la ruta de las librerías de Java, que no debe ser modificada.
Por último pedirá una confirmación antes de instalar.
Después de aceptar el comienzo del proceso de instalación, se mostrará una ventana con
el logotipo de OpenCard que contiene un diálogo que indica el tiempo restante para
finalizar dicha instalación, es como una barra de progreso.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
243
Es posible que durante la instalación aparezca un mensaje de reemplazo de ficheros con
el mismo nombre pero diferente fecha, en estos casos se cogerá la opción que mantenga
el fichero más actual.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
244
2.3. Instalación de la aplicación
Para llevar a cabo la instalación de la aplicación tan sólo es necesario copiar la carpeta
aplicación local de “Control de Visitas”, que se encuentra en el CD que acompaña a este
proyecto, al directorio raíz (C:\) de su ordenador.
Debido a que la aplicación tiene acceso a BBDD vía Web, es necesario crear un vínculo
a la base de datos. En el apartado 4 se explica como realizarlo.
3. Guía de instalación de Control de Inventario
El primer paso, antes de instalar la aplicación, 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
continuación se explica como instalar cada uno de ellos paso a paso.
3.1. Instalación del driver del lector de tarjetas
El primer paso para instalar el driver, es recomendable copiar los ficheros del mismo en
un directorio del sistema destinado para ello donde sea fácilmente localizable, y su
ubicación 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 configuración de
hardware. En primer lugar preguntará si se desea que se conecte con Windows Update,
seleccionando la opción negativa.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
245
Seguidamente el asistente solicitará que se indique cómo se van a proporcionar los
drivers del hardware que se desea instalar. La opción que se ha de seleccionar es la que
se corresponde con “Instalar el driver desde una ubicación específica”, de manera que
en el siguiente paso se deberá pulsar sobre l botón 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 instalación del nuevo hardware.
3.2. Instalación de la aplicación
Para llevar a cabo la instalación de la aplicación tan sólo es necesario copiar la carpeta
aplicación local “Control de Inventario”, que se encuentra en el CD que acompaña a
este proyecto, al directorio raíz (C:\) de su ordenador.
Debido a que la aplicación tiene acceso a BBDD vía Web, es necesario crear un DNS.
En el siguiente apartado se explica como realizarlo.
4. Creación del vínculo con la base de datos
Acceda al Panel de
Control de su
ordenador y haga
doble clic sobre
Herramientas
administrativas.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
246
A continuación se abrirá una carpeta en la que tendrá que hacer doble clic sobre
Orígenes de datos (ODBC).
En la siguiente ventana usted deberá seleccionar el driver del gestor de bases de datos
correspondiente para su implantación real.
Las aplicaciones desarrolladas son independientes del gestor de base de datos que se
utilice (Oracle, SQLServer, MySQL, etc.) En la implantación 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 información 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.
Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios
247
Para definir el vínculo 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 botón de “aceptar”.
Las bases de datos necesarias para llevar a cabo la gestión de visitas son dos: card y
card_personal. Por ello, se tendrán que crear dos orígenes de datos, mientras que en
Control de Visitas sólo hay que definir la base de datos de equipos.
Recommended