SISTEMAS DE CONTROL DE ACCESOS A EDIFICIOS ...desarrollar dos tecnologías de control de acceso,...

PROYECTO FIN DE CARRERA

SISTEMAS DE CONTROL DE ACCESOS A EDIFICIOS MEDIANTE TARJETAS

CRIPTOGRÁFICAS Y TARJETAS RFID

AUTOR: MARTA VELAYOS SARDIÑA

MADRID, JUNIO 2007

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO EN INFORMÁTICA

Proyecto Fin de Carrera Ingeniería Técnica Superior de Informática Sistema de Control de Accesos a Edificios

I

RReessuummeenn


II

1. Descripción general del Sistema

El proyecto Sistema de Control de Accesos a Edificios tiene como objetivo estudiar y

desarrollar dos tecnologías de control de acceso, basadas en la utilización de tarjetas

inteligentes y tarjetas de radiofrecuencia (RFID). Se ha desarrollado un sistema

destinado al Instituto de Investigación Tecnológico (IIT) de la Universidad Pontificia

Comillas, capaz de realizar dos tipos de controles de seguridad: por un lado, un control

de acceso del personal de dicho departamento y por otro lado, un control de inventario.

2. Aplicación de Control de Visitas

La primera aplicación que constituye el sistema final es Control de Visitas, destinada a

registrar las visitas que se realicen en el centro. Este subsisema utiliza la tecnología de

tarjetas inteligentes, de manera que se comunica con un lector LTCX conectado al

ordenador del usuario final a través de un puerto USB. Control de Visitas tiene como

finalidad proporcionar una aplicación que permita al responsable del punto de control

llevar a cabo la gestión de las visitas que tengan lugar. Esta gestión consiste en:

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

Universidad.


III

� Determinar la persona que se quiere

visitar: Consiste en seleccionar el

nombre del empleado a visitar de una

lista obtenida de la base de datos del

personal del departamento. En esta lista

se proporcionan los campos de la

extensión y el despacho donde se puede

localizar el empleado en cuestión, y así

facilitar su localización.

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

3. Aplicación Control de Inventario

Se ha desarrollado la aplicación de Control de Inventario, destinada a llevar a cabo un

seguimiento del estado de los recursos prestables (ordenadores portátiles, cámaras

digitales) que proporciona el departamento a sus empleados. La gestión de los

préstamos y devoluciones de los recursos se ha implantado con la tecnología de

radiofrecuencia, de manera que para realizar este control el sistema se comunica con un

lector RFID, conectado al ordenador donde se ejecuta la aplicación a través de un puerto

USB. La identificación de los recursos se consigue a partir de las tarjetas RFID que se

han asignado a cada uno de los equipos. Cuando se desee registrar un movimiento, se

procederá a leer el TAG designado al recurso, y el lector RFID transmitirá los datos de

la lectura al sistema, el cual es el responsable de llevar a cabo la gestión correspondiente

del movimiento asociado. El sistema se encuentra integrado con la aplicación de

“Reservas Online” donde cada empleado puede realizar la reserva del equipo que

necesite durante un periodo determinado.


IV

4. Conclusión

Se han desarrollado dos aplicaciones de control de acceso, las cuales se han implantado

utilizando dos tecnologías de identificación diferentes. Las ventajas más importantes

que se han conseguido son:

Control de Visitas: Tecnología de tarjetas inteligentes

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

tiempo de cómputo que supone, al realizar la lectura de las tarjetas con esta

tecnología, incluyendo el caso de que no se disponga del carnet de alumno.

� Almacenamiento automático de toda la información relativa a la visita: visitante,

visitado, hora…

� Ayudar al usuario final proporcionando información relativa a los empleados del

departamento: extensión, despacho…

Control de Inventario: Tecnología RFID

� Llevar a cabo un seguimiento detallado del estado de los recursos del IIT.

� Rápida identificación de los recursos a partir de la lectura RFID de los TAGs.

� Optimizar las tareas manuales y los procesos de negocio reduciendo los errores

de gestión, y sincronización del sistema con la base de datos de reservas.


V

AAbbssttrr aacctt


VI

1. General description of the system

The main aim of Buildings Access Control System’s project is to study and develop two

different control access technologies which are based on the use of Smart cards and

radiofrecuency ID cards. This system has been developed for the Institute for Research

in Technology (IIT) of Pontificia Comillas University, and it is able to perform two

types of security access: an access control of the department’s visits, and an inventory

control.

2. Access Control Application

The first application, that forms the final system, is Access Control Application, used to

register visits to the building. This subsystem uses the intelligent cards technology, so it

has to communicate with a LTCX reader connected to the final user’s computer through

a USB port. The purpose of Visits Control is to provide an application that allows the

person is in charge of security control point for management. This management consists

of: identifying the visitor and registering his/her name.

This is done by:

� Reading of the University student card


VII

� Determining the person which is

visited: It consist of selecting the

employ’s name from a list

generated form database of

personnel. In this list, the phone

and room number of the employ

are also shown to facilitate

contacting with the person to

announce the visit.

� Confirmation the storage of the visit data into database.

3. Inventory Control

It has been developed the application Inventory Control which is responsible of

monitoring the status of shared resources (portable computers, digital cameras) provided

by the IIT department to its employees. The loans and returns’ management has been

implemented with the radiofrecuency technology, so to do this kind of control the

system has to communicate with a RFID reader, which is connected through a USB port

to the computer where the application is running. The resources’ identification is

performed with RFID cards attached to each equipment. To register good movements,

the RFID reader will read the resource’s TAG, and it will send the information to the

system which is responsible for managing that movement. The system is synchronized

with a database of reservations where the employees can define which equipment they

need and which dates.


VIII

4. Conclusion

Two access control applications have been developed and implemented using two

different identification technologies. The main features attained are:

Visit Control: Smart Card Technology

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

the visit doesn’t have an ID card) since ID cards is read using this technology.

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

visitor’s name, employ visited, date-time.

� Help the user during the registration process by providing information about the

employees: extension and room number.

Inventory Control: RFID Technology

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

resources.

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

� To optimize the manual tasks and business process to reduce the management

mistakes. Equipments are identified automatically and the system is

synchronized (query and update) with the database of reservations.


IX

ÍÍ nnddiiccee


X

Capítulo

Página

1. Plan de Gestión del Proyecto

1.1. Introducción

1.2. Definición del proyecto

1.3. Diagrama de Actividades

1.4. Descripción detallada de las Actividades

1.5. Organigrama del equipo de trabajo

1.6. Funcionalidad de los integrantes del equipo de trabajo

1.7. Estimación y presupuesto

1.8. Planificación de alto nivel

1

2

2

3

8

12

13

16

23

2. Documento de Conceptos del Sistema

2.1. Objetivos del sistema

2.2. Alcance del sistema

2.3. Tipología de los usuarios finales

2.4. Restricciones

2.5. Antecedentes

24

25

25

28

28

30

3. Análisis de Requisitos

3.1. Ámbito del proyecto

3.2. Contexto general del sistema

3.3. Evaluación y análisis

3.4. Modelo Físico

3.5. Modelo Lógico

3.6. Modelo Conceptual de datos

31

32

35

36

47

63

67

4. Estudio de la Arquitectura

4.1. Especificación de la tecnología hardware

4.1.1. Tarjetas Inteligentes

74

75

75


XI

Capítulo

Página

4.1.1.1. ISO 7816

4.1.1.2. Tipos de Tarjetas Inteligentes

4.1.1.3. Sistema de Ficheros

4.1.1.4. Métodos de Acceso a la TI

4.1.1.5. Lector LTCX

4.1.2. Tecnología RFID

4.1.2.1. Funcionamiento

4.1.2.2. Protocolos y Opciones

4.1.2.3. Etiquetas RFID: TAGS

4.1.2.4. Estándar Mifare

4.1.3. Plataforma donde reside el sistema

4.2. Especificación de la tecnología software y de comunicaciones

4.3. Arquitectura final del sistema

4.4. Evaluación Económica

4.5. Elaboración del Plan de Proyecto

75

79

82

82

85

86

88

89

90

92

93

93

94

95

99

5. Diseño Externo

5.1. Requisitos físicos del nuevo sistema

5.1.1. Entono operativo del sistema

5.1.2. Configuración hardware/software

5.2. Desarrollo del Modelo Físico Final

5.2.1. Fronteras de Mecanización

5.2.2. Especificación de Procesos

5.2.3. Diseño de Entradas

5.2.4. Diseño de Salidas

5.2.5. Estimación de Volúmenes de Información

5.2.6. Procesos de Control y de Seguridad

102

103

103

108

111

113

116

121

123

124

128


XII

Capítulo

Página

6. Diseño Interno

6.1. Técnicas a utilizar

6.2. Subsistema online

6.2.1. El Diagrama de Cuadros Estructurado (STC)

6.2.2. Derivación del DFD al STC

6.2.3. Consideraciones de diseño

6.3. Diagrama del Sistema

6.4. Cuaderno de Carga

132

134

135

136

139

148

149

150

7. Programación

7.1. Análisis y diseño orientado a objetos

7.1.1. Introducción

7.1.2. Ciclo de desarrollo orientado a objetos

7.1.3. Técnicas OO en las fases de la metodología

7.2. Manual de Usuario

7.2.1. Manual de Usuario de Control de Visitas

7.2.2. Manual de Usuario de Control de Inventario

159

161

161

162

163

180

182

182

8. Pruebas

183

9. Implantación

188

10. Conclusiones

190

11. Glosario de Términos

193

12. Bibliografía

199


XIII

Capítulo

Página

Anexo 1

202

Anexo 2

212

Anexo 3 234


1

11.. PPllaann ddee GGeesstt iióónn


2

1.1. Introducción

El presente documento define el Plan de Gestión del proyecto Sistema de Control de

Accesos, PSCA, contemplando los objetivos y alcance del proyecto, la estructura

jerárquica de las actividades principales describiendo una de ellas, la organización del

equipo de trabajo especificando la funcionalidad de uno de los perfiles, la estimación y

presupuesto, y la planificación determinada para la realización de dicho proyecto.

1.2. Definición del Proyecto

Se desea desarrollar un sistema, destinado al Instituto de Investigación Tecnológico

(IIT) de la Universidad Pontificia Comillas (UPCO), capaz de realizar dos tipos de

controles de seguridad: por un lado, un control de acceso de visitas de dicho

departamento, de manera que facilite la gestión y el registro de las vistas que reciben

cada uno de los empleados, tanto de alumnos, como de personas ajenas a la

Universidad; y por otro lado, un control de inventario que permita llevar a cabo un

seguimiento de los ordenadores portátiles que proporciona el IIT a sus empleados, con

el objetivo de que éstos puedan utilizarlos en lugares o contextos externos al dominio de

la universidad.

El control de visitas se implantará utilizando la tecnología de tarjetas inteligentes, de

forma que cuando se atienda la llegada de una persona en el departamento, se solicitará

su carnet de identificación personal para proceder a realizar el registro correspondiente.

Por último, el Control de Inventario se realizará a partir de la utilización de un lector

de radiofrecuencia (RFID), de manera que cuando se desee registrar un préstamo o una

devolución de alguno de los ordenadores portátiles, proporcionados por el IIT, se deberá

mostrar al lector el TAG RFID que posee el recurso, para realizar el proceso de

identificación del mismo.


3

1.3. Diagrama de Actividades

En este apartado se muestran las actividades principales que constituyen el desarrollo

del proyecto PSCA, clasificadas por nivel de detalle:


4

A continuación, se completa el diagrama de Actividades del proyecto Sistema de

Control de Accesos a Edificios, desglosando cada uno de los paquetes en las tareas que

se han de llevar a cabo durante su estudio y desarrollo.

• Actividad PSCA02

• Actividad PSCA03.1


5




6




7




8

1.4. Descripción detallada de las Actividades

En este punto del plan de gestión se proporciona una breve descripción de los paquetes

de trabajo de primer y segundo nivel, según corresponda, que constituyen el desarrollo

completo del presente proyecto.

PSCA01.1 REUNIÓN DE LANZAMIENTO

Primera reunión del proyecto entre el alumno y el director. Tiene como objetivo

determinar el alcance del proyecto inicial y las pautas que se van a seguir para el

desarrollo del mismo.

PSCA01.2 PLAN DE GESTIÓN DEL PROYECTO

Se corresponde con la elaboración del Plan de Gestión del proyecto que se va a llevar a

cabo. Dicho plan supone una primera aproximación a los objetivos y alcance del

proyecto, y proporciona los diferentes paquetes de trabajo que se han de estudiar y

analizar para afrontar el proceso de desarrollo del sistema que se quiere obtener.

PSCA02 GESTIÓN DEL PROYECTO

Paquete de trabajo que tiene como principal finalidad la de realizar un seguimiento

continuo del proceso de desarrollo, garantizando que se satisfacen los requisitos

establecidos y las restricciones impuestas.

Esta Actividad engloba también la elaboración de la documentación correspondiente a

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

documento final.


9

PSCA03.1 INDETIFICACIÓN DE NECESIDADES

Tarea que se comporta como soporte a la petición que el director del proyecto realiza

para determinar las pautas generales de las necesidades determinadas y del contexto del

sistema. La información recogida durante esta etapa se especifica en un Documento de

Conceptos del Sistema.

PSCA03.2 ANÁLISIS DE REQUISITOS

El objetivo de este paquete de trabajo es alcanzar un conocimiento suficiente del

sistema, definiendo las necesidades, los problemas y requisitos del usuario. Todo ello

debe ser expresado mediante dos modelos: de procesos y de datos.

Se obtiene un modelo de procesos físico del sistema, y a partir de él se deduce el

modelo de procesos lógico el cual recoge las funciones esenciales del negocio

PSCA03.3 ESTUDIO DE LA ARQUITECTURA

El objetivo de esta Actividad es definir la solución de arquitectura técnica que satisface

tanto los requisitos como las restricciones del diseño. La arquitectura debe indicar qué

componentes software, hardware y de comunicaciones han de adquirirse o

desarrollarse.

La solución deberá dar una visión externa del sistema, los requisitos físicos que se

tienen que tener en cuenta, así como los aspectos organizativos, operativos, técnicos y

económicos asociados.


10

PSCA03.4 DISEÑO EXTERNO

En esta etapa se completa la definición de las especificaciones del sistema a mecanizar,

obteniéndose el modelo físico final de procesos y el modelo lógico de datos, de

acuerdo a la plataforma hardware y software definida en la tarea anterior.

Además, esta Actividad elabora la estrategia que se ha de llevar a cabo en las etapas de

Pruebas e Implantación, la formación de los usuarios y las conversiones necesarias de

hardware y software del sistema actual al nuevo.

PSCA03.5 DISEÑO INTERNO

Esta tarea identifica y diseña los diversos componentes software del sistema,

describiendo detalladamente sus características físicas. Dependiendo de la arquitectura

escogida para el desarrollo, estos componentes pueden ser muy diversos. Debido a esta

heterogeneidad, el sistema se puede dividir en diversos subsistemas dependiendo de la

tipología de los procesos, y así especificar y diseñar sus componentes.

PSCA03.6 PROGRAMACIÓN

El objetivo de este paquete de trabajo es alcanzar la transformación del sistema en un

conjunto de programas que puedan ser ejecutados satisfactoriamente bajo unos criterios

de calidad. La dificultad se encuentra en cómo realizar la transformación de la mejor

manera posible ya que depende en gran medida del lenguaje de programación y de las

herramientas software disponibles.


11

PSCA03.7 PRUEBAS

Desarrollados y probados cada uno de los programas y componentes que constituyen el

software, deben realizarse una serie de pruebas para conseguir integrar todo el sistema,

de acuerdo al Plan de Pruebas establecido en la etapa de Diseño Interno.

El objetivo global de esta tarea es someter al sistema desarrollado y a sus componentes

a una serie de verificaciones encaminadas a garantizar un nivel de fiabilidad aceptable.

PSCA03.8 IMPLANTACIÓN

Después de probar la integridad del software del sistema y especificada su instalación y

configuración, se debe instalar el software producido en el entorno de trabajo o Centro

de Producción para llevar a cabo la explotación del sistema final. De forma que su

objetivo es el de implementar el nuevo sistema en la producción real.

PSCA04 CIERRE DEL PROYECTO

Esta actividad engloba tanto la reunión de aceptación con el director y con el

coordinador del proyecto, como l elaboración de una copia tanto de la documentación

final como del software que se ha producido. A su vez, se debe proporcionar un

resumen de todo el proyecto que se almacenará en el sistema de documentación de la

universidad.


12

1.5. Organigrama del equipo de trabajo

El equipo de trabajo del proyecto que se va a realizar, está formado por cuatro

participantes claramente diferenciados. Por un lado, se han definido las entidades del

director y del coordinador del proyecto, los cuales son las personas responsables de

controlar y verificar el correcto desarrollo del proyecto, siendo la figura del director

mucho más importante debido a su mayor grado de implicación en el mismo.

La figura del alumno se corresponde con la persona destinada a estudiar, diseñar y

desarrollar el proyecto propuesto por el director. Durante todo el proceso de desarrollo,

el alumno deberá reunirse con el director, ya sea para las reuniones iniciales, como para

verificar todo el trabajo que se haya realizado hasta ese momento, relación muy

diferente a la existente con el coordinador, ya que sólo se realizarán dos o tres reuniones

a lo largo del ciclo de vida del proyecto.

Por último, el alumno deberá relacionarse con el usuario final de la aplicación para

consolidar aspectos de diseño o mejoras del mismo, así como otros aspectos no

funcionales.


13

1.6. Funcionalidad de los integrantes del equipo de trabajo

En el siguiente punto se recoge la funcionalidad que desempeña el perfil del

coordinador en el equipo de trabajo definido en el apartado anterior.

Director del Proyecto: DPFC

La labor del Director del proyecto consiste principalmente en conseguir que el alumno

desarrolle un PFC de calidad, ayudándole desde el punto de vista técnico y funcional y

motivándole para que cumpla los plazos establecidos. El Director podrá ser un Profesor

de la Escuela de Ingeniería o un ingeniero (o titulado superior) normalmente en

ejercicio de la profesión que haya mostrado interés por un proyecto determinado.

El Director es responsable de:

• Proponer un proyecto con calidad suficiente y establecer los objetivos y el

alcance del mismo.

• Facilitar al alumno las orientaciones adecuadas ante los problemas que puedan ir

surgiendo en el desarrollo del proyecto. Esto no implica que el director o tutor

del proyecto resuelva los problemas ya que se está examinando la capacidad del

alumno para hacerles frente.

• Supervisar la realización del proyecto, la calidad de sus contenidos, y verificar

que se desarrolla de acuerdo con las normas establecidas, consultando con el

Coordinador de Proyectos las posibles dudas que le puedan surgir.

• Dar su opinión sobre el alumno y el trabajo realizado rellenando el formulario

elaborado al efecto y entregándoselo al correspondiente Coordinador.


14

En general ningún director podrá dirigir más de 8 proyectos distintos en el mismo curso

académico, las excepciones a esta regla deberán ser autorizadas por el Coordinador

General.

Coordinador del Proyecto: CPFC

Cada Coordinador será responsable de la calificación de los proyectos que coordina. A

principio de curso cada Coordinador deberá pasar a su correspondiente Jefatura de

Estudios, informando al Coordinador General, la lista de los alumnos coordinados por

él, para que desde Jefatura se soliciten las correspondientes actas. Cada Coordinador

tendrá asignada una hora semanal en el horario para realizar el seguimiento de los

alumnos y proyectos.

Las tareas asignadas a cada Coordinador son:

• Buscar proyecto-director a los alumnos que no tengan ningún proyecto asignado.

• Concretar la definición del proyecto.

• Recoger solicitudes de alumnos para cada proyecto.

• Asignar a cada alumno su proyecto.

• Presentar alumno/a al director del proyecto.

• Controlar/supervisar el trabajo de cada alumno, con el director del proyecto (al

menos 2 veces por proyecto).

• Comunicarse con el alumno para supervisar ritmo e incidencias (al menos 2

veces por proyecto).


15

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

determinado nivel o presenten defectos de forma. Finalizado el proyecto, el

alumno entregará al Coordinador un ejemplar visado por su director de proyecto,

junto con un resumen. (En las titulaciones de informática, para el examen de

Reválida, el alumno llevará, junto con el material que considere necesario para

realizar la exposición de su proyecto, otros DOS ejemplares de su Proyecto).

• Calificar a los alumnos y firmar las actas, como profesor de esta asignatura. Una

vez calificado cada proyecto será devuelto al alumno con el visado del

Coordinador y el alumno lo deberá entregar junto con una copia del resumen en

Secretaría General en el momento de realizar la matrícula de Reválida.

Alumno del Proyecto: APFC

El alumno ha de realizar las siguientes tareas propuestas y evaluadas por el Coordinador

de Proyectos:

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

cuando sean proyectos propuestos por profesores u otros coordinadores de la

Escuela. Con el visto bueno del Coordinador el alumno puede comenzar su

proyecto oficialmente y debe proceder a realizar las tareas que le corresponden.

Todos los proyectos deberán tener el visto bueno del correspondiente

Coordinador, a más tardar en la última semana del mes de Octubre.

• Cada alumno deberá preparar de común acuerdo con su director de proyecto un

documento que describa el Proyecto a realizar siguiendo el formato que se

adjunta en el Anexo B. La memoria descriptiva se entregará antes de hacer la

primera presentación. El Coordinador fijará una fecha para la entrega de la

memoria, siendo en la última semana del mes de Noviembre la más tardía.


16

• El seguimiento del proyecto se realizará a través de la clase semanal planificada.

Durante estas sesiones el alumno de acuerdo con la programación establecida

por el coordinador deberá presentar los objetivos, el plan de trabajo y los

avances realizados en su proyecto.

• Durante el segundo y tercer trimestre del curso el alumno hará dos exposiciones

públicas de avance de su proyecto. En general, se realizarán una exposición de

avance y otra a la finalización del trabajo.

• El alumno debe asistir al menos al 50% de las clases de la asignatura.

1.7. Estimación y Presupuesto

A partir de la jerarquía de Actividades diseñada en el punto 1.3 se va a realizar un

estudio de la asignación de recursos para el desarrollo del proyecto. Dicha asignación

permitirá estimar el presupuesto correspondiente al proceso de diseño del sistema final.

Estimación de recursos

La estimación realizada sólo tiene en cuenta los paquetes de trabajo descritos en el

apartado 1.4 ya que permiten tener una perspectiva lo suficientemente detallada como

para poder estudiar la evolución del proceso de desarrollo y asignar las horas/hombre

que se consideren necesarias para cada Actividad.

Antes de realizar la red Pert correspondiente a los niveles considerados de la EDT, se

lleva a cabo un estudio de la relación temporal entre las Actividades. Dicha relación

permitirá entender la evolución del progreso de desarrollo de los paquetes de trabajo, al

igual que la definición de las duraciones de cada uno de ellos.


17

La relación temporal muestra los requerimientos de inicio de una Actividad, en el

sentido de determinar qué Actividad ha de estar finalizada antes de comenzar el

desarrollo de la siguiente.

Los requisitos temporales existentes para llevar a cabo las Actividades que constituyen

el nivel 1 y 2 de la EDT son los siguientes:

Paquete de Trabajo Actividad Predecesora Duración

PSCA01.1 No tiene 1 día (0’033 meses)

PSCA01.2 PSCA01.1 5 días (0’2 meses)

PSCA02 PSCA01.2 270 días (9 meses)



PSCA03.3 PSCA03.2 30 días (1 mes)


PSCA03.5 PSCA03.4 30 días (1 mes)




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.


18

La Red Pert a su vez permitirá definir las fechas de inicio y finalización de cada uno de

los paquetes de trabajo, satisfaciendo la relación temporal entre ellas y la fecha de

entrega del proyecto final.

La flexibilidad que presenten determinadas Actividades proporcionará la posibilidad de

cambiar su organización inicial de tal forma que se garantice un desarrollo del proyecto

uniforme desde el punto de vista de la asignación de recursos, en este caso de las

horas/hombre que se han de dedicar en cada una de dichas Actividades.

La Red Pert correspondiente a este proyecto de gestión, valorando la duración en días,

es la siguiente:

El camino crítico del proyecto lo constituyen las actividades de gestión: las dos

primeras etapas de inicio y elaboración del Plan de Gestión, la propia Actividad de

Gestión global del proceso de desarrollo y la tarea de Cierre del Proyecto.


19

La asignación del número de horas/hombre que se van a trabajar en cada uno de los

paquetes de trabajo es la que se adjunta en la siguiente tabla:

1 2 3 4 5 6 7 8 9 TOT

PSCA01.1

CPFC 1 1

DPFC 3 3

APFC 3 3

PSCA01.2

CPFC

DPFC 2 2

APFC 20 20

PSCA02

CPFC 10 10

DPFC 20 10 10 10 10 10 10 10 90

APFC 10 30 20 20 20 20 20 10 10 160

PSCA03.1

CPFC

DPFC 10 10

APFC 30 30

PSCA03.2

CPFC

DPFC

APFC 30 30

PSCA03.3

CPFC

DPFC 10 10

APFC 80 80

TOTAL 109 140 30 30 30 30 30 20 30 449


20

1 2 3 4 5 6 7 8 9 TOT

PSCA03.4

CPFC 1 1

DPFC 10 10

APFC 80 80

PSCA03.5

CPFC

DPFC 5 5 10

APFC 20 60 80

PSCA03.6

CPFC

DPFC 30 30

APFC 50 80 80 210

PSCA03.7

CPFC

DPFC 10 10

APFC 30 30

PSCA03.8

CPFC

DPFC 10 10

APFC 30 30

PSCA04

CPFC 25 25

DPFC 25 25

APFC 20 20

TOTAL1 109 140 30 30 30 30 30 20 30 449

TOTAL 109 140 146 95 110 110 110 100 100 1020

El número total de horas/hombre que se ha estimado dedicar en todo el proyecto es de

1020 horas, teniendo en cuenta el trabajo realizado por el director y por el coordinador

además del que ha llevado a cabo el alumno.


21

Para tener una visión general de la evolución de la dedicación a lo largo del proyecto, se

