SISTEMAS DE CONTROL DE ACCESOS A EDIFICIOS MEDIANTE TARJETAS CRIPTOGRÁFICAS Y TARJETAS RFID

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA 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

Resumen I

1. Descripción general del Sistema El proyecto 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. II

Determinar la persona que se quiere visitar: Consiste en seleccionar el nombre del empleado a visitar de una lista obtenida de la base de datos del personal del departamento. En esta lista se proporcionan los campos de la 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. III

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. IV

Abstract V

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 VI

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. VII

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

Índice IX

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 X

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 XI

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 XII

Capítulo Página Anexo 1 202 Anexo 2 212 Anexo 3 234 XIII

1. Plan de Gestión 1

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. 2

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: 3

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 4

Actividad PSCA03.2 Actividad PSCA03.3 5

Actividad PSCA03.4 Actividad PSCA03.5 6

Actividad PSCA03.6 Actividad PSCA03.7 7

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. 8

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. 9

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. 10

PSCA03.7 PRUEBAS Desarrollados y probados cada uno de los programas y componentes que constituyen el software, deben realizarse una serie de pruebas para conseguir integrar todo el sistema, de acuerdo al Plan de Pruebas establecido en la etapa de 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. 11

1.5. Organigrama del equipo de trabajo El equipo de trabajo del proyecto que se va a realizar, está formado por cuatro participantes claramente diferenciados. Por un lado, se han definido las entidades del director y del coordinador del proyecto, los cuales son las personas responsables de controlar y verificar el correcto desarrollo del proyecto, siendo la figura del director mucho 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. 12

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. 13

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). 14