han representado las horas/hombre que se han estimado trabajar por cada uno de los

meses que constituyen la duración completa del proyecto:

Se puede observar que entre el primer mes y el tercero hay un incremento constante del

número de horas a trabajar debido a que se pretenden finalizar cinco etapas del

desarrollo más la documentación correspondiente de cada una de ellas.

Tras el primer trimestre se produce un descenso considerable de la dedicación debido a

que se corresponde con el momento de preparación de los exámenes de febrero y de

dedicación para terminar las prácticas finales del primer periodo del curso.

La etapa final del proyecto, correspondiente a los últimos cuatro meses, se caracteriza

por ser mucho más uniforme el esfuerzo que hay que emplear para realizar las tres

últimas etapas del desarrollo.


22

Calculadas las horas de trabajo a emplear, a continuación se realiza el estudio del

presupuesto inicial que se asigna al proyecto.

Estudio del Presupuesto

El coste total del trabajo realizado por los integrantes del equipo de trabajo del proyecto

es el que se muestra en la siguiente tabla:

INTEGRANTE HORAS/HOMBRE €/HORA TOTAL

CPFC 37 60 2220

DPFC 210 60 12600

APFC 773 30 23190

TOTAL 38010

Por tanto, si consideramos el coste de los recursos software o hardware que se han

adquirido para realiza el proyecto además del coste total del equipo de trabajo,

obtenemos el presupuesto inicial estimado para el desarrollo del proyecto:

Recurso Total €

Subtotal Equipo de trabajo: 38010

Lector Inteligente 200

Lector RFID 300

Tags RFID 50

Desplazamiento 300

Comunicaciones 200

Subtotal recursos: 1050

Total Final 39060


23

1.8. Planificación de alto nivel

La planificación que determina el desarrollo y evolución del proyecto Sistema de

Control de Accesos, se muestra a continuación:


24

22.. DDooccuummeennttoo ddee CCoonncceeppttooss

ddeell SSiisstteemmaa


25

2.1. Objetivos del sistema

Se desea desarrollar un sistema, destinado al Instituto de Investigación Tecnológico

(IIT) de la Universidad Pontificia Comillas (UPCO), capaz de realizar dos tipos de

controles de seguridad: por un lado, un control de acceso del personal de dicho

departamento, de manera que facilite la gestión y el registro de las vistas que reciben

cada uno de los empleados, tanto de alumnos, como de personas ajenas a la

Universidad; y por otro lado, un control de inventario que permita llevar a cabo un

seguimiento de los ordenadores portátiles que proporciona el IIT a sus empleados, con

el objetivo de que éstos puedan utilizarlos en lugares o contextos externos al dominio de

la universidad.

2.2. Alcance del sistema

El Sistema Control de Accesos a Edificios requiere la definición de dos funciones de

negocio claramente diferenciadas entre sí:

Control de Visitas

Se requiere de un Control de Visitas que permita consultar en cualquier momento el

listado de qué empleados se encuentran en el edificio, y a su vez, identificar a las

personas que solicitan ser atendidas por un miembro particular del departamento del

IIT.

Todas las visitas deberán ser recogidas en la correspondiente base de datos, facilitando

el registro, además de los alumnos que desean ser atendidos por un profesor de dicho

departamento, el de aquellas personas que no disponen de la identificación de la

Universidad, y que por tanto, son ajenas a la misma.

El Sistema Control de Visitas deberá proporcionar, si es posible, las últimas visitas que

haya realizado en otros momentos la persona identificada, de forma que facilite la

gestión de la visita actual.


26

Control de Inventario

Paralelamente, se desea realizar un control de los ordenadores portátiles y de otro tipo

de recursos, como por ejemplo cámaras fotográficas, que el IIT proporciona a sus

empleados para que éstos puedan utilizarlos en ámbitos externos a la Universidad.

Dicho control se realizará a partir de la gestión de las entradas y salidas del material

suministrado, así como de la identificación y registro de las personas que deseen utilizar

o recoger dicho recurso.

Además, el sistema de Control de Inventario debe estar integrado con un sistema de

reservas previamente existente: “Reservas Online”.

Recopilación y carga de datos

El sistema debe tener acceso a las BBDD que recogen todos los datos sobre el personal

que trabaja en el departamento IIT, información referente a las visitas que han sido

registradas con anterioridad, así como de los recursos informáticos que se encuentran

disponibles y la información de reservas para el Control de Inventario.

Cada visitante y personal del IIT quedarán perfectamente definidos mediante una serie

de datos personales que definen su perfil, de acuerdo al diseño de las tablas que

constituyen las BBDD creadas para la gestión deseada.

Del mismo modo, el control que se realizará sobre los ordenadores portátiles permitirá

conocer en cada momento qué recurso está disponible o cuándo ha de ser devuelto y por

quién, de manera que todos los movimientos sobre dicho material quede recogido en la

base de datos para conseguir un seguimiento eficiente de los mismos.


27

Acceso a la información

Su misión es, la de dotar al sistema de las herramientas necesarias para proporcionar las

diferentes funcionalidades que requiere el usuario final, el vigilante, a la hora de realizar

los controles de seguridad. El papel que desempeña el usuario solo adopta especial

importancia cuando se realiza el control de acceso de los visitantes. El vigilante es la

persona encargada de introducir la tarjeta en el lector y de seleccionar el empleado del

departamento a visitar, y cuando se gestiona un movimiento asociado a un recurso que

implica la lectura del TAG RFID y su confirmación para poder registrarlo en la

correspondiente base de datos para poder actualizar el estado del recurso.

Administración y control del entorno

Tiene como objetivo la gestión de los datos y de los procesos tratados por el sistema.

Para ello, se contará con la figura de un administrador que se corresponde con el usuario

final, el cual es el responsable de llevar a cabo los controles de acceso a través de la

ejecución de las aplicaciones correspondientes y de la manipulación de los lectores

utilizados para la lectura de las tarjetas de identificación. Sin embargo, la información

almacenada que maneja el sistema no requiere de un control como tal ya que no puede

ser manipulada directamente por el usuario final ni por otra persona ajena a la

utilización del sistema. Es la propia aplicación la que lleva a cabo las operaciones contra

las bases de datos correspondientes y porque éstas residen en un servidor al que sólo se

puede acceder, en principio, como administrador del mismo.

El perfil del usuario final se corresponde con una persona que trabaja en la universidad

Comillas, y que se encuentra en la recepción del edificio, controlando las llegadas, tanto

de personas como de documentos.

La aplicación residirá en un PC restringido, al cual sólo tienen acceso las personas cuyo

perfil se corresponda con el que se ha comentado anteriormente.


28

2.3. Tipología de los usuarios finales

Los usuarios del sistema, serán exclusivamente las personas que trabajan en Comillas,

encargadas de controlar y gestionar los acontecimientos diarios que se produzcan en la

universidad, así como de afrontar y comunicar cualquier problema o incidencia que

tenga lugar.

En cada uno de los edificios que constituyen la universidad Comillas, se encuentran

varias personas que se corresponden con este perfil, y que gracias a ellas se puede llevar

a cabo una importante administración y gestión de todo lo que ocurre en cada uno de los

edificios referenciados. Sin embargo, sólo vamos a tener en cuenta el edificio donde se

encuentra el departamento del IIT, el cual es el destino del sistema que se va a

desarrollar, y por tanto, los usuarios de mismo, serán las personas que se adecuen al

perfil indicado que tengan que trabajar en el IIT.

2.4. Restricciones

El sistema que se ha de diseñar debe ser capaz de controlar dos tipos de accesos: el de

visitas y el de recursos prestables. Para ello, se ha decidido desarrollar dos aplicaciones,

bajo el lenguaje de programación Java, que se encarguen de gestionar y registrar los

accesos que se realicen en un momento dado en cada uno de los dos contextos

determinados.

Ambas aplicaciones deben estar sincronizadas en tiempo real con el servidor de bases

de datos, de manera que sea coherente la información del personal que pertenece al

departamento con la almacenada en la base de datos, así como la referente al material

que se proporciona.

Para llevar a cabo el control de acceso de las visitas es necesario que el sistema este

conectado con un lector de tarjetas inteligentes del tipo LTCX, de forma que será

necesario implantar las librerías y funciones adecuadas para que la aplicación Java sea

capaz de realizar la lectura de las tarjetas, y manipular los datos leídos de las mismas.


29

Al mismo tiempo, la aplicación deberá proporcionar dos funciones adicionales:

• Por un lado, la posibilidad de “Introducir datos a mano”, situación que se

corresponde con la llegada de un visitante que no posee su tarjeta en el momento

de la gestión del acceso, o con una persona que no es un alumno de la

universidad. En este caso, el administrador deberá introducir el nombre y los

apellidos del visitante por teclado, e indicar a que persona de la plantilla del IIT

viene a visitar. El registro de este tipo de visitas se realizará de la misma forma

que si se hubiese registrado con una tarjeta inteligente.

• Opción de “Consulta” . Se ofrece la posibilidad de generar un informes de

visitas a partir de un volcado de la base de datos a un archivo excel.

El control de inventario se realizará bajo la tecnología RFID, de manera que se asignará

un tag RFID a cada uno de los recursos que constituyen el inmovilizado prestable que

proporciona el IIT.

Cuando una persona de dicho departamento desee llevarse un recurso, deberá

identificarse, y si cumple las condiciones de autentificación, se procederá a determinar

el tipo de movimiento que se va a. Si se confirma el préstamo o la devolución, se

registrará la entrada o salida del recurso, según corresponda, y se actualizará su estado

de disponibilidad.

Adicionalmente, se contempla la escritura en el TAG de incidencias que alteren la

utilización de un recurso, bien porque este dañado físicamente, o las condiciones con

que se realiza un préstamo del mismo.

Al mismo tiempo, se ha de tener en cuenta una restricción de tipo económico, ya que los

recursos del proyecto necesarios para implantar el sistema en el IIT están financiados

por la universidad.


30

2.5. Antecedentes

El departamento del IIT dispone de un proyecto base que contempla la realización del

control de acceso del personal al edificio, de forma que se utilizará como punto de

partida para el diseño del Control de Visitas, con el objetivo de optimizar y refinar su

comportamiento.

Por otro lado, dicho departamento dispone de un lector de tarjetas situado a la entrada

del edificio, pero su funcionalidad se limita exclusivamente a la apertura de la puerta

principal tras introducir la tarjeta de empleado. Dicho control de acceso no permite

llevar a cabo un seguimiento de la presencia del personal en el edificio, ni de los

horarios que se cumplen cada día, de manera que no facilita la gestión de las visitas, y

mucho menos, el control de las personas que entran y salen del edificio.


31

33.. AAnnááll iissiiss ddee RReeqquuiissii ttooss


32

3.1. Ámbito del proyecto

Lectura de tarjetas inteligentes

El primer objetivo consiste en conseguir leer información de tarjetas inteligentes para

poder implantar una aplicación de ayuda a los vigilantes de un edificio para realizar el

registro de las visitas (descrita más adelante). Se trata de una aplicación Java capaz de

leer tarjetas inteligentes, de manera que pueda manipular y almacenar los datos

recogidos de cada una de ellas.

Se utilizará un lector estándar de tarjetas inteligentes que se corresponden con las

tarjetas de identificación que tiene la Universidad. Para alcanzar este objetivo se parte

del código desarrollado en un proyecto fin de carrera del año anterior.

Lectura de tarjetas RFID

Debido a la gran aceptación que esta experimentando la tecnología RFID, cada vez es

más frecuente la utilización de lectores y tarjetas RFID para realizar diferentes tareas,

como por ejemplo la implantación de los controles de acceso.

Las tarjetas RFID se consideran como una alternativa que sustituirá el empleo de

códigos de barras debido a las ventajas que proporciona la tecnología RFID, destacando

entre ellas la mayor longitud de los códigos de identificación, los cuales permiten que a

cada etiqueta se le pueda asignar uno único, mientras que los códigos UPC actuales, se

limitan a un código para identificar a todas la unidades de un producto en particular.

En este sentido los códigos RFID equivalen más al número de serie de un equipo que al

número de referencia del producto, pero un número de serie que sigue un formato

compatible entre todos los fabricantes.


33

El proyecto Sistema Control de Accesos contempla el diseño de una aplicación, en

principio en Java, destinada a interactuar con tarjetas RFID, de manera que por un lado

se realice una lectura de las mismas para poder efectuar un seguimiento de los objetos

controlados, y por otro su escritura, permitiendo la asignación de identificadores

unívocos, así como la introducción de información descriptiva del objeto al cual va a

identificar.

Comunicar el sistema con las bases de datos

Se han de diseñar las bases de datos necesarias para realizar el almacenamiento de la

información recogida en las lecturas de las tarjetas de identificación. Así mismo, las

bases de datos complementarán la funcionalidad de la aplicaciones que se van a diseñar.

Para ello, se dispone de un servidor Solaris/MySQL donde residirán las bases de datos

que requiere el sistema. Debido a que cada aplicación maneja un tipo de información,

será necesario crear diferentes bases de datos, de manera que se pueda facilitar el

mantenimiento de las mismas, así como garantizar la coherencia de los datos

almacenados.

De la misma forma, se han de diseñar y crear las tablas que constituyen cada base de

datos, estudiando los campos que van a contener cada una de ellas, como las

restricciones respecto a los valores que pueden tomar, incluidos los valores por defecto,

para así conseguir la coherencia tanto en el diseño como en el significado de cada uno

de los registros recogidos.

Desarrollo de las aplicaciones de control de acceso

La primera parte del proyecto consiste en terminar de programar y poner en

funcionamiento una aplicación base de control de acceso denominada Control de

Visitas.


34

Un prototipo de dicha aplicación fue desarrollado en otro proyecto fin de carrera, sin

embargo requiere la incorporación de nuevos servicios y la mejora de los ya existentes

para proporcionar de forma eficiente su funcionalidad, así como el perfeccionamiento

del diseño inicial para proporcionar un interfaz lo suficientemente explicativo e

intuitivo. La aplicación se desarrollará bajo el lenguaje de programación Java, y se

encargará de gestionar las visitas que recibe el personal del departamento de la

universidad IIT.

En el caso de visitas de alumnos, el registro de la visita requiere los datos personales del

alumno en particular, los cuales se consiguen mediante la lectura de la tarjeta de la

universidad, y los de la persona a la que viene a visitar. De esta forma, los registros de

visitas antiguos de un alumno en particular, permitirán agilizar el trámite de la nueva

visita que realice ya que lo más probable es que solicite ver a las mismas personas que

en ocasiones anteriores.

En la segunda parte del proyecto, se ha optado por el diseño de una aplicación que

permita obtener el máximo rendimiento de las diferentes ventajas que proporciona la

tecnología RFID. Por ello, se contempla la realización de un Control de Inventario

destinado a llevar a cabo un seguimiento de los recursos que proporciona el

departamento, así como la gestión de los movimientos asociados que se produzcan.

Para ello, se asignará a cada uno de los recursos del departamento un TAG RFID, de

manera que cuando tenga lugar su entrada o salida se podrá llevar a cabo su

identificación y la gestión de su movimiento asociado. Cuando se confirme un

determinado movimiento se registrará en la bases de datos correspondiente, y se

actualizará el estado del recurso con el objetivo de conocer en todo momento su

disponibilidad. Los movimientos pueden ser de dos tipos: préstamos y devoluciones. El

tratamiento de los préstamos determina la necesidad de que esta aplicación RFID se

integre con otro sistema destinado a realizar reservas de recursos con antelación, de

manera que se gestionan tanto préstamos reservados con anterioridad como en un

momento dado.


35

3.2. Contexto general del sistema

El contexto general del sistema debe contemplar la interacción del sistema con el

usuario, con otros sistemas mecanizados o manuales, o con las posibles bases de datos

existentes. El contexto general correspondiente al Sistema de Control de Accesos a

Edificios se recoge en el siguiente diagrama:

El sistema recibirá la información de entrada a través de los lectores que se encontrarán

conectados en la estación de trabajo del usuario final, en este caso el bedel del

departamento del IIT.

Seguidamente, el sistema determinará la operación a realizar, en función de los

parámetros de entrada, y si se requiere, solicitará al servidor los datos de gestión,

almacenados con anterioridad, que se proporcionarán como información de salida en el

punto de atención. El sistema también interaccionará con el servidor donde residen las

BBDD, cuando tenga que realizar un registro, ya sea de una visita como del estado un

recurso, generando como flujo de salida la correcta finalización de la operación o lo que

se considere más conveniente.


36

3.3. Evaluación y análisis

Ante la descripción del problema que se ha realizado en los apartados anteriores, el

siguiente punto que se ha de abordar es el de evaluar la información recogida y

sintetizarla para obtener el modelo de la situación del sistema que se desea alcanzar.

Para ello, se han de estudiar tres aspectos claves:

3.3.1. Flujo de la información

En este apartado se definen las entradas y salidas del sistema. Como flujo de entrada, el

sistema recibirá los datos correspondientes a las lecturas que se lleven a cabo a través

tanto del lector de tarjetas inteligentes, como del lector RFID. También, el sistema

recogerá información del servidor de base de datos cuando deba mostrar datos

relevantes para continuar con la operación del control de acceso, como por ejemplo

proporcionar los datos de toda la plantilla del IIT, o las descripciones y el estado actual

de cada uno de los recursos.

Como flujo de salida el sistema proporcionará un código de retorno que informará sobre

el resultado de la operación que se haya realizado. Sólo se generará flujo de información

de salida como tal, cuando en Control de Inventario se almacenan cada uno de los

movimientos que se gestionan tras su confirmación, o cuando se desea escribir en el

TAG RFID asociado una breve descripción de algún aspecto que haya que recordar del

recurso en futuros préstamos, por ejemplo un deterioro físico de alguno de sus

componentes, o si en un préstamo no se han llevado un elemento que forma parte del

recurso entregado, por ejemplo un periférico como un ratón

3.3.2. Estructura de la información

Se entiende por estructura al contenido de los flujos de información, con el detalle

suficiente como para comprender la actuación del proceso que transforma un flujo en

otro u otros.


37

Estructura de la Información de Control de Visitas

Los flujos de información que se generan durante un proceso de lectura son los

siguientes:

Nombre: FLUJO-ENTRADA-LECTOR

Identificador: PSCAFD.CV1

* CADENA: String de bits enviados por el lector cuando se introduce una tarjeta

inteligente en el mismo. A partir de dicha cadena de caracteres se determinan el código

de identificación, el nombre y los apellidos del alumno.

Nombre: FLUJO-LECTURA

Identificador: PSCAFD. CV 2

* ID-ALUMNO: Código asignado a cada alumno cuando comienza sus estudios en

la Universidad UPCO.

* NOMBRE: Nombre del alumno identificado.

* APELLIDOS: Apellidos del alumno identificado.


38

Nombre: FLUJO-PERSONAL


* 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


* ID-EMPLEADO: Identificador asignado a cada uno de los empleados del IIT.


39

Nombre: FLUJO-REGISTRO-VISITANTE


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


40

Nombre: FLUJO-RECURSO


* ID-ITEM: Identificador asignado a cada uno de los recursos del departamento

disponibles para ser utilizados por cualquier empleado del mismo.

* CARACTERISTICAS: 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


* ID: Identificador de la reserva.

* ID-ITEM: Identificador del recurso sobre el que se realiza la reserva.


41

Nombre: FLUJO-RESERVA (Cont)


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


42

Nombre: FLUJO-EMPLEADO


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

en el IIT.

* NOMBRE: Nombre del empleado.

* APELLIDOS: Apellidos del empleado.

Nombre: FLUJO-PRESTAMO


* ID-ITEM: Identificador del recurso sobre el que se esta realizando el 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.


43

Nombre: FLUJO-INST


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.


44

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

departamento una persona que no dispone de carnet de alumno, se le asignará un

identificador especial, de forma que tras haber facilitado sus datos personales, se

pueda llevar a cabo el registro de la visita que desea realizar.

• Consultar personal del departamento: Se proporcionan los datos de todas las

personas que forman parte del departamento del IIT de Comillas: nombre,

despacho y teléfono.

• Consultar visitas anteriores: Tras la identificación del visitante, se proporcionan

las últimas diez visitas que han sido registradas y protagonizadas por el mismo.

Esto permite obtener una lista de personal reducida que resulta muy útil ya que

suelen repetirse las visitas de los alumnos a los mismos profesores.

• Registrar visitante: Se almacena en la tabla LOG_VISITAS el identificador del

visitante junto con sus datos personales.

• Registrar visita: Se realiza un registro de la visita en la tabla VISITANTES,

definida dicha visita por el identificador del visitante y del empleado, junto con

la fecha actual.

• Proporcionar ayuda: En tiempo real, la aplicación proporcionará una opción de

ayuda sobre la funcionalidad de la misma.

• Finalizar la aplicación: se suministrarán dos formas de cerrar la aplicación, bien

a través de la opción de Archivo�Salir, o pulsando sobre el icono de cierre de la

ventana de la misma.


45

• Registrar visitas adicional: Opción que se activará cuando, por motivos externos,

no se puede ejecutar la aplicación, de manera que se pueda llevar a cabo el

seguimiento de las visitas que se vayan a realizar durante el tiempo que perdure

el problema.

Los diferentes servicios que definen detalladamente la funcionalidad y finalidad del

Control de Inventario son los siguientes:

• Mostrar el estado actual de los recursos del departamento: Se proporciona para

cada uno de los recursos información sobre su disponibilidad para ser prestado,

o en caso contrario, para ser devuelto, indicando en este caso el usuario del

mismo.

• Esperar el registro de un movimiento: La aplicación deberá permanecer en

espera hasta que se aproxime un TAG al lector cuando se desee gestionar un

movimiento de entrada o de salida del departamento.

• Identificar un recurso: Cuando el lector RFID detecte un TAG le enviará a la

aplicación el identificador del mismo, determinando ésta el recurso al que se está

haciendo referencia.

• Integrar la aplicación con el sistema de Reservas Online para que Control de

Inventario pueda gestionar correctamente, con la información necesaria, aquellos

préstamos que hayan sido reservados con antelación.

• Proporcionar la información de las reservas asociadas a un recurso: Cuando un

recurso sea identificado se mostrará la reserva más próxima al momento actual

del mismo, de forma que si el equipo está libre en ese momento, se podrá

realizar una reserva instantánea teniendo en cuenta la fecha del préstamo de la

siguiente reserva más cercana.


46

• Registrar el préstamo de un recurso con reserva: La aplicación permitirá el

registro de una entrega tras mostrar la reserva asociada al recurso. En ese caso,

el usuario escogerá la opción de “registrar el préstamo” proporcionando toda la

información relativa al mismo, sin posibilidad de cambios, finalizando el

movimiento en el momento en que el usuario lo confirme.

• Registrar el préstamo de un recurso sin reserva: Cuando un recurso esté

disponible para ser prestado en un momento dado, se podrá realizar la entrega

siempre que se respete la fecha del préstamo de la siguiente reserva, como se ha

comentado con anterioridad. Por ello, cuando el recurso sea identificado se

mostrará su reserva más cercana, si existe, en cuyo caso se determinará la fecha

mas tardía de devolución de dicho recurso a través de una ventana de diálogo,

donde el usuario deberá de confirmar además otros campos que definen el

préstamo.

• Registrar la devolución de un recurso: El usuario de un recurso puede devolverlo

en la fecha acordada o antes. En el caso de que el recurso se devuelve con

antelación, se deberán actualizar los datos de la reserva para marcar el recurso

como libre y que puede ser reservado por otro usuario.

• Recoger información adicional sobe el estado del préstamo: Se ofrece la

posibilidad de recoger información acerca de las condiciones en que se entrega

el recurso, por ejemplo sin ratón, sin maletín…Esta información se registrará en

el TAG RFID de forma que cuando se devuelva el recurso se conozcan las

condiciones en que se llevó a cabo la entrega.

• Finalizar la aplicación: La terminación de la aplicación requiere la intervención

del usuario, de manera que se le ofrece la posibilidad de finalizarla cuando desee

o cuando lo considere necesario.


47

3.4. Modelo Físico

3.4.1 Modelo Físico de Control de Visitas

Contexto del subsistema

El sistema Control de Visitas se encuentra conectado con un lector de tarjetas

inteligentes, con el que se comunica inicialmente para realizar la configuración del

lector, y a través del cual recibe la información de la tarjeta leída en forma de una

cadena de caracteres. El usuario interactúa con el sistema arrancando y cerrando la

aplicación, así como confirmando el registro de las visitas. A su vez, el usuario es el

responsable de introducir la tarjeta en el lector.


48

Diagrama de Contexto

El Contexto del sistema se determina mediante un gráfico de presentación, donde

aparece el Sistema de Control de Visitas, el usuario y la entidad externa correspondiente

al lector de tarjetas inteligentes.

A continuación se proporciona una descripción de cada uno de los objetos presentes en

el diagrama anterior (diccionario de datos), de manera que facilite la comprensión del

contexto del sistema.

Diagrama de Contexto: PSCADFD0

Objeto: Entidad Lector LTCX Identificador : PSCADFD0.E1

El lector de tarjetas inteligentes se comunicará con el sistema en dos situaciones

claramente diferenciadas: por un lado para el envío de información de configuración, ya

sea para establecer el terminal como para apagarlo; y el segundo contexto es para la

transmisión de la información leída de las tarjetas


49


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.


Objeto: Orden SHUTDOWN Identificador : PSCAO.1

Orden para apagar el lector, iniciada por el sistema cuando éste recibe la orden de EXIT

generada por la entidad USUARIO.


Objeto: Orden START Identificador : PSCAO.2

Orden para arrancar la aplicación de Control de Visitas. Es generada por la entidad

USUARIO desde su puesto de trabajo.


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.


50

Diagrama Conceptual de Nivel 1: PSCADFD1

Objeto: Orden FIN-LECTURA Identificador : PSCAO.1

Orden generada por el sistema cuando la entidad USUARIO quiere finalizar la

aplicación (recepción de un EXIT).


Objeto: Orden AVISO-LECTOR-NO-

ENCONTRADO

Identificador : PSCAO.2

Orden que se envía al sistema cuando durante la configuración no se detecta o reconoce

ningún lector de tipo LTCX, probablemente motivado por la falta de instalación de los

drivers del mismo.


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.


51

Diagrama Conceptual de Nivel 1

El diagrama conceptual recoge los procesos de primer nivel que realizan la

funcionalidad descrita con anterioridad del Control de Visitas. En este caso, sólo se ha

diseñado un primer nivel debido a que los procesos no requieren explosionarse en otros

de mayor detalle.

La descripción de cada uno de los elementos que constituyen el Diagrama Conceptual

se proporciona a continuación:

Objeto: Proceso 1, Iniciar Servicio TI Identificador: PSCAP.1

Procedimiento destinado a configurar la comunicación con el lector LTCX. Dicha

configuración consiste en determinar un terminal a partir de un slot del mismo, que se

mantendrán durante todo el tiempo de ejecución de la aplicación de control de acceso.


52

Objeto: Proceso 2, Esperar Lectura Identificador: PSCAP.2

Segundo estado de la ejecución del control de acceso, en la que la aplicación se

encuentra en espera activa de procesar una lectura y realizar su correspondiente registro

en la base de datos. En este estado de la ejecución del control de acceso, el usuario

puede proceder a finalizar la aplicación, bien porque lo desea, o porque se produjo un

error durante la lectura

Objeto: Proceso 3, Mostrar Información Identificador: PSCAP.3

Estado del control de acceso en que se proporciona la información sobre la

identificación de la persona que realiza la visita, a quién ha visitado las ultimas veces

que se ha encontrado en el departamento, y todo el personal que constituye la plantilla

del IIT de la UPCO. Por ello, la primera vez que se accede a este estado es cuando se ha

realizado la lectura de la tarjeta, etapa de identificación. El segundo y tercer acceso a

este estado tienen lugar tras proporcionar las visitas que ha realizado la persona

identificada en anteriores ocasiones, y todo el personal del departamento.

Objeto: Proceso 4, Consultar Visitante Identificador: PSCAP.4

Proporciona el personal del departamento que aparece en los registros de las últimas

diez visitas que ha realizado la persona que se está atendiendo, y que se acaba de

identificar a través de su tarjeta de alumno.


53

Objeto: Proceso 5, Consultar Personal Identificador: PSCAP.5

Proporciona información de toda la plantilla del personal del IIT, con el objetivo de que

el usuario, cuando lo necesite, seleccione la persona que se desea visitar.

Objeto: Proceso 6, Obtener Visita Actual Identificador: PSCAP.6

Etapa durante la fase de ejecución en la que se configuran los datos que definen la visita

que se desea registrar. Cuando el usuario confirme los datos proporcionados a través del

interfaz de la aplicación, se procederá a realizar un registro del visitante y de la visita

asociada al mismo.

Objeto: Proceso 7, Apagar Lector Identificador: PSCAP.7

Finalizar la comunicación con el lector LTCX, procediendo a su apagado.

3.4.2. Modelo Físico de Control de Inventario

Contexto del subsistema

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

y conectado al lector RFID. La comunicación entre ambos se caracteriza por no ser

constante, es decir, sólo intercambian información entre sí cuando se desea identificar

un recurso o cuando se escriben las condiciones del préstamo en el TAG RFID.


54

El usuario además de arrancar y cerrar la aplicación, es responsable de iniciar el registro

de los movimientos de recursos que tengan lugar. Dicho inicio se realiza con la

identificación del recurso seguido de asignación de la reserva correspondiente

determinando si se trata de una entrega o de una devolución.

Si se va a efectuar una entrega o devolución, según corresponda, el usuario deberá

indicárselo a aplicación pulsando el botón que se haya habilitado para tal fin, siendo la

propia aplicación quien se encargue de verificar las condiciones del préstamo y de

registrar el movimiento que se ha gestionado.

Diagrama de Contexto

El gráfico de presentación del Sistema Control de Inventario queda definido por el

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


55

Con el objetivo de facilitar la comprensión del contexto del sistema se realiza a

continuación una breve descripción de los objetos que intervienen en el Diagrama de

Contexto anterior, y que forman parte del diccionario de datos del sistema final.


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.


56


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.


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.


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.


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.


57


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.


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


58


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:


59

Objeto: Proceso 1, Mostrar estado actual

de los recursos

Identificador : PSCAP.1

Cada vez que se inicia por primera vez la aplicación, o se finaliza la gestión de un

movimiento, se muestra la disposición actual de los recursos del departamento para ser

prestados. Si un recurso no se encuentra disponible, se indicará a su vez el nombre de la

persona que lo tiene en ese momento.

Objeto: Proceso 2, Esperar Lectura Identificador: PSCAP.2

Estado lógico en el que se encuentra el sistema cuando no gestiona ningún movimiento.

Dicho estado permite atender una nueva petición ya que se encuentra esperando la

lectura del TAG de un nuevo recurso.

Siempre que el sistema cambia a este estado le cede el control de la aplicación al lector

RFID, responsable de detectar una nueva tarjeta, que tras su identificación y lectura se la

transmite al sistema en forma de TRAMA, recuperando de nuevo el control de la

aplicación.

Objeto: Proceso 3, Identificar Recurso Identificador: PSCAP.3

Después que el lector haya realizado la correspondiente lectura del TAG detectado,

envía al sistema el identificador y los datos leídos del mismo. Cuando el sistema recibe

la TRAMA, lo primero que realiza es la identificación del código recibido. Si éste se

corresponde con alguno de los recursos del departamento se procederá a registrar el

movimiento en cuestión, pero si no se corresponde con ninguno el sistema solicitará una

nueva lectura cambiando de nuevo al estado de “Esperar Lectura”.


60

Objeto: Proceso 4, Mostrar reserva

asociada


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.


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.


61

Las descripciones de cada uno de los procesos que constituyen el diagrama anterior y

que completan el diccionario de datos del diseño del sistema, se proporcionan a

continuación:

Objeto: Proceso 1, Confirmar movimiento Identificador : PSCAP.5.1

Estado en el que se encuentra el sistema después de mostrar la información de la reserva

asociada al correspondiente movimiento de un recurso en particular.

En este momento, el sistema se encuentra en espera de que el USUARIO indique si

desea registrar el movimiento o no, en cuyo caso confirmaría que la reserva que se ha

mostrado corresponde con el tipo de movimiento que se está gestionando.


62

Objeto: Proceso 2, Registrar préstamo Identificador: PSCAP.5.2

El movimiento se corresponde con la entrega de un préstamo, de forma que cuando el

USUARIO confirme que desea registrarlo se deberá de mostrar una ventana de diálogo

con los datos necesarios que definen el préstamo.

Objeto: Proceso 3, Registrar préstamo

instantáneo

Identificador : PSCAP.5.3

El registro del préstamo se corresponde con la entrega de un recurso no reservada. Por

ello, la ventana de diálogo deberá de mostrar la fecha de devolución más tardía respecto

de la fecha de realización del próximo préstamo, así como otros datos que permiten

definir la reserva. A su vez, se requiere que el usuario introduzca ciertos campos.

En el momento que el USUARIO confirme los datos, se insertará la reserva asociada al

préstamo y se actualizará toda la información correspondiente al estado de los recursos y

del movimiento que se acaba de gestionar.

Objeto: Proceso 4, Registrar préstamo con

reserva

Identificador : PSCAP.5.4

El registro del préstamo a realizar tiene una reserva asociada. Cuando el USUARIO

confirme el movimiento se mostrará una ventana de diálogo que informa sobre los datos

de la reserva que se está llevando a cabo, sin proporcionar posibilidad a cambios.

Tras la confirmación del USUARIO se registrará el movimiento en la base de datos,

actualizando el estado del recurso prestado.


63

Objeto: Proceso 5, Registrar devolución Identificador: PSCAP.5.5

El movimiento a gestionar se corresponde con la devolución de un recurso. La

aplicación internamente verificará si dicha devolución se realiza en el día acordado o se

corresponde con una fecha más temprana a la registrada, en cuyo caso deberá de

actualizarse la duración de su reserva para permitir el préstamo del recurso a otra

persona a partir del momento en que se recoge la entrega en la base de datos del sistema.

Objeto: Proceso 6, Finalizar movimiento Identificador: PSCAP.5.6

Estado en el que se encuentra el sistema tras la gestión de un recurso. Se espera que el

USUARIO seleccione una nueva lectura, o en caso contrario, finalice la aplicación

saliendo del sistema.

3.5. Modelo Lógico

El objetivo del modelo lógico es identificar las funciones o procesos y datos esenciales,

eliminando o sustituyendo lo considerado como no importante para el funcionamiento

del negocio, así como los aspectos físicos, que aparecen en el modelo físico.

3.5.1. Modelo Lógico de Control de Visitas

En el modelo físico se han definido siete procesos, considerando los aspectos físicos

como por ejemplo el encendido y apagado del lector, así como los errores de introducir

la tarjeta para proceder a la lectura de la misma. También contempla de manera

independiente la obtención de los dos flujos de información sobre el personal del

departamento, ya que por un lado se desea obtener los empleados visitados las últimas

veces, y por otro lado, se proporcionan los datos de todos los empleados del IIT.


64

Como se ha comentado con anterioridad, el diseño del modelo lógico requiere la

selección de los procesos más importantes, desde el punto de vista del funcionamiento

del negocio, y la eliminación de los aspectos físicos. Por ello, el modelo lógico

correspondiente al subsistema de Control de Visitas sólo consta de dos procesos.

El proceso 1, Procesar Lectura, recoge como punto inicial importante para realizar el

control la lectura de una tarjeta, dejando a un lado cómo se realiza la lectura, si es

necesario realizar una configuración de la comunicación, o si se encuentra en espera

activa de lecturas.

El proceso Obtener Información Visita contempla la información que es necesaria

proporcionar al usuario para que pueda determinar los datos correspondientes a la visita

que se va a registrar.

En el modelo físico se desglosó en tres puntos claramente diferenciados, mientras que

en el modelo lógico se divide en dos: la identificación del visitante procedente del

proceso 1, y el resto se proporciona en el segundo proceso ya que se considera como

homogénea, en el sentido de que se requiere de un acceso a base de datos ya que se

encuentra registrada en el servidor, de forma que el tratamiento de la información es el

mismo.

A su vez, Obtener Información Visitas es responsable de recibir la confirmación de la

visita tratada, y de registrarla en la correspondiente base de datos.

El diagrama que representa el Modelo Lógico de Control de Visitas, descrito con

anterioridad, se muestra a continuación:


65

3.5.2. Modelo Lógico de Control de Inventario

El modelo lógico de un sistema no debe representar la forma (el cómo) en que éste

realiza los servicios que se ofrecen al usuario final. Por este motivo, se han definido los

procesos más importantes del Modelo Físico de Control de Inventario que permiten

representar qué hace el sistema, eliminando aquellos procesos que pertenecen más al

ámbito físico.

El diagrama lógico final del Sistema de Control de Inventario consta de 5 procesos que

en conjunto explican el proceso de gestión de un movimiento de un determinado

recurso.

En primer lugar se ha de determinar el estado actual del inventario del departamento con

el objetivo de conocer qué recursos se encuentran en el edificio disponibles para ser

prestados y así poder llevar a cabo un control de los mismos.


66

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

estado de espera, el cual implica la comunicación con el lector para solicitar la lectura

de un TAG RFID. Lógicamente, a pesar de que el lector opere en un nivel inferior al de

la aplicación, también permanece esperando a realizar la lectura de una tarjeta. El

cambio de estado del sistema es motivado por la identificación y lectura de un TAG,

información que enviará el lector RFID al sistema si todo el proceso se ha realizado

correctamente.

En el momento en que el sistema recibe el identificador de la tarjeta, la operatividad es

sistemática: se identifica el recurso, se determina el tipo de movimiento y se obtiene la

reserva asociada al recurso, notificando el resultado de todas ellas al usuario.

El proceso de gestión finaliza cuando el usuario confirma el movimiento, hecho que

determina la actualización del estado del recurso que se ha prestado o devuelto, y el

correspondiente registro del movimiento. Tras ello, el sistema deberá obtener de nuevo

el estado actual del inventario debido a que se ha producido un cambio en el mismo,

repitiéndose de nuevo todo el proceso anterior.


67

3.6. Modelo Conceptual de datos

La información de los flujos de datos, almacenes, registros, y atributos del modelo

lógico permiten identificar las entidades de datos del sistema. El modelo conceptual de

datos determina cuáles son las familias o entidades de datos del negocio, sus relaciones

y atributos más importantes.

El modelo conceptual de datos debe ser independiente del hardware y del software

utilizado para el manejo de los datos, y de las aplicaciones actuales o futuras que

utilicen dichos datos. El modelo conceptual de datos puede tener un mayor o menos

grado de precisión, dependiendo de la etapa de estudio en que se encuentre el sistema a

representar.

3.6.1. Modelo Conceptual de datos de Control de Visitas

Modelo entidad-relación

En el subsistema Control de Visitas se definen dos entidades sobre las que se almacena

información relevante, y a las que se puede identificar de manera unívoca: Visitante y

Empleado, cuya asociación da lugar a la relación Visita. Por lo que el modelo de

entidad-relación correspondiente a Control de Visitas es el siguiente:

Un visitante puede realizar una o más visitas a la misma persona del departamento, o a

otra diferente, dependiendo de los motivos por los que el visitante desea realizar dicha

visita. Ambas entidades se clasifican como físicas, ya que son entidades que se

corresponden con entes externos en la realidad.


68

ENTIDAD: VISITANTE IDENTIFICADOR: PSCAMCD.CVE1

Descripción:

Se identifica a la persona que desea reunirse con uno de los empleados que pertenecen al

departamento del IIT. Dicha persona puede pertenecer a la UPCO, o puede tratarse de

alguien ajeno al contexto de dicha universidad. En ambos casos, se realiza una

identificación del mismo para definir la visita que se va a realizar, y así poder

registrarla.

Composición:

ENTIDAD: EMPLEADO IDENTIFICADOR: PSCAMCD.CVE2

Descripción:

Se corresponde con cada una de las personas que trabajan en el IIT, y que constituyen la

plantilla de dicho departamento. Cada uno de los empleados pueden recibir visitas de

diferentes personas a lo largo del día.

Composición:


69

RELACIÓN: VISITA IDENTIFICADOR: PSCAMCDCV.R1

Descripción:

Una visita queda representada a partir de las entidades de Visitante y Empleado, los

cuales son los objetos físicos que llevan a cabo el encuentro. Para poder registrar una

visita, y que se caracterice de tener un significado coherente y entendible, debe estar

definida a partir de los identificadores de las dos personas que la constituyen, y de la

fecha actual en que se va a realizar.

Composición:

Diseño de Tablas

Con el objetivo de garantizar que los datos están organizados con la menor redundancia

posible y minimizando la probabilidad de anomalías en la actualización de los datos, se

han definido tres tablas:

• USUARIOS: Recoge los datos de cada uno de los empleados del departamento.

• VISITANTES: Alberga la información que define a cada persona que realiza

una visita.

• LOG_VISITAS: Almacena todas las visitas que se registran en el departamento.


70

3.6.2. Modelo Conceptual de datos de Control de Inventario

Modelo entidad-relación

El modelo entidad-relación correspondiente al Sistema Control de Inventario está

formado por dos entidades: recurso y empleado, ya que responde a la situación real de

que un empleado es el que utiliza un determinado recurso del departamento. A su vez,

se representan dos relaciones como resultado de la interacción directa entre las dos

entidades.

La relación “Reserva” surge de la necesidad que tiene un empleado de reservar un

recurso para un determinado día, una serie de horas o de días. Esta relación permite

controlar los préstamos que se han de realizar a lo largo de cada jornada laboral.

Además, es la responsable de contextualizar las condiciones del préstamo: duración,

motivo…

La segunda relación, “Préstamo”, representa básicamente el movimiento: un empleado

recibe o devuelve un determinado recurso. No existe ninguna relación entre “Reserva” y

“Préstamo” ya que un recurso se puede prestar si estar reservado.


71

A continuación se realiza una descripción del conjunto de objetos que constituyen el

modelo conceptual de datos, y que completan el diccionario de datos del diseño del

sistema.

ENTIDAD: EMPLEADO IDENTIFICADOR: PSCAMCDCI.E1

Descripción:

Se corresponde con cada una de las personas que trabajan en el IIT, y que constituyen la

plantilla de dicho departamento. Cada uno de los empleados pueden recibir visitas de

diferentes personas a lo largo del día.

Composición:

ENTIDAD: RECURSO IDENTIFICADOR: PSCAMCDCI.E2

Descripción:

Representa a cada uno de lo bienes materiales que constituyen el inventario que el

departamento del IIT deja a disposición de sus empleados.

Composición:


72

RELACIÓN: RESERVA IDENTIFICADOR: PSCAMCDCI.R1

Descripción:

Una reserva se define a partir de la necesidad que tiene un empleado de utilizar un

determinado recurso. Por este motivo, le reserva permite conocer qué movimientos se

van a realizar a lo largo de cada día, además de gestionar adecuadamente cada préstamo

o devolución, garantizando la coherencia con la realidad.

Composición:

RELACIÓN: PRÉSTAMO IDENTIFICADOR: PSCAMCDCI.R2

Descripción:

Un préstamo representa el tipo de movimiento que se gestiona: bien la entrega de un

recurso, o una devolución. Esta relación permitirá llevar a cabo un control de los

movimientos que realmente se realicen cada día.

Composición:


73

Diseño de Tablas

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

operaciones necesarias para llevar a cabo la gestión de inventario, está constituida por

tres tablas:

• ITEMS: Recoge todos los recursos que forman el inventario del departamento.

• RESERVAS: Almacena las reservas de los recursos que se han prestado, o se

van a entregar en un futuro.

• Préstamos: Registra todos los movimientos que se llevan a cabo sobre un

determinado recurso.


74

44.. EEssttuuddiioo ddee llaa AArr qquuii tteeccttuurr aa


75

4.1. Especificación de la tecnología hardware

Los principales requisitos hardware del Sistema de Control de Accesos son dos lectores

de tarjetas de reconocimiento: uno de tarjetas inteligentes y otro de radiofrecuencia. En

este punto se realiza un estudio de cada una de las tecnologías, así como de las

características de cada uno de los lectores.

4.1.1. Tarjetas Inteligentes

4.1.1.1. ISO 7816

La Organización Internacional de estándares (ISO) dictamina en su estándar número

7816 toda la información de regulación y control de normas acerca de las Tarjetas

Inteligentes de contacto.

El estándar ISO7816 está dividido en cuatro apartados diferentes:

1. ISO7816-1: Características físicas del circuito integrado.

En este apartado se estudian las características físicas de las tarjetas inteligentes de

contacto. A continuación, se describen las más importantes:

• Luz Ultra Violeta: Cualquier protección contra cualquier nivel de rayos UV, será

responsabilidad del fabricante de la tarjeta.

• Rayos X: La exposición de cualquiera de los dos lados de la tarjeta a una dosis

de 0.1 Gy relativo a una radiación de energía media de rayos X de 70 a 140 KV

(dosis acumulativa por año) no deberá causar mal funcionamiento de la tarjeta.


76

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

contactos y la superficie de la tarjeta adyacente deberá ser menor de 0.1mm.

• Fuerza Mecánica: La tarjeta deberá resistir daños sobre su superficie, por presión

causada por una bola de acero de 1.5mm de diámetro en la cuál se aplica una

fuerza de 1.5 N.

• Resistencia eléctrica: Toda la resistencia eléctrica medida entre dos puntos

cualquiera de los pines, no deberá sobrepasar los 0.5 Ohm, con cualquier valor

común de 50 uA a 300 mA.

• Campo magnético: El chip de la tarjeta no deberá ser dañada por campos de

estática magnética de 79500 A.tr/m.

• Electricidad estática: El chip de la tarjeta no deberá ser dañado por descargas

eléctricas de 1500 V y de 100 pF y tendrá 1500 Ohms.

También se contemplan aspectos como la inflexión máxima de la tarjeta o los distintos

tamaños permitidos:

• Inflexión máxima de la tarjeta:

Largo de la tarjeta

Deformación (f): 2 cm

Periodicidad: 30 Inflexiones por minuto

Ancho de la tarjeta

Deformación (f): 1 cm.

Periodicidad: 30 Inflexiones por minuto


77

• Tamaños:

2. ISO7816-2 define las dimensiones y la posición de los contactos.

Esta parte define el número, función y posición de los contactos eléctricos. El circuito

integrado (ICC) tiene 8 contactos eléctricos.

A continuación se adjunta una tabla que contiene la definición de los 8 contactos acorde

con la ISO 7816-2:


78

3. ISO7816-3 define las señales eléctricas y los protocolos de transmisión.

Como protocolos de transmisión se contemplan hasta 16, pero sólo se utilizan dos:

• T=0: Protocolo asíncrono orientado a carácter. Es el más usado (por ejemplo

GSM), aunque se requieren dos transacciones para recibir datos.

• T=1: Protocolo asíncrono orientado a bloque de datos. En este caso solo se

requiere de una transacción para recibir datos.

4. ISO7816-4 define comandos de intercambio industriales.

En este documento de la ISO se definen:

• Sistema de ficheros y estructura de datos.

• Arquitectura de seguridad.

• Lista de instrucciones específicas y/o adicionales de la ISO.

• Lenguaje de comunicación con la tarjeta JavaCard, PCSC10 ...


79

4.1.1.2. Tipos de Tarjetas Inteligentes

Existen diversos tipos de Tarjetas Inteligentes, todas ellas pueden clasificarse bajo dos

criterios. El primero es el tipo de circuito integrado que lleva en su interior y la forma de

procesar la información. El segundo es el tipo de contacto que tiene la tarjeta para

entrada y salida.

1. Clasificación por el tipo de circuito integrado

En lo referente al tipo de circuito integrado, las Tarjetas Inteligentes se clasifican en tres

tipos, dependiendo de sus capacidades de procesamiento y de la lógica con que

modifican internamente los datos que pueden almacenar, aunque se podrían dividir en

sólo dos grupos: tarjetas de memoria, que son el modelo más simple y más económico

de implementar y, tarjetas que contienen en su interior una Unidad Central de

Procesamiento o CPU.

Tarjetas de memoria

Este tipo de tarjetas son las más comunes de hallar en aplicaciones comerciales como

tarjetas de prepago. Solo pueden almacenar datos y no cuentan con la capacidad de

modificarlos, por ello son el modelo más simple y más económico de implementar.

Un ejemplo de uso de estas tarjetas son las tarjetas de cabinas telefónicas, estas vienen

con un importe grabado de fábrica y al realizar la llamada, la cabina va disminuyendo el

importe por cada minuto de uso.

Tarjetas de memoria con lógica de seguridad

Son similares a las tarjetas de memoria pero con la capacidad de controlar el acceso a

los datos. Emplean memorias EEPROM para implementar esta funcionalidad.


80

Tarjetas con procesador y memoria

Este tipo de tarjetas tienen un chip microprocesador que puede contener un microcódigo

que define una estructura de comando, una estructura de archivos y una estructura de

seguridad. Estas tarjetas pueden añadir, borrar y, de alguna manera, manipular

información en su memoria. Pueden ser vistas como un computador en miniatura con un

puerto de entrada/salida, sistema operativo y disco duro.

2. Clasificación por el tipo de contacto

Existen fundamentalmente dos tipos de tarjetas en función de cómo se realice la

comunicación entre el lector y la tarjeta, tarjetas de contacto y tarjetas sin contacto,

aunque también se pueden encontrar tarjetas híbridas que pueden comunicarse de las

dos formas, por contacto y sin él.

Tarjetas con contacto

Estas tarjetas necesitan ser insertadas en un lector inteligente para que por medio de

contactos eléctricos pueda ser leída. En la primera imagen puede observarse los 8

contactos con los que está formada una Tarjeta Inteligente definidos en la ISO 7816-2.


81

Tarjetas sin contacto

Son similares a las de contacto con respecto a lo que pueden hacer y a sus funciones

pero utilizan diferentes protocolos de transmisión en la capa lógica y física. La

comunicación entre el lector y la tarjeta se realiza a través de señales electromagnéticas

sin necesidad de ningún tipo de contacto.

Una de las ventajas que presenta este tipo de tarjetas es que no existen contactos

externos, por lo que es más resistente a los elementos externos como la suciedad, y se

con el uso.

Una Tarjeta Inteligente sin contacto requiere solamente aproximarse al lector. Ambos,

el lector y la tarjeta tienen una antena y la comunicación se establece por ondas de

radio. Muchas tarjetas sin contacto también obtienen la energía para su microchip

interno a través del campo electromagnético creado por el lector.

Este tipo de tarjetas se estudiarán con más detalla en el punto correspondiente a la

Tecnología RFID.

Tarjetas híbridas

Como una categoría derivada están las tarjetas que envuelven las dos categorías que

emplean contacto y las que no. Una tarjeta híbrida tiene dos microchips, cada uno con

su respectiva interfaz para contacto y transmisión por radio.

Los dos chips no están conectados, pero para muchas aplicaciones, este híbrido suple las

necesidades de los usuarios y los distribuidores. De esta manera está emergiendo este

tipo de tarjeta que une en su interior los dos tipos de interfaces en los contactos de

lectores, aumentando así las posibles funcionalidades que pueda tener una sola tarjeta.


82

4.1.1.3. Sistema de Ficheros

El sistema de ficheros de las Tarjetas Inteligentes está definido, como ya se ha indicado

en un apartado anterior, en la ISO 7816-4. Todas las tarjetas deben soportar los

siguientes tipos de ficheros:

• Fichero Maestro (MF): Este fichero representa la raíz de toda la estructura

interna de ficheros (EF) contenidos en la memoria de la tarjeta, así como

contener ficheros dedicados (DF). Solo puede haber un fichero maestro por

tarjeta y su ruta siempre debe ser la misma según la normativa ISO, la

“0x3F00”.

• Fichero Dedicado (DF): Estos ficheros podríamos considerarlos como

directorios similares a una estructura tipo UNIX, por lo que puede contener