Recoger y evaluar el proyecto finalizado, rechazando los que no alcancen un determinado nivel o presenten defectos de forma. Finalizado el proyecto, el alumno entregará al Coordinador un ejemplar visado por su director de proyecto, junto con un resumen. (En las titulaciones de 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. 15

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. 16

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. 17

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. 18

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 19

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. 20

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. 21

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 22

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: 23

2. Documento de Conceptos del Sistema 24

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. 25

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. 26

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. 27

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. 28

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. 29

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. 30

3. Análisis de Requisitos 31

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. 32

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. 33

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. 34

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. 35

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. 36

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. 37

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. 38

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. 39

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. 40

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. 41

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. 42

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. 43

Identificar personal ajeno a la universidad Comillas: Cuando se presente en el departamento una persona que no dispone de carnet de alumno, se le asignará un identificador especial, de forma que tras haber facilitado sus datos personales, se pueda llevar a cabo el registro de la visita que desea realizar. Consultar personal del departamento: Se proporcionan los datos de todas las personas que forman parte del departamento del IIT de Comillas: nombre, despacho y 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. 44

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. 45

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. 46

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. 47

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 48

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. 49

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- Identificador: PSCAO.2 ENCONTRADO 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. 50

Diagrama Conceptual de Nivel 1 El diagrama conceptual recoge los procesos de primer nivel que realizan la funcionalidad descrita con anterioridad del Control de Visitas. En este caso, 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. 51

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. 52

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. 53

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. 54

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. 55

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. 56

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 57

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: 58

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. 59

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. 60

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. 61

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. 62

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. 63

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: 64

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. 65

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. 66

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. 67

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: 68

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. 69

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. 70

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: 71

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: 72

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. 73

4. Estudio de la Arquitectura 74

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. 75

Perfil de la superficie de los contactos: La diferencia de los niveles entre los contactos y la superficie de la tarjeta adyacente deberá ser menor de 0.1mm. Fuerza 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 76

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: 77

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... 78

4.1.1.2. Tipos de Tarjetas Inteligentes Existen diversos tipos de Tarjetas Inteligentes, todas ellas pueden clasificarse bajo dos criterios. El primero es el tipo de circuito integrado que lleva en su interior y la forma de procesar la 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. 79

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. 80

Tarjetas sin contacto Son similares a las de contacto con respecto a lo que pueden hacer y a sus funciones pero utilizan diferentes protocolos de 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. 81

4.1.1.3. Sistema de Ficheros El sistema de ficheros de las Tarjetas Inteligentes está definido, como ya se ha indicado en un apartado anterior, en la ISO 7816-4. Todas las tarjetas deben soportar los siguientes tipos de ficheros: Fichero Maestro (MF): Este fichero representa la 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. 82

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. 83

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. 84

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. 85

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. 86

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. 87

4.1.2.1. Funcionamiento Todo sistema RFID se compone de un interrogador o sistema de base que es responsable de leer y escribir datos en los dispositivos, y un transmisor que responde al interrogador. Existen dos tipos de TAGs: los TAGs activos que incorporan una 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. 88

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. 89

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. 90

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. 91

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. 92

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. 93

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. 94

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. 95

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. 96

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 97

3. Costes operacionales. Este apartado recoge los costes del centro de proceso de datos y los costes de mantenimiento y mejora. Como coste del centro de proceso de datos son los costes fijos de 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 : 98

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: 99

Como se ha comentado con anterioridad, el Plan de Proyecto en este punto del desarrollo debe recoger el resto de etapas que quedan por realizar, determinando de manera 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: 100

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. 101

5. Diseño Externo 102

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. 103

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 104

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. 105

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. 106

Rendimiento del sistema y escalabilidad Con el fin de conseguir que el sistema alcance los objetivos marcados, se debe de medir el flujo de datos que se manejará de manera que se pueda determinar el tiempo 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. 107

La carga de trabajo del sistema es aleatoria, aunque no elevada, ya que depende de la afluencia de movimientos que se tengan que gestionar. Dicha carga de trabajo es constante en cada registro, ya que en todo momento se trabaja con los mismos flujos de 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. 108

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 109

ESPECIFICACIONES HARDWARE DEL SISTEMA Servidor de Base de Datos 8 CPUs 8GB RAM 250GB HD Lector de tarjetas inteligentes CPU CMOS de 8 bits 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 110

ESPECIFICACIONES SOFTWARE DEL SISTEMA Servidor de Base de Datos Sistema Operativo Solaris Gestor de Base de Datos Relacional SQL Adaptador TCP/IP PC Usuario Windows XP Driver lector tarjetas inteligentes Driver RFID Java Virtual Machina Navegador Fichero de 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. 111

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. 112

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 Control de Visitas Iniciar Servicio RFID Identificar Consultar Reservas Confirmar Movimiento Realizar Reserva Actualizar Recursos Registrar Préstamos Consultar Personal MODO DE EJECUCIÓN Automático Automático Automático Automático Automático Manual Manual Automático PROCESO Control de Inventario Obtener Estado Actual de los Recursos Esperar Lectura Identificar Recurso Obtener Reserva Asociada Registrar Movimiento MODO DE EJECUCIÓN Automático Manual Automático Automático Manual 113

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 hombremá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. 114

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. 115

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. 116

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. 117

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. 118

Objeto: Proceso 1, Mostrar estado actual Tipo: Automático de los recursos 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. 119

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 Tipo: Automático asociada 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. 120

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. 121

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. 122

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. 123

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: 124

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 125

En las filas se colocan los procesos y en las columnas las entidades y relaciones del modelo de datos. Una vez definida la matriz, se deben localizar las transacciones que componen el sistema. Las transacciones son conjuntos de procesos que transforman la 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 126

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 127

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: 128

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: 129

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. 130

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. 131

6. Diseño Interno 132

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. 133

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. 134

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. 135

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. 136

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. 137

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. 138

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. 139

Control de Visitas Control de Inventario 140

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 141

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. 142

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. 143

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. 144

Control de Visitas Control de Inventario 145

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. 146

Control de Visitas Control de Inventario 147

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. 148

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. 149

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. 150

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. 151

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 152

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 153

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 154

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. 155

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. 156

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 157

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 158

7. Programación 159

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. 160

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. 161

7.1.2. Ciclo de desarrollo orientado a objetos El ciclo de desarrollo OO consiste en un modelo incremental o evolutivo, donde cada incremento se desarrolla sobre las mismas etapas de la 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. 162

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. 163

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. 164

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 165

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. 166

Caso de Uso de Control de Visitas Control de Visitas tiene un único Caso de Usos que es el de Registrar Visita, el cual representa la única funcionalidad de negocio de la 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 167

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 168

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 169

Diagrama de Clases Detallado de Control de Inventario Diagrama de Casos de Uso Detallado Un caso de uso muestra la manera de interactuar con el sistema. Cuando se 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. 170

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. 171

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. 172

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 173

5a. El sistema no registra correctamente la visita. 1. El sistema muestra un mensaje informando que ha ocurrido un error y no se ha registrado correctamente la visita. 2. El sistema reinicia el servicio de lectura pasando al estado de espera de lectura. 7a. El usuario selecciona 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 174

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 175

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. 176

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 177

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. 178

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 179

1a1a. El sistema no actualiza con éxito la reserva asociada 1a1a1. El sistema muestra el mensaje de error. 1a1a2. El sistema pasa al estado de 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 180

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. 181

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 182

8. Pruebas 183

Tras desarrollar y finalizar las aplicaciones correspondientes a los controles de acceso, deben realizarse una serie de pruebas para garantizar el correcto funcionamiento de las mismas, y verificar que se cumplen con los requisitos funcionales determinados en las etapas de iniciales del proyecto. Así, el objetivo principal de esta etapa es el de someter al sistema desarrollado y a sus componentes, a una serie de comprobaciones encaminadas a garantizar un nivel de fiabilidad aceptable. Esta fase es 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. 184

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. 185

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. 186

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. 187

9. Implantación 188

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. 189

10. Conclusiones 190

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. 191

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 192

11. Glosario de Términos 193

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. 194

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. 195

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. 196

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 197

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 198

12. Bibliografía 199

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 200

Chips RFID de Temic/Atmel: http://www.atmel.com/atmel/products/prod26.htm Algunas aplicaciones interesantes: http://www.capta.com.mx/solucion/ems_rf_id_tags.htm 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 201

Anexo 1 Manual de Usuario Control de Visitas 202

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 203

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. 204

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. 205

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: 206

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. 207

Proporcionados los datos iniciales, el usuario debe confirmar la persona que es visitada para definir finalmente la visita gestionada. Para ello es necesario realizar la 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. 208

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. 209

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). 210

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. 211