ficheros elementales (EF), así como otros ficheros dedicados. Por lo general se

encuentra un fichero dedicado por cada aplicación diferente que se encuentre en

la tarjeta.

• Fichero Elemental (EF): En estos ficheros se almacenan los datos. Una de las

limitaciones mas molestas es que su tamaño debe ser fijado cuando este es

creado, por lo que un estudio previo de la estructura de ficheros es esencial.

4.1.1.4. Métodos de Acceso a la Tarjeta Inteligente

Las librerías de OpenCard permiten la comunicación, por medio de un lector, entre una

Tarjeta Inteligente y una aplicación Java. Estas librerías nos ofrecen dos métodos para

acceder a la tarjeta, uno de ellos nos permite interactuar con la tarjeta en un bajo nivel

por medio de paquetes de comunicaciones llamados Application Protocol Data Units ó

Unidades de datos según el protocolo de la aplicación (APDU), y el otro método es más

abstracto ya que se realiza por medio de unas clases de Java.


83

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

el lector a partir de la utilización de los métodos que las constituyen proporcionándole

los parámetros necesarios para obtener la información de la tarjeta leída. Para poder

utilizar este forma de comunicación hay que asegurarse de que la Tarjeta Inteligente que

se va a utilizar soporta este acceso. Para llevar a la práctica el Control de Visitas se

utilizará el primer método, debido a que la tarjeta de Comillas no soporta el segundo

método de acceso.

Application Protocol Data Units

Estos paquetes tienen una estructura claramente definida y se dividen en dos tipos como

se puede observar en la siguiente tabla:

El campo CLA presente en los paquetes de solicitud, se corresponde con un byte que se

utiliza para indicar la clase de instrucción, por ejemplo si esta es conforme a la ISO

7816 ó es una instrucción en propiedad. También sirve para indicar si se está utilizando

privacidad a la hora de enviar el mensaje.


84

El valor correspondiente a INS, de un byte indica el comando a emplear:

Los bytes P1 y P2 indican parámetros específicos del comando, y su presencia en el

comando es obligatoria.

El campo LC indica la longitud del comando, del tamaño de un byte. También puede

espesar en bytes la longitud del campo de datos opcional.

La referencia de Datos Opcionales se utilizaría para recoger el texto que se desea

insertar en la tarjeta cuando el comando a ejecutar es el de escritura.

El último campo que aparecen en las solicitudes es el de LE que indica en bytes la

cantidad de datos esperados a recibir en el APDU de respuesta. Si no se sabe la cantidad

de datos o simplemente queremos obtener todo lo posible, se indicará con un “cero”.

En las APDU de respuesta aparecen siempre dos campos, SW1 y SW2, que recogen la

información de estado, y adicionalmente un campo opcional.

Tanto en los APDU de comando como en las de respuesta, los parámetros que se envíen

siempre se encontrarán expresados en cantidades basadas en el sistema hexadecimal.


85

4.1.1.5. Lector de tarjetas inteligentes: LTCX

Aspectos técnicos y funcionamiento

Para llevar a cabo el Control de Visitas es necesario un lector de tarjetas inteligentes,

que permita identificar a cada una de las personas que se acercan al centro. Además

debe ser compatible con las tarjetas de alumno que reparte la universidad.

El lector LTCX USB se conecta al ordenador mediante puerto USB y

está preparado para cumplir con el estándar USB CCID, de manera

que el lector no requiere de software añadido (drivers) en sistemas

operativos Linux, Mac OS y Windows, que ya contemplan este estándar en sus

distribuciones.

Otra característica relevante es que se garantiza la compatibilidad y funcionalidad futura

del lector, ya que su tecnología permitirá actualizaciones de forma remota. Es

importante señalar que esta actualización del lector se ha desarrollado teniendo

especialmente en cuenta el futuro uso del DNI electrónico, optimizándolo para ello.

También se encuentra disponible en versión serie (RS232).

Las características técnicas del lector son las siguientes:

• Dispositivo lector y grabador de tarjeta chip conectado al ordenador.

• Instalación en modo Plug and Play para el sistema operativo Windows.

• Diseño de reducidas dimensiones y de poco peso, que facilita su portabilidad y

ubicación.

• Base plana para su posible sujeción a otros dispositivos externos, como por

ejemplo el teclado, el ordenador, etc.


86

• Carcasa de PVC ligero y resistente a golpes.

• Diseñado especialmente para su utilización en entornos de certificación con

firma digital.

• Provisto de una CPU CMOS de 8 bits.

• Consta de dos LEDS señalizadotes: uno verde y otro rojo.

• Alimentación 5V DC del propio ordenador.

• Soporta velocidades de comunicación entre 9600bps y 115200bps

Tarjetas soportadas

Soporta las tarjetas más utilizadas actualmente en el mercado:

• Tarjetas asíncronas protocolo T=0 (GSM, VisaCash, Euro6000, Tarjeta

Criptográfica, etc.)

• Tarjetas asíncronas protocolo T=1 (German Geldkarte)

• Tarjetas de memoria del tipo SLE4442 (referencia C3P2K)

• Cualquier otro tipo de tarjeta bajo demanda.

4.1.2. Tecnología RFID

Para realizar un seguimiento de los recursos prestables que proporciona el departamento

del IIT de Comillas a todos sus empleados, se ha elegido la tecnología RFID.


87

Un sistema RFID consiste en un tag RFID incorporado en cada objeto que se desea

controlar, por ejemplo un ordenador portátil, y en un aparato lector fijo o portátil que lee

dichos TAGS. Estos componentes utilizan ondas de radio frecuencia para intercambiar

información, lecturas o escrituras. Una vez leído el TAG, los datos puede transmitirse

por las redes estándares a las base de datos, o pueden requerirse para notificar a un

controlador programable para que ejecute alguna acción, como por ejemplo registrar la

entrada o salida de un recurso del edificio donde se encuentra instalado el sistema.

Básicamente un SISTEMA RFID los constituyen los siguientes elementos:

• Uno o más Tags (transponder) que incluye un chip semiconductor y una antena.

• Uno o más dispositivos de Lectura/escritura (interrogadores o lectores).

• Dos a más antenas, una en el tag y otra en el dispositivo de Lectura/Escritura

• Un software de Aplicación y una estación de trabajo (Host).

Para poder llevar a cabo la transmisión de datos entre la tarjeta y el lector RFID se

deben encontrar próximos y trabajar en el mismo rango de frecuencia.


88

4.1.2.1. Funcionamiento

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

responsable de leer y escribir datos en los dispositivos, y un transmisor que responde al

interrogador.

Existen dos tipos de TAGs: los TAGs activos que incorporan una batería para su

alimentación (por ejemplo el control de autopistas), y los pasivos, que se alimentan por

el campo magnético que induce el propio lector.

El proceso de lectura de TAGs pasivos es el siguiente:

1. El interrogador genera un campo de radiofrecuencia, normalmente

conmutando una bobina a alta frecuencia. Las frecuencias usuales van desde 125 KHz

hasta la banda ISM de 2.4GHz, incluso más.

2. El campo de radiofrecuencia genera una corriente eléctrica sobre la bobina

de recepción del dispositivo. Esta señal es rectificada y de esta manera se alimenta el

circuito.

3. Cuando la alimentación llega a ser suficiente el circuito transmite sus datos.


89

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

perturbación del propio nivel de la señal.

La señal recibida por el interrogador desde la tarjeta está a un nivel de -60 db por debajo

de la portadora de transmisión. El rango de lectura para la mayoría de los casos está

entre los 30 y 60 centímetros de distancia entre interrogador y tarjeta.

Las variables críticas en un sistema RFID son las siguientes: el rango de frecuencia de

la comunicación, el tamaño de la información contenida en el tarjeta, la velocidad a la

que se establece la comunicación con el TAG, la forma física del TAG, la capacidad del

sistema para comunicarse “simultáneamente” con múltiples TAGS, y la robustez de la

comunicación respecto a las posibles interferencias existentes entre el lector y la tarjeta.

Los factores a tener en cuenta para implantar la tecnología RFID consideran los niveles

legales y regulados de emisión permitida en el país de uso, si se incluye o no una batería

en el propio TAG para mejorar su comunicación con el lector, y la frecuencia de

portadora de RF utilizada para transportar la información entre el TAG y el lector.

4.1.2.2. Protocolos y opciones

Normalmente el sistema de modulación utilizado es modulación de amplitud (AM) con

codificación tipo Manchester NRZ. Para conseguir mayor alcance y más inmunidad al

ruido eléctrico, se utilizan sistemas más sofisticados: en algunos casos se divide la

frecuencia del reloj de recepción.

La mayor parte de los TAGS tienen una memoria EEPROM donde se almacenan datos.

En algunos casos llevan datos grabados de fábrica y en otros también hay datos que

puede grabar el usuario. Cada vez es más habitual, implantar sistemas que utilizan

encriptación de clave pública para conseguir mayor seguridad ante posibles escuchas

maliciosas.


90

Por otro lado podemos encontrar sistemas anticolisión que permiten leer varias tarjetas

al mismo tiempo. En caso de que varias tarjetas estén en el rango de alcance del

interrogador y empiecen a transmitir al mismo tiempo, se produce una colisión.

El interrogador detecta la colisión y manda parar la transmisión de las tarjetas durante

un tiempo. Después irán respondiendo cada una por separado después de un tiempo de

espera aleatorio.

4.1.2.3. Etiquetas RFID: TAGS

Las etiquetas RFID se clasifican en tres tipos, desde el punto de vista de si poseen una

fuente de alimentación o no:

Pasivas: Caracterizadas por no tener fuente de alimentación propia. La mínima corriente

eléctrica, inducida en la antena por la señal de escaneo de radiofrecuencia, proporciona

suficiente energía al circuito integrado CMOS de la etiqueta para poder transmitir una

respuesta. Debido a las limitaciones de energía, la respuesta de una etiqueta pasiva

RFID es necesariamente breve, normalmente apenas un número de identificación. La

falta de una fuente de alimentación propia hace que el dispositivo pueda ser bastante

pequeño. Las etiquetas pasivas, en la práctica tienen distancias de lectura que varían

entre unos 10 milímetros hasta cerca de 6 metros dependiendo del tamaño de la antena

del tag, y de la potencia y frecuencia en la que opera el lector. Por ejemplo etiquetas de

productos de consumo.

Semi-pasivas: Similares a las pasivas, salvo que incorporan además una pequeña

batería. Esta batería permite al circuito integrado de la etiqueta estar constantemente

alimentado. Además, elimina la necesidad de diseñar una antena para recoger potencia

de una señal entrante. Por ello, las antenas pueden ser optimizadas para la señal de

backscattering. Las etiquetas RFID semi-pasivas responden más rápidamente dado que

su razón de lectura es mayor que las con las etiquetas pasivas.


91

Activas: Tienen una fuente de energía, lo que le permite alcanzar rangos mayores,

albergar memorias más grandes que las etiquetas pasivas, e incrementar la capacidad de

poder almacenar información adicional enviada por el transmisor-receptor. Muchas

etiquetas activas tienen rangos prácticos de diez metros, y una duración de batería de

hasta varios años. Por ejemplo los TAGs de las autopistas.

Por otro lado, las etiquetas RFID también se clasifican según su rango de frecuencia:

• Las etiquetas de frecuencia baja: entre 125 ó 134,2 kilohertz.

• las etiquetas de alta frecuencia: 13,56 megahertz.

• las etiquetas UHF o frecuencia ultraelevada: 868 a 956 megahertz. Estas

etiquetas no pueden ser utilizadas de manera global porque no existe una

regulación estándar para su utilización.

• Las etiquetas de microondas (2,45 gigahertz). Las etiquetas de microondas

tampoco pueden ser utilizadas de forma global porque no existen regulaciones

globales para su uso.

Las etiquetas pueden ser de lectura solamente, lectura y escritura, o combinaciones de

ambas, donde algunos datos son permanentes, como por ejemplo el número de serie de

la tarjeta, y por otro lado se cuenta con una memoria adicional, que está disponible para

otros datos que pueden ser añadidos o actualizados en otras ocasiones.

Lectura de las Etiquetas

Los lectores de RFID o “interrogadores”, utilizan ondas de radio para leer la

información almacenada en la etiqueta. El lector puede ordenar a la etiqueta transmitir

la información que tiene almacenada, o bien la etiqueta puede transmitir la información

que contiene de manera periódica.


92

Los lectores pueden ser portátiles o fijos, aunque también pueden estar integrados en

otros equipos, como por ejemplo en terminales handheld. Con el objetivo de mantener

cierta privacidad, la información que fluye entre la etiqueta y el lector puede estar

encriptada.

El lector de RFID, a su vez transmite los datos obtenidos desde la etiqueta a un

ordenador, donde se ejecuta la aplicación que utilizará los datos del tag identificado,

para llevar a cabo las funciones del sistema implantado dicha aplicación recibe el

nombre de Object Name Service (ONS)

4.1.2.4. Estándar Mifare

Los TAGS RFID que se utilizarán en el Control de Inventario son tarjetas inteligentes

Mifare, las cuales contienen en su interior un chip Mifare desarrollado por Philips, de

manera que tienen una estructura específica de almacenamiento.

Una tarjeta que cumple con el estándar MIFARE está conformada por 16 sectores,

donde cada sector posee 4 bloques de 16 bytes.

El bloque cero del sector cero es de sólo lectura, donde se almacena la información del

número serial de la tarjeta o Card ID, datos del fabricante e información de control. Los

bloques finales de cada sector (3, 7, 11,..,63) almacenan los datos de configuración de

cada sector.


93

Estos datos de configuración incluyen las claves de acceso A y B como también las

condiciones de acceso al sector. Este bloque recibe el nombre de Sector Trailer.

A continuación se presenta un esquema de la distribución de la memoria de las tarjetas

inteligentes que cumplen con el estándar MIFARE:

4.1.3. Plataforma donde reside el sistema

El Sistema Control de Accesos a Edificios residirá en un ordenador ubicado en la

entrada del edificio del departamento del IIT, lugar donde el usuario de las aplicaciones

podrá llevar a cabo los controles correspondientes para cada una de las aplicaciones que

constituyen el sistema. Consistirá en una plataforma PC, a la cual se conectarán el lector

de tarjetas inteligentes, y el lector RFID, a través de dos puertos USB.

4.2. Especificación de la tecnología software y de comunicaciones

El software necesario para que las aplicaciones se puedan ejecutar en la máquina del

usuario final es el siguiente:

• Los drivers de cada uno de los lectores, que se encontrarán en una ubicación

específica en dicho ordenador.

• La máquina virtual de Java, JVM, elemento necesario para que se pueda llevar

a la práctica cualquier programa Java.


94

Las comunicaciones necesarias para implantar el Sistema Control de Accesos son

básicamente las de acceso al Servidor de BBDD que se encuentra localizado en el


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.


95

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

identificación, y son responsables de retransmitir la información leída en cada

lectura al sistema, para que éste último la procese.

• Middleware: Nivel intermedio destinado a traducir la información que recibe de

los dispositivos, y a retransmitir la conversión de dicha información a la

aplicación de nivel superior en el protocolo correspondiente para poder llevar a

cabo el procesado de la misma. En el Control de Inventario el fichero .C es el

que desempeña el perfil de estado intermedio, ya que por un lado se comunica

con el lector RFID, y por otro con la aplicación Java, manteniendo de esta forma

la independencia entre los niveles. Sin embargo, en el Control de Visitas no hay

un middleware tan diferenciado debido a que la aplicación sí que tiene medios

(el API) para comunicarse con el lector de tarjetas inteligentes directamente.

• Sistema: Representa las dos aplicaciones de controles de acceso que reciben,

procesan y generan flujo de datos, registrándolos, si procede, en el servidor de

BBDD.

• BBDD: Último nivel de la arquitectura, que se corresponde con el repositorio de

datos del sistema.

4.4. Evaluación Económica

La viabilidad económica considera tanto la inversión en el proyecto, como el gasto que

supone. Un estudio detallado del factor económico se realiza en base al llamado

Análisis de Coste/Beneficio. En él se recogen los costes del proyecto y se comparan con

los beneficios que proporcionará el sistema. Dichos beneficios pueden ser tangibles,

aquellos que se valoran directamente y por tanto se pueden cuantificar; e intangibles,

caracterizados porque no se pueden valorar de forma precisa y son el resultado de

juicios objetivos.


96

Con los costes y beneficios cuantificados se define la rentabilidad del proyecto mediante

consideraciones de amortización: tiempo requerido para recuperar el dinero invertido en

el proyecto. Sin embargo, debido a las características particulares del presente proyecto

como proyecto fin de carrera, no corresponde la realización de este aspecto al no existir

inversión alguna. Aun así, se proporcionará el estudio de amortización que le

correspondería como proyecto real.

Todos estos cálculos requieren un conocimiento sobre el valor actual del dinero, su

tendencia en el futuro, y otros aspectos monetarios que influyen en un análisis de este

tipo. Por este motivo, el Análisis de Coste/Beneficio resulta laborioso de realizar debido

a los criterios variables que se han de aplicar, por las características del sistema que se

está diseñando, el tamaño y complejidad del proyecto, y la recuperación esperada de la

inversión (ROI). Sin embargo, desde el punto de vista del estudio de diferentes

alternativas, para determinar qué solución supone más coste para el proyecto, es

suficiente con tener en cuenta sólo los beneficios tangibles. Dichos beneficios son:

1. Costes de implantación.

• Costes de desarrollo: Incluye al personal necesario para el desarrollo del nuevo

sistema. Se requiere de analistas, consultores, programadores y desarrolladores,

que en este caso, todos ellos son responsabilidad del alumno que está realizando

el proyecto fin de carrera.

• Costes de puesta en marcha: supone el paso a producción, una vez desarrollado

el sistema. Particularizando en este proyecto, no se cuenta con este coste si

consideramos como métrica los euros, pero si el estudio se realiza en

horas/hombre, entonces sí supone un gasto, ya que requiere en primer lugar las

reuniones necesarias con el director. En segundo lugar, la estancia en el

departamento del alumno para instalar tanto los lectores como el sistema en el

ordenador del usuario final.


97

Tras la instalación, se llevan a cabo las pruebas pertinentes para confirmar y

garantizar el correcto funcionamiento de las aplicaciones.

• Costes de formación: Enseñar a todos los usuarios finales del sistema a utilizar

el nuevo sistema. En el proyecto que se esta desarrollando no será necesario que

el usuario final asista a cursos de formación para la utilización de las

herramientas finales: se le enseñará personalmente la metodología de cómo

manejar el sistema.

2. Costes de adquisición de tecnología.

• Coste del hardware: Coste del equipo para el nuevo sistema, considerando los

costes de instalación y mobiliario. Por ello, en este coste se debe tener en cuenta

la adquisición de los lectores y de las tarjetas RFID.

• Coste del software: Licencias de productos ya desarrollados y comerciales,

necesarios para el desarrollo del proyecto como hojas de cálculo, bases de datos,

sistemas operativos, cambios de versión de herramientas…En el proyecto se han

utilizado herramientas, como por ejemplo los compiladores, que no han supuesto

ser un coste para llevar a cabo el desarrollo correspondiente. Como se ha

comentado con anterioridad, los drivers se catalogan como software, y como tal,

se debe considerar el gasto correspondiente de los mismos. Sin embargo, dicho

gasto es nulo, ya que los lectores vienen acompañados por sus correspondientes

drivers.

• Coste de las comunicaciones: Instalación de redes locales, unidades de control

de transmisión o equipos de comunicación a adquirir. Como se ha comentado en

el apartado anterior, el Sistema Control de Accesos no requiere de una red de

comunicaciones para efectuar los controles de acceso: sólo necesita comunicarse

con el servidor de base de datos para gestionar correctamente los flujos de datos

de entrada y de salida que se generarán en cada uno de los controles


98

3. Costes operacionales.

Este apartado recoge los costes del centro de proceso de datos y los costes de

mantenimiento y mejora. Como coste del centro de proceso de datos son los costes fijos

de explotación del nuevo sistema, considerando tanto a las personas como los recursos

materiales.

Por ello, los costes operacionales importantes que influyen en el nuevo sistema son

poco relevantes, ya que por coste fijo podemos considerar la energía que requiere el

funcionamiento del sistema, y el posible mantenimiento que se tenga que realizar en un

futuro, gasto que se considerará en el momento que se tenga que llevar a cabo alguna

actividad que permita mejorar o resolver un determinado problema que impide

proporcionar el correcto servicio del sistema.

La Matriz de Evaluación de Costes recoge, por Grupos o por Factores, cada uno de los

costes estimables o cuantificables que se han descrito con anterioridad. En esta matriz se

anotan los costes reales o esperados de cada parámetro, obteniéndose como suma de

cada uno de ellos, el valor del coste total de la solución tecnológica que se ha elegido.

Cuando no pueden barajarse datos numéricos más o menos fiables, no cabe la

posibilidad de establecer la viabilidad económica del proyecto, pero sí se puede realizar

una estimación aproximada de lo que supone la alternativa, facilitando la posibilidad de

compararla con el resto de soluciones en el caso de que se haya estudiado más de una.

En muchas ocasiones, en lugar de valorar numéricamente cada uno de los factores, se

les asigna un valor simbólico: ++ para indicar un coste alto, + un coste aceptable, - un

coste bajo, y – un coste poco apreciable. El resultado mostrará un conjunto de signos +

y – por cada una de las soluciones, permitiendo compararlas de manera individual.

La Matriz de Evaluación de Costes correspondiente al proyecto que se está diseñando es

la siguiente :


99

Alternativa € (euros)

Costes de Implantación

Costes de Desarrollo 38010

Costes de puesta en marcha 1000

Costes de Formación 20

Costes de Tecnología

Costes del Hardware 550

Costes del Software 0

Costes de Comunicaciones 0

Costes Operacionales

Costes del C.P.D 0

Costes de Mantenimiento y

mejora 0

Costes Totales 39580

4.5. Elaboración del Plan de Proyecto

Definida ya la tecnología hardware, software y de comunicaciones que se ha elegido

utilizar, se procede a realizar la planificación general del resto de etapas: Diseño

Externo, Diseño Interno, Programación, Pruebas e Implantación.

Con la información y conocimiento que se tiene del proyecto en este momento, resulta

más segura y fiable una planificación detallada de cada una de las etapas que quedan

por realizar. Por tanto, debe actualizarse la planificación general realizada al comienzo

del proyecto, y adecuarla a las condiciones actuales establecidas por la solución a

desarrollar. Aún así pueden producirse cambios sustanciales a lo largo del desarrollo de

una etapa. Por este motivo, el proceso de planificación es una tarea cíclica y permanente

durante el desarrollo del proyecto. A continuación, se muestran el ciclo de planificación

del proyecto:


100

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

desarrollo debe recoger el resto de etapas que quedan por realizar, determinando de

manera específica el objetivo de cada una de ellas, considerando al mismo tiempo sus

duraciones para garantizar que la finalización del proyecto se encuentra dentro del plazo

previsto.

La revisión del Plan que se realizará a posteriori al terminar cada una de las etapas

consistirá en comprobar que se satisfacen los requerimientos funcionales del sistema,

así como los que están relacionados con el tiempo, ya que si no se cumplen con las

expectativas determinadas para cada etapa se deberá reestructurar la planificación.

La metodología de desarrollo que se está siguiendo es lineal aunque evidentemente la

revisión del plan definido sea cíclica debido a las verificaciones que se han de llevar a

cabo del mismo. Ya definido el ciclo de desarrollo y las actividades a realizar, se

procede a determinar la secuencia de ejecución de tales actividades, y la duración de

cada una. A continuación se muestra el plan de actividades:


101

La secuenciación de las actividades es lineal, de forma que no se admiten alteraciones

en la planificación en las mismas ya que determinan un camino crítico en el proceso de

desarrollo que se ha de realizar a partir de este momento. La finalización de las cuatro

actividades en conjunto se llevaría a cabo el día 151, considerando como día de inicio el

comienzo de la etapa de Diseño Externo. Además, se ha de tener en cuenta la actividad

de Gestión del Proyecto definida en el Plan de Gestión del apartado 1, ya que se su

realización es constante a lo largo de todo el desarrollo del proyecto. La duración de las

actividades en este punto se ha estimado en semanas, ya que permite estimar con más

facilidad el trabajo que queda por realizar así como el tiempo existente para llevarlo a

cabo con el objetivo de satisfacer la planificación inicial.

Para completar el plan, se deben tener en cuenta los recursos que se van a utilizar así

como el esfuerzo que se espera dedicar en cada una de las etapas. Dicha información se

encuentra recogida en la tabla de asignación de recursos que se estimó en el comienzo

del proyecto en el Plan de Gestión del mismo.


102

55.. DDiisseeññoo EExxtteerr nnoo


103

A partir de la plataforma tecnológica elegida en el Estudio de la Arquitectura, en esta

fase se completarán los requisitos físicos del sistema final, se diseñarán las entradas y

salidas, se completará la especificación de los procesos del modelo, y se elaborará el

modelo lógico de datos, a partir de los volúmenes manejados por el sistema. Con el

objetivo de completar la definición del modelo físico, se le dota de procesos de control,

de seguridad y auditabilidad, necesarios para una instalación mecanizada.

Y como el conocimiento del nuevo sistema aumentará considerablemente en esta etapa,

se podrá definir la estrategia a seguir en los planes de formación al usuario, la

conversión de los datos, las pruebas del sistema e implantación, como parte del ciclo

vida a recorrer.

5.1. Requisitos físicos del nuevo sistema

A partir de las necesidades hard/soft definidas en la etapa anterior para la solución

elegida, se debe completar detalladamente la plataforma hardware y software para la

puesta en marcha del sistema. Estos requisitos físicos se expresan bajo los conceptos de:

entorno operativo del sistema y configuración hardware/software.

5.1.1. Entorno Operativo del Sistema

Se especifican aspectos clave del diseño del sistema, como los descritos a continuación.

• Entrada, salida y recogida de datos

En este punto se establecen los diferentes tipos de entradas y salidas de datos, con el

objetivo de poder diseñar interfaces con otras aplicaciones o sistemas que dialogan con

éste. Además se debe especificar cómo van a llevarse a cabo las respectivas tomas de

datos para la entrada al sistema: quiénes van a realizarlas, con qué seguridad se va a

contar, qué información se va a introducir.


104

Si acudimos al modelo lógico de procesos obtenido en la etapa de Análisis de

Requisitos, podemos extraer las entradas y salidas del sistema a partir de los flujos de

datos que figuran en el Diagrama de Contexto. Estos flujos comunican entidades

externas con el sistema.

Los flujos de interfaz que el sistema en conjunto tiene con otras entidades se representan

en los respectivos diagramas de contexto de los dos controles de acceso:

Control de Visitas



105

• Mantenimiento de Ficheros

Los ficheros maestros del sistema que representan el código de la aplicación residirán

en el ordenador del usuario, en un directorio específico para ello, donde el usuario no

tenga acceso, u otra persona, o no se corresponda con los contextos habituales de trabajo

de dicho usuario. De esta forma, en cierto modo se garantiza de la mejor manera

posible, la seguridad y mantenimiento de los ficheros de arranque de los controles de

acceso.

Por otro lado, las bases de datos residirán en el servidor del departamento, responsable

de albergar todos los registros de control que se efectúen cada día. No se ha pensado en

llevar a cabo un plan de mantenimiento de las BBDD debido a su simplicidad y a que

no suponen un consumo considerable de la capacidad del servidor.

• Generación de Informes

En este apartado se definen los informes o avisos por pantalla que el sistema producirá

en determinadas situaciones. Dichos informes se catalogan como mensajes por pantalla

que se imprimirán ante situaciones consideradas relevantes para encaminar

adecuadamente la ejecución del programa, y como listados, generados a partir de las

visitas registradas (fichero Excel de las visitas de los tres últimos días). Los mensajes de

información que se proporcionarán en ambos controles de acceso se clasifican de la

siguiente manera:

Error:

Éstos a su vez, pueden ser tecnológicos, cuando hay un fallo en la comunicación con el

lector, bien porque no se encuentre conectado correctamente, o bien porque la

transmisión no se ha completado adecuadamente. También pueden ser errores de

aplicación, cuando el registro de un flujo de datos, ya sea de una visita o de un

movimiento de entrada y salida de un recurso, no se ha completado.


106

También se consideran avisos de este tipo los fallos derivados de las lecturas de la base

de datos cuando es necesario mostrar información del estado actual de los recursos del

departamento, o de las reservas y visitas registradas con anterioridad.

Confirmación:

Avisos informativos del correcto registro de la visita o del movimiento de inventario, ya

sea de entrada como de salida.

• Control de información y de seguridad del sistema

La ejecución de las aplicaciones de los diferentes controles de acceso es responsabilidad

del usuario final, trabajador interino de la universidad Comillas. Dicha ejecución no está

sujeta a ningún control de seguridad, sin embargo sí esta respaldada por la

autentificación inicial cuando el usuario arranca el ordenador por primera vez, ya que

para encenderlo debe de introducir su contraseña como usuario del sistema general de la

universidad.

Por otro lado, el acceso al servidor de base de datos del departamento se realiza bajo un

usuario y una contraseña, para poder realizar la conexión con el mismo.

La transmisión de los datos entre los lectores y el sistema no está cifrada ni sometida a

ningún control de seguridad, excepto cuando se escribe en un TAG RFID. Dicha

escritura se realiza bajo un algoritmo simple de codificación de la información textual

(de caracteres), cuando se quiere recoger el nombre y el primer apellido del responsable

del recurso, y no caracteres numéricos, como es el caso del identificador de dicha

persona.

Además, el acceso a una tarjeta RFID requiere la utilización de una clave determinada

para poder acceder a la información que almacena en sus bloques, de forma que supone

un punto de seguridad adicional del sistema.


107

• Rendimiento del sistema y escalabilidad

Con el fin de conseguir que el sistema alcance los objetivos marcados, se debe de medir

el flujo de datos que se manejará de manera que se pueda determinar el tiempo máximo

de respuesta. En este caso, el tiempo máximo queda definido por el acceso a la base de

datos que corresponda, ya que la comunicación con los lectores constituye una mínima

parte del tiempo total que supone un control de acceso. A su vez, el sistema se

caracteriza por carecer de una plataforma pesada de comunicaciones, de manera que el

tiempo de respuesta sólo dependerá de los accesos a la base de datos. El tiempo de

ejecución queda definido por las lecturas a la base de datos, más el tiempo de gestión

del control de acceso, más el acceso al servidor para registrar la visita o el movimiento

de reserva o devolución.

La arquitectura que presenta el Sistema Control de Accesos a edificios es fácilmente

portable, ya que se puede migrar a otro entorno de desarrollo instalando simplemente

los drivers de los lectores y los archivos de codificación sobre los que está programado.

Por otro lado, la expandibilidad del sistema es posible, instalando varios lectores

conectados entre sí a partir de una red local que permita la comunicación entre todos

ellos, y también con el servidor de base de datos. A su vez, se puede ampliar la

funcionalidad del sistema proporcionando más servicios que los que se exponen en el

proyecto actual.

• Condiciones de operación

El horario operativo de explotación del sistema se realizará durante la jornada laboral de

los empleados del departamento del IIT, es decir, durante todo el tiempo que el

departamento se encuentre abierto tanto para el personal del edificio como para las

personas ajenas al mismo. Los controles de acceso se llevarán a cabo en cualquier

momento que se corresponda con los contextos ya descritos con anterioridad: una nueva

visita, o un préstamo/devolución de un recurso.


108

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

afluencia de movimientos que se tengan que gestionar. Dicha carga de trabajo es

constante en cada registro, ya que en todo momento se trabaja con los mismos flujos de

información, siendo el mayor de todos el que se refiere a las inserciones de los mismos

en las diferentes tablas de la base de datos.

• Forma de implantación

El sistema residirá en el ordenador personal del usuario final, que se encuentra

conectado con la red local del departamento, y por tanto de la propia universidad. Dicho

ordenador está ubicado en la entrada del IIT, lugar estratégico desde donde se

gestionarán todas las visitas, préstamos y devoluciones de recursos.

La implantación del sistema es sencilla. En primer lugar se deben instalar los drivers de

cada uno de los dos lectores en el ordenador donde se va a ubicar el sistema (para ello

los lectores deberán estar conectados). Seguidamente se copiarán los ficheros de código

que constituyen las aplicaciones de los controles de acceso en un directorio específico

para ello.

Se ha optado por proporcionar dos ejecutables que permitan arrancar las aplicaciones de

Control de Visitas y Control de Inventario directamente, de manera que se configure

automáticamente el entorno de ejecución y su inicio. Dichos ejecutables se ubicarán en

el entorno de trabajo del usuario final (Véase Anexo 3).

5.1.2 Configuración hardware/software

De acuerdo con la solución elegida en el Estudio de la Arquitectura se completa la

especificación de los elementos hardware y software que van a constituir la plataforma

del sistema.


109

La especificación se plantea mediante un gráfico para la configuración hardware y otro

para la configuración software. En el primero de ellos se recogen los elementos básicos

que van a formar la plataforma y sus interconexiones de comunicación. En el segundo,

se representan los ficheros maestros, las bases de datos y productos software que estarán

soportados bajo la plataforma hardware

Gráfico de Configuración hardware

Gráfico de Configuración software


110

ESPECIFICACIONES HARDWARE DEL SISTEMA

Servidor de Base de Datos

• 8 CPUs

• 8GB RAM

• 250GB HD

Lector de tarjetas inteligentes

• CPU CMOS de 8 bits

• Alimentación 5V DC del propio ordenador.

• Soporta velocidades de comunicación entre 9600bps y 115200bps

• Puerto USB/Serial

Lector RFID

• Antena Incluida.

• Frecuencia de Operación 125KHz.

• Conector USB.

• Led de operación y led de lectura incorporado.

• Lectura de tarjetas a una distancia entre 5 y 9 cm.

• Alimentación requerida: 5V/80 mA.

PC Usuario

• 512MB de RAM

• Procesador 2,5MHz

• 100GB de HD

• Puertos serie y USB


111

ESPECIFICACIONES SOFTWARE DEL SISTEMA

Servidor de Base de Datos

• Sistema Operativo Solaris

• Gestor de Base de Datos Relacional

• SQL

• Adaptador TCP/IP

PC Usuario

• Windows XP

• Driver lector tarjetas inteligentes

• Driver RFID

• Java Virtual Machina

• Navegador

• Fichero de código fuente

• Drivers ODBC

5.2. Desarrollo del Modelo Físico Nuevo

Durante la etapa de Análisis de Requisitos se han diseñado los modelos físicos actual y

lógico actual, con el objetivo de conocer la situación de partida y detectar los problemas

y carencias. A partir de ellos y de los requisitos adicionales que se han ido especificando

se ha deducido el modelo lógico correspondiente al sistema que se está desarrollando

sin pensar aún en su mecanización.


112

En la fase de Estudio de la Arquitectura se ha definido una solución técnica y

organizativa, basada ya en una plataforma hardware y software. En el anterior punto, se

ha completado la especificación de esta plataforma, determinando cada uno de los

elementos que van a constituir la plataforma del sistema.

En este punto del desarrollo, se regresa al modelo lógico del sistema para transformarlo

en un modelo físico que contemple la plataforma tecnológica escogida.

El DFD del modelo físico tenderá a convertir qué hace el sistema por cómo lo hace

utilizando dicha plataforma. Para desarrollar este modelo deben realizarse diferentes

actividades:

• Establecer las fronteras de mecanización: qué procesos deben realizarse

manualmente y cuáles mediante ordenador.

• Determinar los diferentes tipos de procesos y especificarlos por lotes, on-line,

servicio…

• Diseñar las entradas y salidas del sistema: ventanas y formularios.

• Estimar volúmenes de información e identificar las transacciones críticas para

desarrollar el modelo lógico de datos a partir del modelo conceptual.

• Definir los controles y seguridad del sistema para su explotación: procesos de

control y seguridad.

Todas las actividades constituyen el modelo físico del nuevo sistema, y serán estudiadas

una a una en esta sección.


113

5.2.1. Fronteras de Mecanización

La implantación del sistema sobre la plataforma tecnológica se especificó en la etapa de

Estudio de la Arquitectura, fase en la que se determinaron las características técnicas,

organizativas y operativas de la solución a desarrollar. A partir de ello, se determinan

qué procesos se llevarán a cabo manualmente y cuales se automatizarán, apareciendo

ambos tipos en el modelo físico final del sistema ya que si no, la función de negocio

quedaría incompleta. A continuación se muestran los procesos clasificados según su

modo de ejecución, de los dos tipos de controles de acceso:

PROCESO MODO DE EJECUCIÓN

Control de Visitas

Iniciar Servicio RFID Automático

Identificar Automático

Consultar Reservas Automático

Confirmar Movimiento Automático

Realizar Reserva Automático

Actualizar Recursos Manual

Registrar Préstamos Manual

Consultar Personal Automático

PROCESO MODO DE EJECUCIÓN


Obtener Estado Actual

de los Recursos Automático

Esperar Lectura Manual

Identificar Recurso Automático

Obtener Reserva

Asociada Automático

Registrar Movimiento Manual


114

La tarea de definir el modelo físico final se realizará a partir del modelo lógico diseñado

en la etapa de Análisis de Requisitos representando mediante una línea discontinua las

fronteras entra unos procesos y otros. Dichas líneas se denominan interfaz hombre-

máquina debido a que aparecen básicamente en las entradas y salidas del sistema.

A continuación se muestra el DFD correspondiente al modelo lógico mostrando las

fronteras de mecanización:

Control de Visitas

En el DFD del modelo lógico se representa el proceso 1 seleccionado mediante una

línea discontinua indicando que será automatizado, mientras que el proceso 2 requiere la

intervención del usuario del sistema de forma que se ejecutará manualmente.


115


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.


116

5.2.2. Especificación de Procesos

En el diccionario de datos se definen todos los procesos originados en el modelo lógico.

A partir de las fronteras de mecanización, se añade una característica más a estos

procesos: manual o automático, ya que la definición realizada de los mismos se orientó

hacia la lógica de negocio más que hacia el contexto informático o de programación.

Por ello, se revisan de nuevo las descripciones de los procesos con el objetivo de

mejorar la miniespecificación actual de cada uno de ellos, considerando que el proceso

será iniciado por el usuario o automáticamente según corresponda.

Las nuevas miniespecificaciones se realizarán a partir de las ya existentes, que fueron

definidas en la etapa de Análisis de Requisitos para cada uno de los dos controles de

acceso que se están diseñando.


117

Objeto: Proceso 1, Iniciar Servicio TI

Tipo: Automático


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


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


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






118

Objeto: Proceso 4, Consultar Visitante

Tipo: Automático


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


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


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


Control de Visitas

Finalizar la comunicación con el lector LTCX, procediendo a su apagado.


119

Objeto: Proceso 1, Mostrar estado actual

de los recursos

Tipo: Automático







Objeto: Proceso 2, Esperar Lectura

Tipo: Manual









aplicación.

Objeto: Proceso 3, Identificar recurso

Tipo: Automático





la TRAMA, lo primero que realiza es la identificación del código recibido.


120

Objeto: Proceso 3, Identificar recurso (Cont)

Tipo: Automático



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





Objeto: Proceso 4, Obtener reserva

asociada

Tipo: Automático











121

Objeto: Proceso 5, Registrar movimiento

Tipo: Automático






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.


122

Ventana Control de Visitas

Es posible que durante la etapa de programación se realicen cambios en el diseño del

interfaz de forma dinámica, con la finalidad de alcanzar los objetivos marcados en cada

una de las etapas y de proporcionar un interfaz claro e intuitivo de cara al usuario final.


123

Ventana Control de Inventario

5.2.4. Diseño de Salidas

Los flujos de datos que salen del sistema hacia las entidades externas se pueden

considerar como salidas hacia el exterior, y podrán resultar ser ventanas de resultados o

formularios.

En el Control de Visitas el flujo de salida se mostrará siempre en la ventana principal,

siendo el usuario de la aplicación quien confirme la visita para proceder a su registro en

la base de datos.

Por otro lado, el Control de Inventario tiene además situaciones en las que se

proporciona un formulario para completar el movimiento de un recurso, ya sea un

préstamo no reservado con anterioridad o una devolución temprana respecto a la fecha

de devolución registrada.


124

5.2.5. Estimación de Volúmenes de Información

La estimación de volúmenes pretende alcanzar dos objetivos principalmente. El primero

de ellos es dimensionar el tipo de transacciones que se pueden presentar ajustando el

modelo a las necesidades físicas de éstas.

Las transacciones que supongan mayor número de accesos a la base de datos serán las

más críticas, de forma que se deberá prestar más cuidado con el objetivo de no

sobrecargar el sistema. Aún así, no se considera un problema como tal ya que no

existirán dos ejecuciones de las mismas características en paralelo.

También este estudio de volúmenes indicará si los procesos definidos en el modelo

lógico están bien diseñados respecto a los flujos de información con los que trabajan.

Para que el modelado sea físico y se pueda implantar en una máquina, se debe

considerar el modo más rentable y eficaz de acceso a los datos y de procesado de los

mismos.

El segundo objetivo determinado es el de obtener información acerca de las diferentes

entidades del modelo de datos, con la finalidad de realizar un buen diseño conceptual de

datos.

De esta manera se pueden encontrar nuevas necesidades de crear claves o

identificadores que resten tiempo de acceso a la base de datos de los programas, aunque

se requiera aumentar la redundancia y por tanto la ocupación en disco.

Para realizar el análisis se parte del modelo lógico o físico de procesos, del modelo de

datos, del ciclo de vida de las entidades y de los diseños de entrada y salida. Un primer

análisis se puede realizar configurando una Matriz de Procesos/Entidades:


125

Control de Visitas

PROCESOS/ENTIDAD VISITANTE EMPLEADO VISITA SISTEMA

Iniciar Servicio TI C

Esperar Lectura C

Mostrar Información L L

Consultar Visitante L

Consultar Personal L

Obtener Visita Actual A A A

Apagar Lector C


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


126

En las filas se colocan los procesos y en las columnas las entidades y relaciones del

modelo de datos. Una vez definida la matriz, se deben localizar las transacciones que

componen el sistema. Las transacciones son conjuntos de procesos que transforman la

información a través del sistema, constituyendo una actividad o función específica para

el negocio que se está diseñando.

El método que se ha escogido para definir las transacciones consiste en agrupar los

procesos de DFDs partiendo del DFD de nivel conceptual, y teniendo en cuenta la

integridad de la operación que se ha de realizar a través del sistema, combinándola

adecuadamente a la interacción externa del usuario final. Por tanto este método tiene en

cuenta el proceso lógico y el operador físico que lo realiza, pero no los datos que se

están manejando.

Control de Visitas


127

Los procesos 3, 4 y 5 tienen un cometido homogéneo, lectura de la base de datos, de

manera que no supone un riesgo para garantizar la compatibilidad de las operaciones y

la integridad de los datos. Realizan una lectura cada vez que se gestiona un control de

acceso, no se considera operación crítica, de manera que si se tiene en cuenta una

perspectiva de futuro se podrían ejecutar más de una transacción de este tipo en paralelo

si se desea llevar a la práctica controles de acceso en varios puntos del edificio, en este

caso, de la universidad.

El proceso 6 es el único que realiza una operación caracterizada por su criticidad,

debido a que realiza escrituras contra la base de datos responsable de registrar la visita

que se va a llevar a la práctica así como la escritura en el log, de forma que es coherente

que se considere como una transacción independiente de la ya descrita con anterioridad.



128

Los procesos 1,3 y 4 son de lectura, realizan consultas contra la base de datos con el

objetivo de obtener la información necesaria para poder realizar adecuadamente la

gestión de un recurso. Por ello, los tres procesos anteriores se pueden considerar en

conjunto como una misma transacción.

El proceso “Registrar movimiento” supone la escritura del préstamo gestionado en la

base de datos, y la actualización del estado del recurso que se ha entregado o devuelto.

Por este motivo, al tratarse de operaciones críticas que pueden alterar la coherencia e

integridad de la información almacenada, este proceso se ha de gestionar como una

transacción independiente.

5.2.6. Procesos de Control y de Seguridad

En el modelo de procesos diseñado en la etapa de Análisis de Requisitos no se tuvieron

en cuenta los posibles controles del proceso de explotación del sistema, debido a que

dichos procesos no definen la funcionalidad de negocio del sistema ya que se trata de

procesos destinados al control de la operación del sistema. Más concretamente,

podemos relacionar dichos procesos con el ámbito de la informática.

En este punto del proyecto ya se conoce con más detalle el nuevo sistema, de manera

que a continuación se procede a introducir y especificar en el modelo los controles de

operación y de seguridad, ya que se sabe cómo se van a mecanizar las tareas que se han

definido en los apartados anteriores. Todos estos procesos de control y de seguridad se

incluirán dentro de los procesos existentes ya que el alcance del proyecto es bastante

limitado y los procesos sólo se ejecutarían cuando se esté gestionando un control de

acceso (no es un proceso que se esté gestionando de manera activa durante todo el

tiempo). En otros proyectos, estos procesos se consideran independientes de los demás

debido a que realizan otras funciones adicionales como consecuencia de los controles

que lleven a la práctica, de forma que se incluyen en el modelo físico del sistema. Para

realizar un análisis completo del control del sistema, se deben estudiar los procesos de:


129

• Controles destinados a preservar la integridad de los datos

• Seguridad de la información y del acceso

• Auditabilidad del sistema por el usuario o por el administrador

• Procedimientos de recuperación de la información

• Historización de la información

Debido a las características del proyecto no procede realizar un estudio de todos los

puntos enumerados, ya que no se trata de un sistema de gran contenido funcional, y

mucho menos requiere de procedimientos de recuperación y de historización tan

exhaustivos al no manejar grandes volúmenes de datos de manera continua en el tiempo.

Tampoco se necesitan editar informes de análisis que muestren el correcto

funcionamiento del sistema, ni realizar actividades de auditabilidad. A continuación se

explican los aspectos de control y de seguridad que se consideran que debe de poseer el

sistema que se está desarrollando.

• Procesos de Control

Se entiende por control a la comparación de un hecho o una tarea realizada con un

objetivo prefijado. Estos objetivos son las reglas que de acuerdo a la finalidad del

sistema en estudio se deben cumplir, mientras que los hechos serán las circunstancias

detectadas en un momento dado durante el periodo de explotación del sistema.

Las medidas estudiadas y seleccionadas para garantizar la integridad de los datos son las

siguientes:


130

1. Control de los registros leídos frente a los registros grabados. Todo proceso que

realice una lectura de un conjunto de registros de una tabla de la base de datos,

para tratarlos y gestionarlos en su totalidad debe generar el mismo número de

registros insertados o presentados. Si no se cumple esta igualdad, algún registro

habrá sido despreciado, ignorado, o lo que es más grave, perdido.

2. Diseñar algoritmos que relacionen registros leídos, tratados y rechazados. Es

posible definir ecuaciones o algoritmos donde, de acuerdo al proceso realizado,

el número de registros leídos debe ser el mismo que la suma de los grabados más

los rechazados.

3. Controles de las lecturas y escritura realizadas contra la base de datos donde

residen los registros de información que maneja el sistema

No se contempla tener un registro de logging, ya que los movimientos que se escriban

en la base de datos, en este caso, muestran el estado actual de los recursos y del personal

en cada momento dentro del departamento.

• Seguridad de la información

Engloba los procesos o procedimientos de seguridad de uso, seguridad de los datos,

privacidad de la información y seguridad ante accesos no autorizados. Para estudiar

estos procesos se deben definir los riesgos potenciales del sistema considerando las

consecuencias de los mismos. Así los aspectos a considerar se han desglosado en cuatro

categorías:

1. Seguridad de los datos en su gestión, asegurando que los datos de salida desde el

sistema, sean utilizados por aquellos a los que van dirigidos.


131

2. Seguridad de la confidencialidad de la información, garantizando que

únicamente las personas que están autorizadas pueden acceder a la información

de carácter personal, de acuerdo con la legalidad vigente.

3. Seguridad del propio sistema proporcionando la disponibilidad del sistema ante

caídas provocadas por el hardware o software.

4. Asegurar el acceso al sistema desde un terminal.

Aún así, se deberá sopesar el esfuerzo del diseño y de programación que suponen estos

controles frente a los beneficios que van a proporcionar, y establecer el grado de control

y se seguridad que se requiere alcanzar.


132

66.. DDiisseeññoo II nntteerr nnoo


133

En esta fase de identifican y diseñan los diversos componentes software del sistema,

describiendo detalladamente sus especificaciones físicas. Dependiendo de la

arquitectura elegida correspondiente al sistema final, estos componentes pueden ser de

una naturaleza muy diferente.

Teniendo en cuenta el Modelo Físico de Procesos diseñado en la etapa de Diseño

Externo, donde cada proceso ha sido catalogado como de naturaleza de servicio, se

reunirán todas las funciones de negocio de nivel más detallado en función de su

tipología, y se estructurará el sistema en un conjunto de subsistemas. Generalmente los

subsistemas están formados por procesos de diferente naturaleza, pero en este proyecto

el sistema está definido por procesos de la misma naturaleza: de servicio.

También se deben considerar las ventanas y formularios que se han diseñado en la etapa

anterior, para garantizar la coherencia del diseño. Para aquellos subsistemas de tipo

cliente-servidor se tendrán que identificar y diseñar los módulos o programas cliente y

los programas de servicio, al igual que las transacciones (es la tipología que se

corresponde más fielmente a la del sistema que se está desarrollando).

Una vez diseñada la función de negocio y estructurada en sus componentes de

programación, se realizará una especificación de cada uno de ellos, denominada

Cuaderno de Carga.

Dicha especificación recoge todos los elementos de diseño que debe tener en cuenta el

programador para codificar cada programa, cómo son los ficheros de entrada y salida,

los diseños de ventanas utilizados por el programa, los controles que se deben aplicar, y

las reglas de negocio que deben satisfacerse para que a partir de los datos de entrada se

obtengan los de saldas esperados.

El Cuaderno de Carga es un documento que será utilizado tanto para la programación

como para llevar a cabo la etapa de pruebas.


134

Antes de iniciarse la programación se debe finalizar el diseño de la base de datos y

demás ficheros para que los programas se codifiquen utilizando la configuración

establecida, y mediante las pruebas correspondientes comprobar la correcta ejecución de

éstos.

Finalmente, a partir de la estrategia definida para cada uno de los planes de pruebas y de

formación, se deben diseñar los elementos software necesarios para llevarlos a la

práctica, y especificarse cada uno de los planes mediante las actividades a realizar, los

recursos a utilizar, y la planificación a seguir.

6.1. Técnicas a utilizar

Se cuentan con diversas técnicas para el diseño de componentes software de una

función de negocio. Las metodologías estructuradas basan su diseño de modelo de

procesos en la técnica de Diagrama de Flujo de Datos, por lo que los diseños de

funciones realizados sobre ellos permiten estructurarlos y diseñarlos paralelamente. De

esta manera existe una continuidad en el diseño, que de otro modo supondría abandonar

el modelo físico de procesos ya realizado para inventar el diseño detallado de la

función. Por este motivo, y considerando que las funciones de negocio serán On-line,

cualquier componente puede diseñarse basándose en los DFDs. Básicamente la técnica

que se va a utilizar consiste en realizar la conversión del DFD al diagrama estructurado

que le corresponda para identificar a cada componente.

Para los subsistemas online tanto las transacciones a ejecutar bajo un monitor

transaccional como los programas cliente-servidor, se utiliza la derivación del DFD

físico de cada función hacia el diagrama de cuadros estructurado o Structured Chart.

Éste es un diagrama que permite mostrar la jerarquía existente entre los módulos

principales y subordinados, de manera que cada uno realice una única tarea y se muestre

como un componente al que se le llama enviándole unos parámetros y devolviendo un

resultado.


135

Dependiendo de las características del diseño, éstos módulos pueden empaquetarse o

encapsularse en rutinas reutilizables, módulos funcionales o librerías de funciones