Anexo 2 Manual de Usuario Control de Inventario 212

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 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 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 216 216 216 217 218 220 223 226 226 228 228 228 229 229 230 230 231 231 231 213

Capítulo Página 5. Ubicación de las tarjetas para la lectura y escritura RFID 233 214

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). 215

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. 216

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. 217

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. 218

Otro elemento importante del interfaz de usuario es el que indica el tipo de movimiento que se puede realizar sobre un recurso, Prestar si se trata de la entrega de un recurso, o Devolver : Como se puede observar en la imagen anterior, tras la 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. 219

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 : 220

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. 221

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. 222

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 : 223

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. 224

El comentario que se desee escribir no debe ser superior a 16 caracteres debido a las restricciones de las tarjetas RFID; si se supera se mostrará el siguiente mensaje de error: 2. A 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: 225

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. 226

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. 227

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. 228

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. 229

El acceso a la base de datos del personal del departamento ha fallado: 1.1. Verificar el estado de la base de datos card_personal en el servidor. 1.2. Comprobar el driver de acceso a dicha base de datos. 4.5. La fecha de 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 230

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 231

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. 232

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. 233

Anexo 3 Manual de Instalación 234

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 235

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. 236

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. 237

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. 238

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: 239

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. 240

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 241

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. 242

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. 243

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. 244

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. 245

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. 246

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. 247