(DLLs o clases .java). Para comprender y diseñar el diálogo de la aplicación con el

usuario final, a veces resulta conveniente utilizar los Diagramas de Flujo de Aplicación,

pero en este caso no se considera necesario por la sencillez de la navegación que

caracteriza a las aplicaciones de los controles de acceso, al no variar de ventana

principal.

6.2. Subsistema Online

Aquellas funciones de negocio que no se ejecuten bajo un orden secuencial, y por el

contrario, se procesen de manera aleatoria a petición del usuario, constituyen el

subsistema online. Estas funciones han sido diseñadas en el modelo físico de procesos,

donde sus componentes son flujos de datos, almacenes y procesos. Mediante la

derivación del DFD de la función hacia un Diagrama de Cuadros Estructurado o STC,

estos componentes darán lugar a los ficheros, ventanas, y módulos de programa que se

diseñarán y especificarán unitariamente.

El método a seguir consiste en tomar toda la información de cada función disponible en

el modelo físico y derivarla al diagrama STC, mediante dos métodos posibles de

derivación y la creatividad de la persona que desempeña el perfil de diseñador. Por

último, se encapsula la función en una transacción o librería.

El diseño del software orientado a objetos utiliza otros paradigmas diferentes al

subsistema online, dadas sus características propias de herencia, encapsulamiento y

polimorfismo: diagramas UML. Por ello, se ha decidido diseñar el sistema utilizando las

dos metodologías: en OO porque uno de los requisitos del proyecto es que se programe

en Java, y también se representa como un subsistema Online ya que en futuras versiones

el software final del proyecto se puede implantar como un sistema distribuido donde

varios lectores, conectados a través de una LAN, se comuniquen con una aplicación que

se encuentre ubicada por ejemplo en el servidor o en otra estación de trabajo a la actual.


136

6.2.1. El diagrama de Cuadros Estructurado (STC)

El STC es un diagrama jerárquico donde los elementos son módulos con información

sobre su acoplamiento respecto a otros módulos: datos y control. Un módulo es un

programa con una función única, que puede ser llamado por otros módulos y a su vez

puede llamar a otro, mediante el paso de parámetros o flujos de información y/o control.

En el subsistema online aparece un nuevo componente que no aparece en un subsistema

BATCH. Lo constituyen los eventos que pueden proceder del propio sistema operativo

de la máquina donde reside el sistema o del exterior, provocados por las acciones del

usuario final sobre su interfaz.

De esta forma, cuando se diseñaron las ventanas o el interfaz, se tuvieron en cuenta los

diferentes eventos que podían tener lugar durante la ejecución de la aplicación, y la

actuación o respuesta que el sistema deberá realizar en cada situación. Ahora es el

momento de solapar la navegación del sistema con la lógica de negocio (servicios).

El modelo de diseño utiliza tres elementos, de manera similar a los modelos de

procesos:

• Estructuras de cuadros o diagrama STC (componente gráfico)

• Repositorio o diccionario (componentes de definición)

• Miniespecificaciones (componentes de especificación)

La técnica STC se basa en tres conceptos: descomposición, jerarquía e independencia.

La descomposición:

• División de las funciones de negocio, en módulos ejecutables.


137

• Fácil de mantener, al obtener una alta modularidad del software

• Minimiza la duplicidad del código

• Posibilita la reutilización del código

La jerarquía:

• Facilita el diseño basado en componentes: presentación, negocio y datos.

• Módulos altos, responsables de realizar la coordinación y el control del proceso.

• Módulos bajos, encargados de realizar las operaciones.

La independencia:

• Un módulo es un componente software: procedimientos, datos.

• Un módulo no debe preocuparse de la estructura de otro: son cajas negras.

El diagrama STC utiliza una sencilla paleta para realizar su diseño, aunque varia en

función de la herramienta CASE que se utilice. Los símbolos esenciales son los

siguientes:

• El rectángulo identifica un módulo genérico, que se localizará en un

determinado nivel dentro de la jerarquía. De esta forma, existirán módulos

padres o jefes, y módulos hijos o subordinados, de acuerdo con la jerarquía de

control del proceso que se desee establecer.


138

• Un rectángulo con una flecha en semicírculo en su base, representa a un módulo

iterativo, de forma que una vez que es llamado permanecerá en ejecución hasta

que se detenga su módulo principal.

• Un rectángulo con un rombo en su base representa un módulo de decisión, de

modo que la secuencia de ejecución de los módulos subordinados es un único

camino entre varios. Generalmente este camino será tomado en función del flujo

de control o de información que reciba.

• Un rectángulo con dos líneas paralelas representa un módulo reutilizable en

diferentes funciones de negocio, de manera que será diseñado una sola vez, y

llamado tantas veces como sea necesario.

• Para expresar la utilización de diferentes dispositivos de E/S se suelen utilizar

diversos símbolos, siendo los más comunes y genéricos los que se muestran en

los organigramas tradicionales. Este icono representa cualquier soporte de

entrada y salida, debido a que será el componente de definición del modelo el

que determine la unidad física que se utiliza. En este caso se corresponderán con

los lectores que se instalarán para realizar los dos controles de acceso.


139

• Las flechas con dirección dispuestas sobre la estructura jerárquica del diagrama

representan los flujos de información. Estos flujos son los datos de negocio que

manipulan los módulos. Estas mismas flechas en vídeo inverso hacen referencia

a los flujos de control, que se corresponden con los datos utilizados por el

sistema del ordenador para controlar el proceso: mensaje de error, finalización

correcta, caracteres de control de dispositivos…

El diagrama STC establece una jerarquía en la dependencia de los módulos principales

y sus subordinados. Un STC debe interpretarse de arriba hacia abajo y de izquierda a

derecha.

6.2.2. Derivación del DFD al STC

A partir del diseño físico de la función de negocio recogida en el modelo de procesos,

aplicamos el método de derivación de transformación para conseguir organizar dicha

derivación como una transacción online, donde existe un programa principal que

identifica dicha transacción o función. Para ello deben considerarse los siguientes

puntos:

1. Disponer o dibujar el DFD de último nivel

El DFD que se utilizará para realizar la derivación al diagrama STC es el que se diseñó

en la etapa de Análisis de Requisitos, el cual proporciona información sobre lo que hace

el sistema y cómo.

Para que el estudio sea mucho más detallado, se realizará la derivación de los dos

controles de acceso en paralelo, ya que se tratan de aplicaciones que se ejecutan de

manera independiente sobre bases de datos diferentes, a pesar de que en conjunto

constituyen el mismo sistema.


140

Control de Visitas



141

2. Identificar el centro de transformación (CT)

Los centros de transformación identificados en cada uno de los controles de acceso se

muestran con una línea roja discontinua.

Control de Visitas



142

3. Realizar la primera aproximación al STC

A partir de la localización del CT, se realiza una primera aproximación de la estructura

del diagrama. Generalmente cada función derivada requiere de un módulo principal, que

identificará la transacción. Este módulo se encargará de recibir la llamada del menú de

la aplicación, y coordinar la ejecución del proceso cediendo el control a sus módulos

subordinados.

Además el módulo principal será el que deba configurar las variables de entorno o

globales de la función, así como la petición de recursos al sistema para poder llevar a

cabo la ejecución de la transacción. Bajo éste módulo, siempre aparecerá una estructura

donde a la izquierda estarán los módulos del camino o camino de entrada, a la derecha

los módulos que configuran el camino o los caminos de salida, y en el centro, el módulo

o módulos que constituyen el centro de transformación.

Puede ocurrir que se cuenten con varios caminos de entrada o salida, en cuyo caso se

establecerá directamente la jerarquía de los caminos, o un módulo intermediario que se

encargue de controlar a los diferentes caminos de entrada o salida, bajo el cual se

subordinarán los caminos.

Los módulos intermediarios de entradas y salidas son responsables de controlar los

procesos de los caminos subordinados.


143

La primera aproximación correspondiente a los DFDs de las aplicaciones que realizan

los dos controles de acceso son las siguientes:

Control de Visitas


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.


144

Las burbujas de los caminos de salida se organizan en módulos subordinados en el

mismo sentido que en el DFD.

Además se deben mostrar los dispositivos de entrada y salida, en este caso los lectores,

el terminal del usuario y la base de datos, utilizados para realizar las lecturas y escrituras

que se configuren y utilicen a lo largo de la gestión del movimiento del control de

acceso.

Respecto a los flujos de datos se mantienen su estructura y ubicación, justamente en los

mismos lugares donde aparecen en el DFD, ya que son los módulos ahora los que se

encargan de transformar unos flujos en otros.

Se pueden introducir tantos flujos de control como se consideren que sean necesarios.

Dichos flujos de control permitirán conocer el estado de los controles de acceso en cada

momento.

En el diagrama STC correspondiente a cada uno de los DFDs de los controles de acceso

se muestran las burbujas en diferentes niveles caracterizados por un color diferente,

dependiendo del nivel que le corresponda.

Como se ha comentado con anterioridad, se han añadido las señales de control que se

transmiten entre el sistema y el lector, con el objetivo de gestionar y controlar el

correcto funcionamiento de la aplicación, y así reaccionar de la mejor manera posible

ante las diversas situaciones que se pueden dar durante cada una de las ejecuciones de

los controles de acceso.

A continuación se muestra para cada control de acceso el diagrama STC final diseñado

a partir de las consideraciones que se han ido comentando a lo largo del desarrollo del

presente punto.


145

Control de Visitas



146

5. Verificar la estructura final encapsulando módulos en programas

Una vez obtenida la estructura final, se debe realizar un último estudio de la

funcionalidad, verificando su correcto funcionamiento, y estableciendo la forma en que

se van a encapsular los módulos en los diferentes programas, dando lugar a las

diferentes transacciones que definirán el sistema final. Esta operación se debe realizar

teniendo en cuenta las pautas que se han descrito en al apartado 6.2.3. , referentes al

tamaño de los programas, la reutilización del código, la ubicación físico…

El módulo principal se corresponde con un módulo de control de la transacción, y

permanecerá como programa de control. La función de entrada, constituida por los

módulos encargados de recoger los flujos de datos de entrada, se encapsulará en un

único programa que será ejecutada en la máquina del usuario final, al igual que el resto

de módulos. El módulo principal será el responsable de controlar el estado de la

aplicación al iniciar su funcionalidad con una lectura, y a la hora de tratar los accesos a

través de las correspondientes llamadas a los demás módulos: el de acceso a la base de

datos, y el módulo que se comunica con el lector.

La función de negocio, por ejemplo Obtener Información en el Control de Visitas, se

encapsulará de manera aislada al resto, al menos en tratamiento, ya que facilita el

mantenimiento ante posibles cambios en un futuro. Hay que recordar que, el módulo de

Obtener Información representa el Centro de Transformación del Control de Visitas.

Por otro lado, los módulos de salida de ambos controles de acceso se gestionarán desde

el módulo principal, de forma que los primeros serán los responsables de informar al

usuario el resultado de la gestión y tratamiento del movimiento de acceso, y de hacerlo

permanente en la base de datos correspondiente.

Finalmente, el encapsulamiento del STC de Control de Visitas esta formado por cuatro

transacciones diferentes, y lo mismo ocurre con el subsistema Control de Inventario.


147

Control de Visitas



148

6.2.3. Consideraciones de diseño

El software se caracteriza por una serie de características que se deben tener en cuenta

cuando se quiere decidir cómo encapsular los programas, con el objetivo de conseguir

las ventajas más apropiadas para el diseño que se está realizando. Las aplicaciones

presentan requerimientos muy diferentes, por lo que hay que conocer al máximo detalle

el software que se está generando.

Dos propiedades que delimitan la división del sistema en subsistemas o módulos son el

tamaño y la complejidad. Es decir, decidir si interesa construir un programa con muchas

o pocas instrucciones. En este caso, la ejecución de los controles de accesos se realiza a

partir de ficheros de código cuyo tamaño no es grande debido a que el alcance del

mismo está acotado para el departamento de la universidad, y por tanto la funcionalidad

también. Debido al pequeño tamaño de los ficheros, permitirá evitar problemas de

diseño, de pruebas y sobre todo de mantenimiento.

A lo anterior, hay que añadirle que se evita el problema de falta de memoria para llevar

a cabo la ejecución de las aplicaciones, de modo que el tiempo de ejecución de los

mismos no se ven afectados por este problema. Aún así, hay que tener en cuenta que la

tecnología bytecode de Java presenta algún retardo en la gestión de eventos que se ven

compensados por los rápidos accesos a la base de datos.

Los ficheros de código se ubicarán en el ordenador del usuario final que se encuentra

localizado en la entrada del edificio del departamento del IIT. En este caso, al contar

sólo con una máquina servidora no existen problemas derivados de la distribución de la

carga a través de la red.

La complejidad es otro factor que determina la modularidad de los programas. Existen

funciones de negocio que por su complejidad generan gran cantidad de código. En este

caso, dado que dicha función de negocio se ha estructurado sobre el modelo físico de

procesos, siempre se puede descomponer en un conjunto de programas.


149

El factor de reutilización siempre debe tenerse en cuenta a la hora de encapsular los

programas. En este aspecto, las tecnologías orientadas a objetos han superado a los

paradigmas estructurados. Y la premisa seguida es muy razonable: se encapsulan

aquellos módulos que puedan ser reutilizados por otros componentes.

Otro elemento a tener en cuenta es el diseño basado en componentes, donde la lógica de

presentación suele estar en las estaciones cliente, o los servidores Web, la lógica de

aplicación en los servidores de aplicaciones, y la lógica de datos en los servidores de

bases de datos. En el presente sistema, la lógica de presentación y de aplicación se

encuentra en la máquina del usuario final, pero gestionadas por diferentes módulos, o

patrones de diseño. Al encapsular el software se tiene que considerar dónde se va a

ejecutar el programa, de manera que se pueda distribuir coherentemente con la función

de negocio a desempeñar en cada máquina o sistema.

En cuanto al diseño, existen dos factores que se deben tener en cuenta para determinar

la modularidad del software: el acoplamiento, o dependencias, que pueda existir entre

diferentes módulos, lo cual es negativo, y la cohesión, dependencia funcional, entre los

elementos de un módulo, factor que se pretende maximizar.

6.3. Diagrama del Sistema

Este tipo de diagramas son utilizados para mostrar visualmente las diferentes opciones

de navegación por el sistema, de manera que a partir de la ventana principal se observen

las diferentes funciones de negocio del mismo.

Cada diálogo o submenú podrá estar formado por varias ventanas o mostrarse dentro del

contexto de la ventana principal. El diagrama del sistema sirve por tanto como un punto

de referencia para realizar el Manual de Usuario.


150

Se debe tener en cuenta en todo momento el tipo de usuario final que será el responsable

de utilizar la aplicación, de forma que el diseño debe ser sencillo e intuitivo con el

objetivo de que el usuario se pueda familiarizar sin problemas con los programas.

Control de Visitas


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.


151

6.4.1. Cuaderno de Carga de Control de Visitas

1. Descripción de archivos

El programa se codificará en Java, de forma que los archivos tendrán la extensión de

.java (junto con sus correspondientes ficheros de compilación denominados .class).

Adicionalmente, se proporciona la posibilidad de recoger en un fichero Excel todas las

visitas que se hayan tratado durante los últimos tres días.

2. Descripción del tratamiento o lógica de negocio

INICIAR SERVICIO TI Identificador: PROCV.01

Al arrancar por primera vez la aplicación, se establecerá la comunicación inicial entre el

sistema y el lector TI, con el objetivo de configurar el canal de transmisión para las

lecturas que se realicen a posteriori.

ESPERAR LECTURA Identificador: PROCV.02

Seguidamente el sistema pasará a un estado de espera de lectura, hasta que reciba la

notificación, mediante el String de caracteres, de que se ha introducido una tarjeta. El

sistema siempre se va encontrar en este estado menos cuando se encuentre gestionando

una visita.

Si se recibe una persona ajena de la universidad o un alumno sin la tarjeta que le

identifica como tal, se proporcionará la opción de registrar la visita sin realizar una

lectura como tal.


152

IDENTIFICAR TARJETA Identificador: PROCV.03

Cuando el sistema reciba la cadena de caracteres deberá codificarlo para garantizar que

la tarjeta introducida es la de la universidad y proporcionar los datos personales del

visitante: identificador de alumno junto con el nombre y los apellidos.

OBETENER INFORMACIÓN Identificador: PROCV.04

Cuando se haya autentificado la tarjeta e identificado el visitante, se proporcionará la

plantilla de empleados del IIT, y las últimas visitas que la persona que se está

atendiendo ha realizado con anterioridad.

Si el visitante no dispone de carnet de alumno, se le asignará un identificador especial

para poder registrarlo en la base de datos, activando para ello la opción que estará

localizada en la ventana principal.

OBETENER VISITA ACTUAL Identificador: PROCV.05

El usuario deberá de seleccionar la fila correspondiente a la persona que se va a visitar,

ya sea en la tabla de visitas anteriores o en la tabla que recoge al personal del

departamento.

REGISTRAR VISITA Identificador : PROCV.06

La confirmación del usuario supone la inserción en la base de datos de los registros:

• Visitante: identificador, nombre, apellidos

• Visita: identificador visitante, identificador empleado, hora


153

MOSTRAR SOLUCIÓN Identificador: PROCV.07

Después de definir la vista que se está gestionando y de registrarla en la base de datos,

se deberá de informar al usuario del resultado de las inserciones en dicha base de datos.

Se considera la posibilidad de ofrecer a través de un menú, la opción de salir del

programa, de ayuda y de realizar el volcado del fichero de recuperación.

3. Estructura del programa: Pseudocódigo


154

4. Diseño del formato de los registros

Como se ha explicado en el punto del Modelo Conceptual de Datos, se han definido tres

tablas para poder realizar el registro de las diferentes visitas, cuyos formatos se

describen a continuación:

TABLA: USUARIOS IDENTIFICADOR: TABLACV.1

TABLA: VISITANTES IDENTIFICADOR: TABLACV.2

TABLA: LOG_VISITAS IDENTIFICADOR: TABLACV.3


155

6.4.2. Cuaderno de Carga de Control de Inventario

1. Descripción de archivos

La aplicación será programada en Java, de forma que el código fuente con extensión

.Java (junto con el compilado .class) residirá en una carpeta especial. Además, en dicha

carpeta se ubicarán también las DLLs necesarias para la comunicación con el lector

RFID.

2. Descripción del tratamiento o lógica de negocio

Mostrar estado actual de los recursos Identificador: PSCAP.1





Esperar Lectura Identificador: PSCAP.2







aplicación.


156

Identificar Recurso Identificador: PSCAP.3



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








Registrar movimiento Identificador: PSCAP.5





157

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

registros de un préstamo escribir en la tarjeta las condiciones con que se realiza éste por

ejemplo sin maletín, sin disco…Dicha escritura será controlada para no superar la

longitud máxima de 16B del bloque del TAG donde se almacenará el comentario.

3. Estructura del programa: Pseudocódigo


158

4. Diseño del formato de los registros

Como se ha explicado en el apartado del Modelo Conceptual de Datos, se han definido

tres tablas para poder realizar la gestión de la entrega o devolución de los recursos. El

formato de los registros de éstas se describe a continuación:

TABLA: PRÉSTAMOS IDENTIFICADOR: TABLACI.1

TABLA: ITEMS IDENTIFICADOR: TABLACI.2

TABLA: RESERVAS IDENTIFICADOR: TABLACI.3


159

77.. PPrr ooggrr aammaacciióónn


160

El objetivo de esta etapa es alcanzar la transformación del sistema en un conjunto de

programas que se ejecuten satisfaciendo los requisitos marcados bajo unos criterios de

seguridad. La dificultad reside en cómo realizar la transformación de la mejor forma

posible, debido a que va a depender de los lenguajes de programación que se utilicen, de

las herramientas y utilidades software disponibles, y del responsable de la

programación.

Como ya se ha comentado en las primeras etapas, no sólo es necesario realizar un buen

diseño, sino también conseguir un sistema tangible de calidad, con resultados

económicos, fiables, y que funcione adecuadamente facilitando y disminuyendo el

mantenimiento futuro.

En esta etapa se inician las pruebas del software con el objetivo de confirmar que cada

módulo del programa funciona correctamente de acuerdo a los criterios establecidos. No

basta con una compilación correcta, sino que deben contemplarse todas las

circunstancias en el que el programa pueda ejecutarse con el objetivo de evitar posibles

errores no controlados. Sobre todo, el programa debe tener un control completo de su

ejecución, de manera que en el caso de que se tengan que afrontar anomalías, el mismo

programa debe auditarse e informar al usuario de lo sucedido, para que el propio

programa o el usuario sea el responsable de tomar la decisión de qué acción realizar.

Además de codificar los programas, de acuerdo a los Cuadernos de Carga diseñados en

la etapa del Diseño Interno, deben desarrollarse los procedimientos catalogados o scripts

de ejecución, que constituyen los programas de control de ejecución de las funciones de

negocio o transacciones.

En base a los programas desarrollados y los procedimientos de control, se confeccionan

los manuales o guías de usuario y de explotación del sistema. El sistema quedará

definido por dos manuales de usuario y de explotación, debido a que esta formado por

las dos aplicaciones que llevan a la práctica los controles de acceso al edificio del



161

7.1. Análisis y diseño orientado a objetos

Dado que los programas serán codificados utilizando el lenguaje de programación Java,

se ha optado por realizar el Ciclo de desarrollo orientado a objetos.

7.1.1. Introducción

Las metodologías orientadas a objetos y de Análisis Estructurado se diferencian en el

énfasis que se aplica a los distintos componentes del modelado. Las técnicas de

orientación a objetos (OO) se encuentran dominadas por los modelos de clases y de

objetos. Estas técnicas representan la realidad a través de objetos, de clases de objetos,

de sus relaciones y de sus características propias o atributos, ofreciendo un contexto

para comprender el comportamiento dinámico y funcional del sistema. Por el contrario,

el Análisis Estructurado acentúa la descomposición funcional, proporcionando un

conjunto de funciones al usuario final.

Los métodos de Booch y OMT (Object Modeling Technique) se desarrollaron de

manera independiente entre sí, reconociéndose como métodos de orientación a objetos.

El desarrollo de UML (Unified Modeling Language) se inició en Octubre de 1994

cuando Grady Booch y Jim Rumbaugh unificaron los dos métodos anteriores de OO.

Las motivaciones que impulsaron el desarrollo de un lenguaje de modelización

unificado son las siguientes:

• Eliminar las diferencias entre los métodos de OO para evitar posibles

confusiones entre los usuarios.

• Unificar la semántica y notaciones simbólicas definiendo estándares universales.

• Mejorar los métodos existentes aportando mayor funcionalidad a los anteriores,

y nuevas formas de resolver la problemática más usual o habitual.


162

7.1.2. Ciclo de desarrollo orientado a objetos

El ciclo de desarrollo OO consiste en un modelo incremental o evolutivo, donde cada

incremento se desarrolla sobre las mismas etapas de la metodología estructurada,

utilizando para ello las técnicas y herramientas OO. Por tanto, un proyecto de desarrollo

software OO se inicia con la identificación de Necesidades y la Definición de

Requisitos. A partir de este punto, se desarrolla un primer incremento basado en las

metodologías de Análisis, Arquitectura, Diseño, Programación, Pruebas e Implantación.

El resto de incrementos se suelen realizar en paralelo, o en ciclo incremental en base a

los resultados que se van obteniendo en los incrementos anteriores. El número de

incrementos que se deben llevar a cabo para diseñar el sistema se deben definir en la

etapa de Identificación de Necesidades, donde se acuerda con el cliente el número de

incrementos y las entregas con nueva funcionalidad que se realizarán en cada uno.

La estrategia del paradigma incrementar se puede reforzar aplicando algunos

procedimientos de desarrollo como:

• Desarrollo temprano de la interfaz de usuario. Lo más recomendable es mostrar

el escenario sobre el que va a tener que trabajar el usuario final, y así realizar los

cambios que se consideren oportunos en las primeras etapas.

• Desarrollo temprano de las clases generales: es conveniente desarrollar las clases

de las que van a depender el resto como interfaces con el sistema operativo de

base de datos.

• Desarrollo temprano de las clases críticas: aquellas clases que son esenciales

para el funcionamiento del sistema, y así posibilitar su reutilización.

• Desarrollo de prototipos: consiste en el diseño de una versión parcial o básica

del sistema. El prototipo debe ser evolutivo, de manera que el software no sea

desechable, sino que a partir de él se pueda seguir desarrollando el sistema.


163

En la práctica, las fases de análisis de requisitos, de validación y de aceptación se llevan

a cabo a través de reuniones constantes con el director del proyecto. Dichas reuniones

definen el desarrollo incremental de la codificación del sistema, pero no del estudio y

diseño del mismo. Por este motivo, se realiza el diseño detallado del sistema de acuerdo

a la metodología estructurada sin considerar la tecnología de programación que se va a

utilizar (presente documento), y por otro lado, se lleva a cabo la codificación del sistema

de acuerdo al ciclo de vida de la metodología de orientación a objetos en la etapa de

programación del desarrollo estructurado del proyecto.

7.1.3. Técnicas OO en las fases de la metodología

Las fases del ciclo de vida cuyas actividades técnicas se encuentran influenciadas por

las técnicas de OO a utilizar son las de Análisis de Requisitos y de Programación.

Técnicas de orientación a objetos en la etapa de Análisis de Requisitos

La etapa de Análisis de Requisitos se debe completar con técnicas OO para realizar el

modelado del sistema. Estás técnicas se encuentran orientadas a la recopilación de

información para llegar a obtener el modelo final del sistema. Este modelado se realiza

de manera iterativa durante esta etapa, y se completará definitivamente en la etapa de

Diseño, por lo que se comienza con unos diagramas básicos que se irán refinando a

medida que se obtiene más información del sistema.

En una primera iteración se debe obtener un conocimiento general del sistema

identificando y describiendo el proceso que el sistema debe controlar y realizar. Tras

sucesivas iteraciones deben definirse todos los elementos que constituyen el dominio de

la aplicación. Al final de este proceso de análisis se obtiene un modelo del sistema tanto

desde la perspectiva estructural (descripción estática) como desde la de comportamiento

(descripción dinámica). Por tanto, los objetivos a cubrir en esta etapa son:

• Descomponer funcionalmente las operaciones complejas en clases del dominio.


164

• Organizar el sistema en partes manejables.

• Determinar el comportamiento dinámico esencial de las clases cuyo

comportamiento es fundamental para la lógica de negocio y control del sistema

en su totalidad.

Diagrama de Clases: modelo estático

Es un modelo de estructura estática, por lo que la información que representa no

depende del factor tiempo. Proporciona una descripción del problema reflejando la

realidad. Su descomposición en otros niveles depende de la complejidad del problema y

no del sistema.

El diagrama de clases es una técnica de modelización, por lo que requiere de un

componente gráfico y un componente de definición de sus atributos y de su

comportamiento. Debe describir las operaciones de las clases, así como la dependencia

entre ellas, utilizando tanto la definición textual como el pseudocódigo. El modelo

describe:

• Las precondiciones: Los requisitos que se deben cumplir desde el punto de vista

del sistema.

• Las postcondiciones: Los eventos, acciones o informaciones que se pueden

garantizar después de haber ejecutado con éxito una clase.

• Las excepciones: Las diferentes situaciones especiales o anómalas que pueden

tener lugar durante la ejecución del programa, y que deben tenerse en cuenta

para garantizar la continuidad del servicio.

• Los parámetros. Argumentos de entrada y salida.


165

• Los algoritmos: Los métodos utilizados por las clases.

• Los resultados: Son las salidas resultantes de la ejecución de una clase.

Este modelo determinará la jerarquía de herencia para todas las clases generadas, así

como las relaciones entre ellas.

Diagrama de Clases inicial de Control de Visitas


166

Diagrama de Clases inicial de Control de Inventario

Definición de Casos de Uso

La definición de los casos de uso permite mostrar la funcionalidad del sistema desde el

punto de vista del usuario. Un caso de uso es una descripción de un conjunto de

caminos de ejecución relacionados a través de su comportamiento, durante la

interacción del usuario con el sistema.

Estos caminos son el resultado de los estímulos o eventos transmitidos al sistema por

una entidad externa o actor: el usuario, el sistema u otro interfaz externo. Si el nivel de

detalle de estudio del sistema es alto, y se trata de un sistema complejo, es conveniente

utilizar diagramas de secuencia o diagramas de actividad como una forma de especificar

los casos de uso de una manara más precisa. Sin embargo en esta fase no se suelen

utilizar los diagramas de secuencia.


167

Caso de Uso de Control de Visitas

Control de Visitas tiene un único Caso de Usos que es el de Registrar Visita, el cual

representa la única funcionalidad de negocio de la aplicación de Visitas.

Las diferentes situaciones o contextos que pueden existir durante la ejecución de la

aplicación, se contemplarán en la definición detallada del escenario primario del caso de

uso como extensiones del mismo.

Casos de Uso de Control de Inventario


168

Técnicas de orientación a objetos en la etapa de Diseño

En esta etapa se parte del modelado realizado en las fases anteriores para conseguir un

nivel de detalle que permita implantar el sistema mediante el lenguaje de programación

elegido, en este caso Java.

Por tanto, los diagramas diseñados con anterioridad serán los mismos que los utilizados

en ésta pero llevando a cabo un refinamiento y un diseño detallado, incorporando a su

vez, nuevas clases necesarias para alcanzar y completar el sistema deseado. Al detallar

los modelos realizados se pretende conseguir:

• Refinamiento del modelo estático:

� Definir todas las clases del sistema

� Diseñar todos los diagramas de clases de todos los componentes

� Identificar asociaciones y agregaciones

� Determinar todos los atributos de las clases y sus enlaces

� Determinar la jerarquía de herencia para todas las clases del sistema

� Describir completamente los métodos utilizados en las clases

• Refinamiento dinámico:

� Describir detalladamente la interacción de las clases que poseen un

comportamiento dinámico

� Especificar los eventos y estados de las clases con comportamiento dinámico


169

� Completar el modelo de clases contemplando los cambios realizados durante

el modelado dinámico (nuevas clases, operaciones, atributos, etc.)

Por ello, los diagramas utilizados en esta etapa deberán de hacer referencia a los

diagramas sobre los que se realiza el refinamiento, diseñados con anterioridad.

Diagrama de Clases Detallado

Como se ha comentado con anterioridad, el diagrama de clases representa una visión

estática del sistema. Se puede representar con varios niveles de detalle, de manera que

se añadirá al diagrama inicial el resto de clases necesarias para definir el sistema

completamente.

Diagrama de Clases Detallado de Control de Visitas


170

Diagrama de Clases Detallado de Control de Inventario

Diagrama de Casos de Uso Detallado

Un caso de uso muestra la manera de interactuar con el sistema. Cuando se diseña un

diagrama de este tipo, se debe considerar además de la funcionalidad del sistema, el uso

que le va a dar el usuario final. Cada caso de uso constituye una recopilación de

sucesos, cuyo evento inicial lo provoca una entidad externa o actor, especificando la

interacción existente entre el sistema y el actor.

En esta etapa del proyecto se estudian detalladamente los casos de uso que se han

definido en la fase de Análisis de Requisitos, estudiando el escenario primario de cada

uno de ellos así como las extensiones que surjan y que se tengan que tener en cuenta.


171

El diagrama debe de estar acompañado por una descripción específica de los casos de

uso fundamentales que constituyen la funcionalidad del sistema. La descripción de cada

uno de ellos debe ser lo más completa posible, a pesar de que los diagramas en esta fase

se hayan refinado respecto a su versión inicial si fuese necesario. Para cada caso de uso

debe especificarse:

• Una breve descripción del caso de uso, indicando su empleo, su modo de

funcionamiento y frecuencia de utilización.

• Una descripción de la secuencia de iteraciones entre el actor y el sistema,

incluyendo las posibles excepciones de la secuencia esperada del

funcionamiento del sistema.

• Las precondiciones que activan el caso de uso: son los requisitos que se han de

satisfacer, desde el punto de vista del sistema, antes de iniciarse cada caso de

uso, sin tener en cuenta aquellos requisitos de los que el usuario no tenga

visibilidad.

• Las postcondiciones: representan los eventos, acciones o informaciones que se

han obtenido como resultado de la ejecución correcta del caso de uso.

• Las excepciones: corresponden a los situaciones anómalas que pueden ocurrir en

cualquier momento, durante la ejecución normal del caso de uso. En el caso de

que existan, se debe especificar cuándo suceden, cómo se detectan y el

tratamiento que se debe realizar con ellas.

A continuación, se realizan las descripciones de los escenarios primarios

correspondientes a los casos de uso que definen la funcionalidad de cada uno de los

controles de acceso. Junto a cada escenario primario, se indicarán las estructuras de

datos utilizadas, así como las posibles extensiones que pueden tener lugar durante la

ejecución del control de acceso.


172

Descripción del Caso de Uso de Control de Visitas

Caso de Uso: Registrar Visita

• Actor: Usuario final

• Precondiciones: El sistema debe haber detectado correctamente la conexión del

lector de tarjetas inteligentes, y comprobar la comunicación entre ambos.

• Trigger: Introducir una tarjeta de la universidad o activar la opción de visita sin

tarjeta.

• Escenario Primario:

1. El sistema muestra los datos de la tarjeta inteligente.

2. El sistema muestra los datos de la plantilla del personal de las últimas vistas

realizadas por el visitante identificado.

3. El sistema muestra los datos de la plantilla del personal de todo el departamento

del IIT.

4. El usuario selecciona la fila de la persona que se quiere visitar.

5. El sistema registra correctamente la visita definida.

6. El sistema muestra un mensaje de información del correcto registro de la visita.

7. El sistema cambia al estado de espera de lectura de tarjeta.


173

• Estructuras de datos:

� Datos de la tarjeta inteligente:

Código de alumno de la universidad

Nombre del alumno

Apellidos del alumno

� Datos de la plantilla del personal

Identificador empleado

Nombre del empleado

Apellidos del empleado

Teléfono asociado al despacho del empleado

Planta donde se encuentra el despacho del empleado

Puesto de trabajo del empleado

• Extensiones:

1a. El sistema muestra el identificador asignado al visitante sin tarjeta inteligente.

1. El usuario introduce el nombre y apellidos del visitante.

2. El sistema salta al punto 3


174

5a. El sistema no registra correctamente la visita.

1. El sistema muestra un mensaje informando que ha ocurrido un error y no se

ha registrado correctamente la visita.

2. El sistema reinicia el servicio de lectura pasando al estado de espera de

lectura.

7a. El usuario selecciona opción de salir de la aplicación.

1. El sistema muestra diálogo de confirmación

2. El usuario confirma la finalización de la aplicación.

3. El sistema pasa a permanecer al estado de inactividad.

7a2. El usuario no confirma la finalización de la aplicación.

1. El sistema pasa al estado de espera de lectura.

Descripción de los Casos de Uso de Control de Inventario

Caso de Uso: Registrar Préstamo Sin Reserva

• Actor Primario: Usuario

• Precondiciones: El lector RFID debe estar conectado al ordenador, y reconocido

por el sistema.

• Trigger: El usuario pulsa el botón de Registrar Préstamo para realizar la entrega

en ese momento del recurso


175


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.


� 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


176

Nombre y apellidos del usuario del recurso

Comentario personal del préstamo del recurso

• Excepciones:

2a. El usuario no confirma los datos del registro instantáneo.

2a1. El sistema pasa al estado de espera de confirmación de operación.

3a. El sistema comprueba que los datos del registro instantáneo introducidos no son

correctos

.

3a1. El sistema muestra un mensaje informado el error detectado.

3a2. El sistema salta al punto 1.

4a. El sistema no registra correctamente el movimiento.



5a. El sistema actualiza correctamente el estado del recurso gestionado.



7a. El usuario pulsa el botón de finalizar la aplicación.


177

Caso de Uso: Registrar Préstamo Con Reserva

• Actor Primario: Usuario final

• Precondiciones: El lector RFID está conectado al sistema, y existe comunicación

entre ambos.

• Trigger: El usuario pulsa el botón de Registrar Préstamo para realizar la entrega

en ese momento del recurso.


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.


� Datos del préstamo:

Duración en horas del préstamo


178

Timestamp del día de entrega del recurso

Día de devolución del recurso

Nombre y apellidos del usuario del recurso

Comentario personal del préstamo del recurso

• Excepciones:

2a. El usuario no confirma el movimiento.


3a. El sistema actualiza correctamente el estado del recurso gestionado.



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.


179

• Trigger: El usuario pulsa el botón de Registrar Devolución cuando se entrega el

recurso al departamento antes de la fecha de devolución registrada.


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


180

1a1a. El sistema no actualiza con éxito la reserva asociada

1a1a1. El sistema muestra el mensaje de error.

1a1a2. El sistema pasa al estado de confirmación de operación.

7.2. Manual de Usuario

La estructura que se ha definido para realizar el Manual de Usuario es la siguiente:

1. Introducción

1.1. Objeto de la aplicación

1.2. Ámbito de la aplicación

1.3. Documentación relacionada

2. Descripción general del sistema

2.1. Entorno de trabajo

2.2. Perfiles de usuario

2.3. Funcionamiento del sistema

2.4. Sistemas relacionados

2.5. Ayudas

3. Funcionalidades del sistema

3.1. Función de negocio 1

3.1.1. Descripción de la funcionalidad

3.1.2. Perfiles de los usuarios autorizados

3.1.3. Operativa de la función

3.2. Función de negocio 2

3.2.1. Descripción de la funcionalidad

3.2.2. Perfiles de los usuarios autorizados

3.2.3. Operativa de la función


181

En el epígrafe 1 se introduce la finalidad del sistema, el ámbito o funciones de negocio

que se realizan, y las referencias a otros documentos que pueden ayudar al usuario a

entender y manipular el sistema, como procedimientos de actuación, normas y

estándares referentes a las funciones recogidas por la aplicación, aunque debido a la

sencillez que caracteriza a la aplicación no se considera que sea necesario desarrollar

este último punto.

En el segundo epígrafe se realiza una exposición general del sistema, describiendo el

entorno de trabajo donde se ejecuta o accede a la aplicación, haciendo referencia a los

elementos hardware y software más relevantes. También se especifican los perfiles de

usuario asignando a cada uno de ellos las operaciones que pueden ejecutar.

Dependiendo del tipo de aplicación, suelen aparecer diferentes tipos de usuario, aunque

el Sistema Control de Accesos sólo tiene un único usuario final que desempeña el papel

de administrador y de “usuario” al mismo tiempo.

Si desde el puesto cliente se pueden acceder a diferentes aplicaciones, es necesario

llevar un control de dónde y cómo se ubican, así como la forma a partir de la cual se

puede lanzar su ejecución. Por último, se contempla el sistema de ayudas utilizado por

la aplicación, indicando si es a nivel de ventana, de campo de información o existe una

función específica de ayudas por donde puede navegar el usuario.

En el epígrafe 3 se describen las distintas funciones de negocio que pueden realizar

dentro de la aplicación, describiendo el alcance de la funcionalidad de cada una de ellas,

los perfiles de usuario necesarios para ejecutaras, y la operativo o procedimiento de

actuación. Este procedimiento se describe realizando un recorrido por los diálogos de la

función.

En el epígrafe 4 se pueden incluir una serie de anexos que ayuden al usuario a

comprender y a manejar la aplicación.


182

Así, un glosario de los términos utilizados en las ventanas y mensajes de la aplicación,

así como de los acrónimos utilizados, será de gran utilidad para aquellos usuarios que

por diversos motivos no hayan podido familiarizarse con la operativa.

También es recomendable recoger los problemas e incidencias que se pueden presentar

con mayor frecuencia durante la actividad del sistema, y así describir al usuario la forma

de resolverlos. Dado que anteriormente se ha expuesto el modo de operación de cada

función de negocio de forma individual, no será necesario incluir como anexo la

descripción detallada del interfaz de la aplicación como un epígrafe por separado.

7.2.1. Manual de Usuario de Control de Visita

Se adjunta como Anexo 1

7.2.2. Manual de Usuario de Control de Inventario

Se adjunta como Anexo 2


183

88.. PPrr uueebbaass


184

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

deben realizarse una serie de pruebas para garantizar el correcto funcionamiento de las

mismas, y verificar que se cumplen con los requisitos funcionales determinados en las

etapas de iniciales del proyecto.

Así, el objetivo principal de esta etapa es el de someter al sistema desarrollado y a sus

componentes, a una serie de comprobaciones encaminadas a garantizar un nivel de

fiabilidad aceptable. Esta fase es crítica, y debe realizarse con la misma dedicación y

planificación con las que se ha desarrollado el resto de proyecto.

Si los resultados son satisfactorios, se procederá a la aceptación de los mismos y a la

implantación del sistema en el entorno para el cual ha sido diseñado, pero en caso

contrario se tendrán que resolver las anomalías encontradas suponiendo un retraso en la

finalización del proyecto ya que se ha de revisar el diseño y la codificación realizada.

El entorno de pruebas suele configurarse y adaptarse antes de realizar cualquier tipo de

pruebas con el objetivo de simular el entorno final de producción. Para ello, se utiliza un

ordenador personal que representará la herramienta de trabajo del usuario final del

sistema, que se encontrará conectado a los lectores y donde residirán las aplicaciones

correspondientes a los controles de acceso.

Por otra parte, suelen utilizarse volúmenes representativos de información para llevar a

cabo cada una de las pruebas, ya que los volúmenes de datos reales que va a manejar el

sistema representan un alto grado de ocupación del servidor donde residen. En cuanto a

la información personal a utilizar para realizar las pruebas se corresponderán con datos

meramente intuitivos de manera que permitan emular la gestión de los controles de

acceso.

El equipo de pruebas en este caso lo constituye el alumno junto con el director, ya que

éste último podrá realizar un mejor control de calidad del sistema final.


185

Durante las etapas de Programación, Pruebas del Sistema e Implantación se ejecutan

diferentes pruebas parciales sobre el sistema final, cada una de ellas con objetivos

diversos, aunque en función del tipo de software diseñado se le suele someter a unas

pruebas u otras.

En la etapa de Pruebas del Sistema se ejecuta el bloque de pruebas más completo con el

objetivo de comprobar la funcionalidad del sistema y el rendimiento exigido en los

requisitos.

Para ello, previamente se habrán llevado a cabo las pruebas unitarias de cada

componente, y posteriormente se realizarán las pruebas de carga y de rendimiento sobre

el entorno real de producción. Los tipos de pruebas que se van a realizar son los

siguientes:

• Pruebas de Encadenamiento

Comprobado el correcto funcionamiento del software, este tipo de pruebas permiten

garantizar la adecuada comunicación entre todos los componentes que intervienen en la

gestión de un control de acceso. En este caso se corresponde con la comunicación

existente entre los lectores y el sistema.

• Pruebas de Explotabilidad

Estas pruebas tienen el objetivo de determinar la facilidad que el sistema ofrece para ser

utilizado e explotado en el entorno de producción. Para ello, se ejecutan las aplicaciones

correspondientes a los controles de acceso siguiendo las instrucciones recogidas en el

Manual de Usuario sobre las entradas, salidas, informes de errores y controles.


186

• Pruebas de Recuperación

En esta caso las pruebas de recuperación se encuentran localizadas en las operaciones

que se realizan contra la bases de datos, de manera que se tienen en cuenta los

comandos de Rollback y Commit para garantizar la coherencia de las bases de datos

utilizadas en la gestión que realizan cada una de las aplicaciones.

• Pruebas de Aceptación del Usuario

Estas pruebas junto con las de Usabilidad son realizadas por el usuario en su entorno de

trabajo. La finalidad de esta prueba es la de validar el sistema desde el punto de vista

funcional y operativo. Generalmente se utiliza el Manual de Usuario para seguir la

navegación del sistema en cada una de las funciones de negocio. Esta aceptación

únicamente certifica la aceptación del usuario con las aplicaciones desarrolladas, hecho

que supone la implantación del sistema en el entorno real de producción. En este

entorno se ejecutarán más pruebas sobre el sistema comprobando su funcionalidad en el

entorno final de producción, que determinará la conformidad del usuario con el software

implantado. El usuario ejecutará esta fase de pruebas bajo la supervisión y guía del

autor del proyecto.

• Pruebas de Usabilidad

Normalmente las pruebas de aceptación del usuario se complementan con las pruebas de

usabilidad cuya finalidad es la de verificar la facilidad de uso del sistema que debe

manejar. Estas pruebas se realizarán en el IIT en el entorno de trabajo del usuario final.

Cuando se habla de facilidad de uso se está haciendo referencia al diseño de la interfaz y

al Manual de Usuario. Durante estas pruebas se pude aprovechar para formar al usuario

sobre la utilización del sistema, de forma que resulta mucho más sencillo y claro el

aprendizaje, al realizarse directamente con la persona que ha diseñado el sistema.


187

Al preparar el entorno de pruebas para emular el contexto de explotación del sistema, se

han instalado y configurado tanto el software base como el de aplicación de acuerdo a

los componentes utilizados. A partir de ello, se realizará el Manual de Instalación y

Configuración necesario para configurar el entorno de producción. El manual

correspondiente al sistema se adjunta como Anexo en la presente documentación.

Un aspecto importante que se ha de tener en cuenta sobre la tecnología RFID es que

dependiendo de la posición con que se ubique la tarjeta que se desea leer sobre el lector,

puede que la operación no se realice correctamente porque no se estabiliza la

comunicación entre el lector y el TAG para su lectura. En este caso el sistema recibe el

error generado por el lector y se lo comunica al usuario. Este error de lectura se debe a

que el lector detecta la tarjeta pero el nivel de la señal es demasiado bajo, de forma que

al no ser capaz de realizar su identificación lo considera un problema generando un

mensaje de error. Este aspecto funcional se describe detalladamente en el Manual de

Usuario de Control de Inventario.


188

99.. II mmppllaannttaacciióónn


189

Tras probar la integridad del software del sistema y especificar su instalación y

configuración, se ha llevado a cabo la instalación del sistema en el centro de producción

donde se va a llevar a cabo su explotación: se han instalado los drivers y las

aplicaciones correspondientes a los dos controles de acceso en la estación de trabajo del

usuario final del departamento, configurando adecuadamente los orígenes de acceso a

las bases de datos necesarias.

Instalado el software sin presentar problemas se han realizado dos pruebas adicionales

que se suelen ejecutar en esta etapa del proyecto, y que consolidan la finalización

correcta del mismo. Una de ellas tiene como objetivo certificar el correcto

funcionamiento de la aplicación utilizando los recursos reales del entorno de

explotación. La otra prueba necesaria es la aceptación final del usuario, que desde su

puesto de trabajo, y bajo los diferentes perfiles con los que puede utilizar el sistema,

certifica el correcto funcionamiento del sistema.

Superadas ambas pruebas el sistema se encuentra finalmente implantado en el entorno

de producción garantizando su correcto funcionamiento.


190

1100.. CCoonncclluussiioonneess


191

El Sistema Control de Accesos proporciona diversas ventajas a partir de la ejecución

conjunta de las dos aplicaciones que lo constituyen, gracias a las tecnologías de control

de accesos empleadas para llevar a cabo su implantación, las cuales están basadas en la

utilización de tarjetas inteligentes y de radiofrecuencia.

Por un lado, se consigue informatizar el registro de las entradas y salidas del centro del

IIT gracias a la implantación del subsistema de Control de Visitas. Este sistema a su vez

permite facilitar y agilizar el trabajo realizado por el usuario final, y disminuir en gran

medida el tiempo de espera que afecta considerablemente a la persona que realiza la

visita.

Respecto a la tecnología RFID los puntos positivos son diversos:

• Permite llevar a cabo un monitoreo detallado y automático de los movimientos

que tienen lugar en el departamento, posibilitando la identificación rápida del

recurso. Si se dispone de un almacén con un número considerable de recursos,

por ejemplo el de una biblioteca, esta tecnología permitiría identificar el estado

de los libros.

• Proporciona la posibilidad de administrar inventarios tan efectivamente que

muchas de las tareas manuales que se han realizado hasta el momento pueden

ser eliminadas, los procesos o funciones de negocio pueden ser acelerados y los

errores de despacho reducidos. Por tanto, se mejora considerablemente la gestión

de inventarios.

• Permite gestionar el inventario garantizando una organización del mismo,

disponer de la traza e historia de los productos, prevenir robos, evitar pérdidas

de recursos por desconocimiento de su ubicación y acelerar las consultas de

inventario.


192

• Los códigos de barras (UPC) serían una alternativa a la tecnología RFID pero

requieren que se escanee uno por uno los artículos y que la etiqueta sea visible

para poder realizar adecuadamente su lectura, sin embargo los lectores de RFID

pueden escanear simultáneamente varios artículos tanto tengan el TAG visible

directamente como que no (lecturas anticolisión), siempre que se cumpla con las

distancias mínimas. Además, el código de barras típicamente suele informar de

qué artículo se trata, por ejemplo Códigos UPC, mientras que la tecnología

RFID maneja números de identificación más largos y permite identificar cada

artículo individualmente y recoger información adicional asociada al mismo:

número de serie, lote, etc…


193

1111.. GGlloossaarr iioo ddee TTéérr mmiinnooss


194

Análisis: Estudio y modelización de una función de negocio para ser mecanizada

mediante un sistema de ordenador.

Análisis de Requisitos: Primera etapa del ciclo de vida del desarrollo de un sistema, una

vez identificadas las necesidades generales.

Atributo: Dato elemental que expresa las características o propiedades de una entidad o

una relación.

Burbuja: Proceso representado en un diagrama de flujo de datos mediante un círculo.

Cardinalidad: En una relación mide la máxima y mínima participación de las entidades

cuando se observa el conjunto de las ocurrencias de cada una de ellas.

CASE: Computer Arded Software Engineering. Ingeniería del software asistido por

ordenador.

Ciclo de vida: Conjunto ordenado de las etapas por las que transcurre el desarrollo de

un sistema informático.

Control de Calidad: Actividades encaminadas a detectar y corregir cualquier desviación

durante el desarrollo del sistema.

Cuaderno de Carga: Especificación del diseño de un programa.

DER: Diagrama de Entidad-Relación.

Diagrama de Casos de Uso: La definición de los casos de uso permite expresar las

facilidades del sistema desde el punto de vista del usuario. Un caso de uso es una

descripción de un conjunto de caminos de ejecución relacionados por su

comportamiento durante la interacción del usuario con el sistema.


195

Diagrama de Clases: Es un modelo de la estructura estática que proporciona una

descripción del problema reflejando el mundo real y cómo lo ve el cliente. Su

descomposición en otros niveles depende de la complejidad del problema y no del

sistema. Debe mostrar las operaciones de las clases así como la dependencia entre ellas,

utilizando tanto la definición textual como el pseudocódigo.

Diagrama Conceptual: Es el primer nivel en que explosiona el proceso que representa

el sistema en estudio bajo un modelo de procesos. Muestra los procesos esenciales del

sistema.

Diagrama de Contexto: Primer nivel de un modelo de procesos, donde se representan

las entidades externas al sistema y los flujos principales de entrada y salida.

Diagrama del Sistema: Se utiliza para mostrar visualmente la composición de las

opciones de navegación por el sistema, de modo que a partir de una ventana inicial se

observen los diferentes diálogos de funciones.

Diagrama de Flujo de Datos (DFD): Representación gráfica de un modelo de procesos

donde aparecen los flujos de datos y sus transformaciones a lo largo del sistema.

Diagrama de Presentación: Diagrama de formato libre utilizado para mostrar algún

concepto o alguna idea, dentro de las especificaciones de análisis y de diseño del

sistema.

Diagrama Entidad-Relación (DER): Representación gráfica de un modelo de datos

donde aparecen las entidades de datos y sus relaciones.

Diccionario de Datos: Conjunto de entradas de datos que constituyen los nombres y

descripciones de todos los elementos utilizados en la especificación del software del

sistema.


196

Documento de Conceptos del Sistema: Especificación de las necesidades del cliente,

donde se recogen los objetivos del sistema en estudio.

EDT: Estructura de división del trabajo. Es una descomposición del proyecto en un

conjunto de tareas manejables.

Entidad: Concepto dentro de la organización o del negocio que es de gran interés para

el estudio del sistema.

Especificación: Descripción detallada del elemento software objeto de análisis, diseño

o programación.

Flujo de Datos: Rango de información que al entrar en un proceso sufre una

transformación dando lugar a otra porción de información diferente.

Gestión de Configuración: Componente de la ingeniería del software que estudia el

control de las versiones de los componentes software y la gestión de cambios a lo largo

del desarrollo.

IIT: Instituto de Investigación Tecnológico

Interrogador: Lector. Son dispositivos que activan y / o dan potencia a una etiqueta

electrónica y recuperan la información contenida en la misma.

Metodología: Método sistemático de abordar la resolución de un problema, o un

conjunto de métodos y procedimientos que describen el proceso mediante el cual se

debe abordar las etapas del ciclo de vida del desarrollo software.

Middleware: Es la capa de software que realiza las operaciones de gestión y control de

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


197

Modelo: Representación del sistema o de algún elemento constituyente del mismo. Los

modelos están formados por tres elementos: componente gráfico, componente de

definición y componente de especificación.

Modelo Conceptual de Datos: Representa el conjunto de familias de datos o de

entidades, sus posibles relaciones de acuerdo a las reglas de negocio, y sus

características o atributos.

Modelo Físico del Nuevo Sistema: Representa las funciones de negocio del nuevo

sistema y cómo van a ser implantadas sobre una plataforma tecnológica hardware,

software y de comunicaciones.

Modelo Lógico del Nuevo Sistema: Representa las funciones lógicas en que se

estructura el sistema, determinado qué debe hacer y no cómo se debe implementar sobre

la plataforma tecnológica.

PFC: Proyecto Fin de Carrera

PSCA: Proyecto Sistema Control de Accesos

Repositorio: Sistema de almacenamiento de una herramienta CASE donde se recogen

las especificaciones de los componentes de acuerdo con el modelo de datos o metadata

de dicho almacén.

RFID (Identificación por Radio frecuencia): Es un método para identificar artículos

utilizando ondas de radio. La gran ventaja en comparación con la tecnología de códigos

de barras es que el láser debe ver el código para efectuar la lectura correspondiente. Las

ondas de radio no necesitan tener una línea directa de visión y pueden pasar a través de

diversos materiales tales como el cartón o el plástico.

TAG: Tarjeta o etiqueta RFID


198

UML: Unified Modeling Language. Metodología de análisis y diseño orientado a

objetos.

UPC (Código Universal de producto): Sistema de numeración y codificación en barras

de Norteamérica desarrollado a fines de la década de sesenta y principios del setenta por

la industria alimenticia de los EUA que se utiliza para la identificación de productos de

artículos de consumo que son escaneados en un punto de venta minorista.

UPCO: Universidad Pontifica Comillas


199

1122.. BBiibbll iiooggrr aaff ííaa


200

Páginas Web:

RFID Journal:

www.rfidjournal.com

RFID Magazine:

www.rfid-magazine.com

Página de RFID de Texas Instruments:

www.ti.com/tiris/default.htm

Página de Randall Jackson:

http://rfid.home.att.net/

Enlaces a Webs de fabricantes de tecnologías RFID:

http://members.surfbest.net/eaglesnest/rfidweb.htm

Manual RFID:

http://www.rfid-handbook.de/links/index.html

Sistemas identificación por radiofrecuencia de Philips:

http://www.semiconductors.philips.com/products/identification/index.html

Sistema de Control de Accesos Liberté:

http://www.alfi.it/es/liberte.html

Estándares aprobados RFID:

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


201

Chips RFID de Temic/Atmel:

http://www.atmel.com/atmel/products/prod26.htm

Algunas aplicaciones interesantes:

http://www.capta.com.mx/solucion/ems_rf_id_tags.htm

Artículos RFID y API de Java

www.sun.com

Software de tarjetas inteligentes

www.opencard.org

Documentos:

Standard Card IC MF1 IC S50

Manuales de Circontrol:

� Programación

� Usuario

� Protocolo de Comunicaciones


202

AAnneexxoo 11

MM aannuuaall ddee UUssuuaarr iioo ““ CCoonnttrr ooll ddee VViissii ttaass””


203

Capítulo

Página

1. Introducción

204




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


204

El presente documento se corresponde con el Manual de Usuario de la aplicación de

Control de Visitas, que recoge una descripción del funcionamiento del sistema y del

entorno de explotación, así como un apartado de ayuda para afrontar los problemas más

usuales que pueden surgir.

1. Introducción

En este primer apartado del manual se pretende realizar una breve descripción del

subsistema de Control de Visitas.


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.


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.


205


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.


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.




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.


206

3. Funcionamiento del sistema

El interfaz de la aplicación es el que se adjunta a continuación:

El sistema se encuentra en espera de gestionar una visita, ya sea con tarjeta inteligente o

no. Las funciones que se proporcionan cuando la aplicación permanece en dicho estado

son las de salir, consulta y ayuda:


207

3.1. Gestión de visitas con carnet de alumno

La lectura de una tarjeta supone la transmisión de los datos leídos de la misma hacia el

sistema. Cuando este recibe los datos del visitante los muestra por pantalla,

proporcionando al mismo tiempo la información del personal al cual ha visitado en las

últimas ocasiones (si procede) y de toda la plantilla del departamento. Si la persona

identificada ha realizado visitas con anterioridad, es muy probable que la próxima visita

que protagonice sea a la misma persona.


208

Proporcionados los datos iniciales, el usuario debe confirmar la persona que es visitada

para definir finalmente la visita gestionada. Para ello es necesario realizar la selección

de la lista de visitas recientes, o bien, de la de todo el personal.

3.2. Gestión de visitas sin carnet de alumno

La aplicación proporciona la posibilidad de gestionar visitas de personas que por

cualquier motivo no disponen del carnet de alumno de la universidad. En esta situación

el usuario de la aplicación debe activar el checkbox de “Introducir los datos a mano”,

para escribir el nombre y los apellidos de la persona que desea realizar la visita. Cada

vez que se reciba una persona sin carnet se le asignará un identificador unívoco para

poder registrarlo en la base de datos.

Tras la selección, el subsistema muestra los datos de toda la plantilla del personal del

departamento con el objetivo de que se indique quien es el visitado.


209

Determinados todos los datos que constituyen una visita, se debe confirmar su registro

pulsando el botón de “Registrar Visita”.

3.3. Opción “Consulta”

El servicio de “Consulta” permite afrontar informes de las últimas

visitas realizadas en el departamento.

Mediante esta opción se abre la aplicación Excel con un listado de las últimas visitas

realizadas. Esta información procede de los movimientos gestionados en la

correspondiente base de datos del servidor del departamento.


210

4. Ayudas

La aplicación proporciona una opción de ayuda destinada a facilitar la gestión de una

visita ante una posible duda. Dicha ayuda se corresponde con un submenú en el que

mencionan los diferentes pasos que hay que llevar a cabo para realizar el registro de una

visita.

Adicionalmente, en este punto se recogen los posibles errores que pueden surgir durante

la ejecución de la aplicación.

4.1. “Error al intentar acceder a la tarjeta”

Si se introduce una tarjeta distinta a la de la UPCO o una tarjeta dañada, la aplicación

nos mostrará un mensaje de error.

Si esto ocurre, se deberá extraer la tarjeta incorrecta, hacer clic sobre “aceptar” y

asegurarse de introducir una tarjeta de la universidad.

4.2. “No se he encontrado ningún lector”

Esto se problema puede deberse a dos motivos: que no haya ningún lector de Tarjetas

Inteligentes instalado correctamente, o que el acceso al lector está bloqueado por otra

aplicación (por ejemplo no se ha iniciado el servicio de Tarjetas Inteligentes de su

Sistema Operativo).


211

Para resolver el problema se deben tener en cuenta los siguientes puntos:

1. Compruebe que tenga instalado correctamente un lector compatible con el estándar

PCSC10, y con los drivers actualizados.

2. Compruebe que el servicio de Tarjetas Inteligentes esté iniciado.


212

AAnneexxoo 22

MM aannuuaall ddee UUssuuaarr iioo ““ CCoonnttrr ooll ddee II nnvveennttaarr iioo””


213

Capítulo

Página

1. Introducción

215





216

216

216

217

3. Funcionamiento

3.1. Gestión de préstamos

3.2. Gestión de devoluciones

3.3. Botón de “Nueva Lectura”

3.4. Escritura en una tarjeta RFID

218

220

223

226

226

4. Ayudas

4.1. “Error al identificar el recurso, aproxime de nuevo la tarjeta”

4.2. “Error de conexión con la base de datos”

4.3. “No se han encontrado recursos registrados”

4.4. “Error en el acceso a la base de datos. Se finaliza la aplicación”

4.5. “La fecha de devolución es errónea. Debe ser anterior a XXXX-XX-XX”

4.6. “Error de escritura RFID. Aproxime de nuevo la tarjeta RFID al

lector”

4.7. “El campo “Información adicional del préstamo” debe ser más

corto”

4.8. “Error al actualizar los recursos de la devolución. Inténtelo de

nuevo”

4.9. “Error al registrar la devolución”

228

228

228

229

229

230

230

231

231

231


214

Capítulo

Página

5. Ubicación de las tarjetas para la lectura y escritura RFID 233


215

El presente documento se corresponde con el Manual de Usuario de la aplicación de

Control de Visitas, que recoge una descripción del funcionamiento del sistema y del

entorno de explotación, así como un apartado de ayuda para afrontar los problemas más

usuales que pueden surgir.

1. Introducción

En este primer apartado del manual se pretende realizar una breve descripción del

subsistema de Control de Inventario.


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.


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


216


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.


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.




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.


217


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.


218

3. Funcionamiento del sistema

Al arrancar la aplicación se mostrará la disponibilidad actual de todos los recursos que

constituyen el inmovilizado prestable del departamento:

La disponibilidad de los recursos se representa mediante un checkbox, de manera que si

se encuentra activo significa que el recurso está disponible. Cuando un recurso sea

prestado se indicará en la tabla de recursos el nombre del usuario que lo tiene.

El sistema permanecerá en estado de espera hasta que el lector le comunique que ha

identificado un tarjeta, momento en el que se selecciona en la tabla el recurso

correspondiente.

En este primer paso de identificación, se mostrará un mensaje informativo si el recurso

tiene asociada alguna incidencia que haya que recordar. Dicha información puede ser

referente al préstamo, como por ejemplo que no se ha llevado el ratón o un disco, o bien

puede estar relacionada con algún defecto del propio recurso: por ejemplo que el cable

del cargador esté roto.


219

Otro elemento importante del interfaz de usuario es el que indica el tipo de movimiento

que se puede realizar sobre un recurso, “Prestar” si se trata de la entrega de un recurso,

o “Devolver”:

Como se puede observar en la imagen anterior, tras la identificación del recurso y del

tipo de movimiento se muestra la reserva asociada que se va a gestionar. En el ejemplo

que se adjunta como imagen, se ha leído el TAG del Móvil 1, de forma que se ha

consultado en la base de datos sus posibles reservas, y se ha obtenido que la reserva más

próxima a la fecha actual tiene como usuario a Pedro Silva, y el préstamo ha de

realizarse el 03/05/2007.


220

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

notificándolo:

3.1. Gestión de préstamos

Se pueden gestionar dos tipos de préstamos: aquellos que tienen reservas asociadas y los

que no. Éstos últimos se corresponden con situaciones en los que no hay reservas para

los próximos días, o en los que hay una reserva confirmada pero no para el día actual.

Préstamo con reserva

Se corresponde con la situación normal en que una persona ha reservado con antelación

y se dispone a recoger el equipo. Para confirmar la entrega de un recurso se deberá

pulsar el botón de “Registrar Préstamo”:


221

Cuando el préstamo que se ha de gestionar tiene como día de inicio de la reserva el

actual o uno anterior, la aplicación proporciona una ventana con todos los datos que

definen la entrega del recurso, sin permitir posibles cambios, motivo por el cual

aparecen los campos deshabilitados. La ventana de diálogo que se muestra se

corresponde con la que se muestra a continuación:

El campo correspondiente a “Información adicional del préstamo” está destinado a

recoger algún tipo de incidencia relacionada con el recurso. Esta funcionalidad se

explicará en el punto 3.4 de este manual.

Préstamo sin reserva

Esta situación se denomina también “Reserva instantánea”. Como se ha comentado con

anterioridad, el préstamo sin reserva tiene lugar cuando no hay reservas asociadas o

cuando la reserva registrada no tiene como fecha de préstamo la actual.


222

Como en el caso anterior, después de mostrar el mensaje informativo, si no hay

reservas, o la reserva correspondiente, en el caso de que si exista alguna, el usuario debe

confirmar la gestión del préstamo pulsando el botón de “Registrar Préstamo”:

Seguidamente, el sistema mostrará una ventana de diálogo cuyo contenido dependerá de

si hay o no alguna reserva del recurso.

Si no existen reservas asociadas al recurso, la ventana permitirá determinar la fecha y

hora de devolución que se desee:

Igualmente, el usuario de la aplicación deberá indicar a quién se entrega el recurso, un

comentario que justifique el préstamo, y la información del estado del préstamo, campo

que se explica en el apartado 3.4.


223

Cuando la entrega del recurso se encuentra condicionada por una reserva que está ya

confirmada, el sistema mostrará una ventana de diálogo que mostrará por defecto la

fecha y hora de devolución más tardía con las que se permite llevar a cabo la entrega del

recurso. Esta restricción se validará cuando el usuario confirme el préstamo después de

que haya introducido el resto de datos. La ventana correspondiente a esta situación es la

que se adjunta a continuación:

3.2. Gestión de devoluciones

El movimiento correspondiente a una devolución se realiza de manera similar al

préstamo de un recurso.

Después que el sistema identifique el recurso y el tipo de movimiento, se muestra la

reserva correspondiente a la devolución que se va a registrar. Por ello, para confirmar la

devolución se deberá pulsar el botón de “Registrar Devolución”:


224

A continuación la aplicación proporciona un mensaje informando si la operación de

devolución se ha registrado correctamente o no, ya que implica realizar una

actualización del estado del recurso y del préstamo asociado que se acaba de finalizar.

El mensaje que confirma el correcto registro del movimiento se muestra con la siguiente

imagen que se adjunta:

Por último, después de registrar el movimiento de devolución, se proporciona la

posibilidad de escribir en la tarjeta algún problema o deficiencia física del recurso que

haya que recordar en posteriores gestiones.

El proceso de escritura en las devoluciones es el siguiente:

1. Se muestra una ventana donde se deberá escribir la descripción del problema.


225

El comentario que se desee escribir no debe ser superior a 16 caracteres debido a las

restricciones de las tarjetas RFID; si se supera se mostrará el siguiente mensaje de error:

2. A través de otra ventana informativa se solicitará que se aproxime la tarjeta del

recurso al lector para proceder a realizar la escritura del comentario que se ha descrito

en el paso anterior:

Si la escritura se realizó correctamente, el lector emitirá un sonido de confirmación de la

escritura, y el sistema mostrará la tabla de recursos con el estado de disponibilidad

actualizado con la devolución que se acaba de gestionar: se activa el checkbox

correspondiente al recurso devuelto.

Si por el contrario, se produce un error se muestra el siguiente mensaje:


226

Para resolverlo, se deberá pulsar el botón de aceptar hasta que se escuche el sonido

emitido por el lector confirmando la lectura. Si se considera que la tarjeta no se

encuentra bien situada frente al lector, se deberá posicionar de nuevo entre los diferentes

intentos hasta conseguir la escritura.

3.3 Botón de “Nueva Lectura”

Si después de identificar un recurso no se desea realizar el movimiento correspondiente

se debe pulsar el botón de “Nueva Lectura” para poder llevar a cabo otra lectura.

3.4. Escritura en una tarjeta RFID.

Cuando se realiza una escritura, el comentario o descripción a grabar en la tarjeta no

debe superar los 16 caracteres de longitud máxima ya que se excede el tamaño del

bloque de memoria donde se va a escribir.

Siempre que se tenga que realizar una escritura en una tarjeta, el sistema solicitará al

usuario que aproxime dicha tarjeta al lector RFID. El mensaje de petición es el

siguiente:

Cuando se acepte se realiza la escritura.


227

Si la operación no se completa se muestra un mensaje de error:

Para conseguir que la operación se realice correctamente se deberá comprobar que la

tarjeta se sitúa adecuadamente sobre el lector, y aceptar de nuevo el intento de escritura.

En el momento en el lector emita un beep significará que la operación se ha llevado a

cabo satisfactoriamente.


228

4. Ayudas

En este apartado se contemplan los posibles errores que se pueden producir durante la

ejecución de la aplicación. Para cada uno de ellos, se proporcionan una serie de pautas

que permiten resolverlos.

4.1. Mensaje de error: “Error al identificar el recurso, aproxime de nuevo la tarjeta”

1. Compruebe que el lector está conectado al ordenador.

2. Sitúe de nuevo la tarjeta sobre el lector, asegurándose que se encuentra próxima

a la antena. (Ver apartado de Posición de lectura).

4.2. “Error de conexión con la base de datos”

1. Comunicar el problema al administrador del sistema.


229

La conexión inicial que se establece al arrancar la ejecución ha fallado:

1.1. Verificar el estado de la base de datos en el servidor.

1.2. Comprobar el driver de acceso a la base de datos.

4.3. “No se han encontrado recursos registrados”

1. Comunicar el problema al administrador.

La base de datos con la que trabaja de la aplicación no es la correcta, o la tabla de

recursos del departamento se encuentra vacía.

1.1. Comprobar que la tabla de recursos está disponible y contiene registros realizando

una consulta directa contra el servidor

4.4. “Error en el acceso a la base de datos. Se finaliza la aplicación”

1. Comunicar el problema al administrador.


230

El acceso a la base de datos del personal del departamento ha fallado:

1.1. Verificar el estado de la base de datos “card_personal” en el servidor.

1.2. Comprobar el driver de acceso a dicha base de datos.

4.5. “La fecha de devolución es errónea. Debe ser anterior a XXXX-XX-XX”

La fecha de devolución introducida al definir los datos de configuración de la

reserva instantánea debe ser anterior a la fecha y hora en la que hay que entregar el

recurso en el siguiente préstamo confirmado. Por tanto, introduzca:

• Fecha de devolución anterior a la fecha de entrega mostrada en la reserva más

próxima asociada.

• Fecha de devolución igual a la fecha de entrega pero la hora de devolución

menor a la de entrega.

4.6. “Error de escritura RFID. Aproxime de nuevo la tarjeta RFID al lector”


231

Acepte el mensaje informativo, y automáticamente se realizará un nuevo intento de

escritura.

4.7. “El campo “Información adicional del préstamo” debe ser más corto”

La descripción o comentario relacionado con un determinado recurso debe tener una

longitud máxima de 16 caracteres. En caso de no satisfacerse este restricción, se

mostrará este mensaje de error.

4.8. “Error al actualizar los recursos de la devolución. Inténtelo de nuevo”

Repita de nuevo todo el proceso de devolución explicado con anterioridad.

4.9. “Error al registrar la devolución”


232

Cuando las devoluciones se realizan con antelación al día que se había acordado es

necesario actualizar el estado de la reserva asociada, de manera que el equipo queda

marcado como libre, y el sistema puede aceptar nuevas reservas sobre el mismo a partir

del instante e que se realiza la devolución. Si el proceso de actualización falla se lanza

este tipo de error. Por ello, se ha de repetir de nuevo todo el proceso de devolución

explicado con anterioridad.


233

5. Ubicación de las tarjetas para la lectura RFID

Para evitar posibles errores de lectura o de escritura derivados por la incorrecta posición

de la tarjeta sobre el lector, se ha de tener en cuenta que la correcta ubicación es la que

se muestra en la imagen que se adjunta.


234

AAnneexxoo 33

MM aannuuaall ddee II nnssttaallaacciióónn


235

Capítulo

Página

1. Instalación de la JVM

1.1. Añadir la variable de entorno PATH

236

236

2. Guía de instalación de la aplicación Control de Visitas

2.1. Instalación del driver del lector de tarjetas

2.2. Instalación del software OpenCard

2.3. Instalación de la aplicación

238

238

239

244

3. Guía de instalación de la aplicación Control de Inventario

3.1. Instalación del driver del lector RFID


244

244

245

4. Creación del vínculo con la base de datos

245


236

A continuación se indican los pasos que se han de seguir para llevar a cabo la

instalación del sistema en entornos Windows, aunque al tratarse de herramientas

multiplataforma y gratuitas, podrían instalarse en otros sistemas operativos.

1. Instalación de la JVM

Para obtener la JVM hay que dirigirse a la página Web www.sun.com y acceder a la

sección de descargas, donde se puede descargar de manera gratuita la Java 2 Platform

Standard Edition (J2SE). Ésta se puede descargar como kit de desarrollo, JDK, o

simplemente como entorno de ejecución, JRE.

Una vez descargado el fichero, hay que ejecutarlo realizando un doble clic sobre el

mismo y seguir los pasos que el asistente de instalación indicará para completar la

instalación.

1.1. Añadir la variable de entorno PATH

Con el objetivo de poder ejecutar y

compilar aplicaciones Java desde la

consola de comandos, añadimos a la

variable Path el directorio en el que

se encuentran los archivos binarios

de Java.

Para ello entre en Propiedades del

sistema haciendo clic con el botón

derecho de su ratón sobre el icono

de MI PC o pulse la tecla Windows

seguida de la tecla Pause.


237

A continuación se debe hacer clic en la pestaña Opciones avanzadas y seguidamente en

el botón Variables de entorno.

Por último hay que crear la nueva variable de usuario indicando el nombre de la

variable Path y el valor de la variable C:\directorio del jdk\bin.


238

2. Guía de instalación de Control de Visitas

El primer paso, antes de instalar la aplicación, será cerciorarse de que se encuentra

instalado en el ordenador donde se va a ejecutar la aplicación la JVM, el driver del

lector y las librerías de OpenCard.

Si no se tiene instalado algún componente de los mencionados anteriormente, a

continuación se explica como instalar cada uno de ellos paso a paso.


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.


239

2.2. Instalación del software OpenCard

El primer paso es descargar las librerías de OpenCard (software gratuito y abierto) de la

siguiente página Web, www.opencard.org, en la sección download. Hay que descargar

el fichero installocf.class localizado en el apartado OpenCard Framework All-in-One.

Una vez descargado el fichero, se abrirá la consola de comandos y se debe ejecutar lo

siguiente “java installOCF”.

En caso de que a la hora de ejecutar el comando anterior aparezca un mensaje de error

como el de la siguiente captura, deberá añadir en la variable de entorno “classpath” el

directorio en el que se encuentra, de la siguiente forma:


240

La ejecución correcta del fichero de OpenCard descargado permitirá arrancar el

asistente de instalación del sw:

Seguidamente, nos pedirá la ruta de instalación y el nombre de un grupo de programas

para colocarlo en el menú Inicio.

A continuación, pedirá confirmación para crear un fichero de configuración interna, en

donde responderemos de manera afirmativa.


241

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

que responderemos “PC/SC” ya que el estándar “Java Card”; aún no está tan

popularizado como el PC/SC, y por tanto para la realización del proyecto se escogió el

estándar PC/SC.

Tras hacer esta elección si se diese el caso en que se mostrara un mensaje de error, lo

ignoraremos pulsando “OK”


242

Mas tarde, se pedirá una ruta para guardar los ficheros internos, en donde por defecto

establecerá la ruta de las librerías de Java, que no debe ser modificada.

Por último pedirá una confirmación antes de instalar.

Después de aceptar el comienzo del proceso de instalación, se mostrará una ventana con

el logotipo de OpenCard que contiene un diálogo que indica el tiempo restante para

finalizar dicha instalación, es como una barra de progreso.


243

Es posible que durante la instalación aparezca un mensaje de reemplazo de ficheros con

el mismo nombre pero diferente fecha, en estos casos se cogerá la opción que mantenga

el fichero más actual.


244


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.


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.


245

Seguidamente el asistente solicitará que se indique cómo se van a proporcionar los

drivers del hardware que se desea instalar. La opción que se ha de seleccionar es la que

se corresponde con “Instalar el driver desde una ubicación específica”, de manera que

en el siguiente paso se deberá pulsar sobre l botón de “Examinar” y determinar la ruta

de acceso a la carpeta donde se copiaron los ficheros. Finalmente, el sistema

comunicará el resultado del proceso de instalación del nuevo hardware.


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.


246

A continuación se abrirá una carpeta en la que tendrá que hacer doble clic sobre

Orígenes de datos (ODBC).

En la siguiente ventana usted deberá seleccionar el driver del gestor de bases de datos

correspondiente para su implantación real.

Las aplicaciones desarrolladas son independientes del gestor de base de datos que se

utilice (Oracle, SQLServer, MySQL, etc.) En la implantación definitiva se utiliza un

servidor Solaris con SQL, por lo que e necesario habilitar el nombre del servidor, el

nombre de la base de datos…

Sin embargo, para preservar la información del servidor durante las pruebas y en el

desarrollo del proyecto, se he seleccionado el driver de Access para el acceso local en

modo de pruebas.


247

Para definir el vínculo con Access hay que indicar el nombre del DNS, el directorio en

el cual se encuentra ubicada la base de datos con la que se quiere trabajar y se confirma

pulsando sobre el botón de “aceptar”.

Las bases de datos necesarias para llevar a cabo la gestión de visitas son dos: card y

card_personal. Por ello, se tendrán que crear dos orígenes de datos, mientras que en

Control de Visitas sólo hay que definir la base de datos de equipos.

SISTEMAS DE CONTROL DE ACCESOS A EDIFICIOS ...desarrollar dos tecnologías de control de acceso,...

Documents

Transcript of SISTEMAS DE CONTROL DE ACCESOS A EDIFICIOS ...desarrollar dos tecnologías de control de acceso,...