Proyecto fin de carrera
1
Autorizada la entrega del proyecto del alumno/a:
Alberto Carrasco Sánchez
EL DIRECTOR DEL PROYECTO
Álvaro Sánchez Miralles
Fdo.: …………………… Fecha: ……/ ……/ ……
Vº Bº del Coordinador de Proyectos
David Contreras Bárcena
Fdo.: …………………… Fecha: ……/ ……/ ……
Sistema de automatización y control DOM
2
PROYECTO FIN DE CARRERA
SISTEMA DE AUTOMATIZCIÓN Y
CONTROL DOM
AUTOR: ALBERTO CARRASCO SÁNCHEZ
MADRID, SEPTIEMBRE 2007
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Proyecto fin de carrera
3
RESUMEN
El proyecto Sistema de automatización y control DOM es un proyecto que
diseña e implementa el software de gestión de un sistema domótico/inmótico. El
Sistema de automatización y control DOM fue inicialmente concebido para colaborar
en paralelo con otro sistema compuesto por una red de sensores y actuadores
coordinados desde un servidor central por medio de un sistema de radio. Mientras los
sensores toman medidas de distintas magnitudes relacionadas con el entorno del
inmueble como son la temperatura, la luminosidad o el movimiento, los actuadores
controlan el comportamiento de diferentes dispositivos electrónicos (motores o
interruptores) integrados en multitud de elementos del propio inmueble (persianas,
puertas, llaves de encendido de luz, agua, calefacción, electrodomésticos…)
Por tanto, la función principal del Sistema de automatización y control DOM es
la de proporcionar un interfaz al usuario que le permita tanto monitorizar la información
procedente del sistema domótico/inmótico como controlar la forma de actuar del
mismo. Para ello el Sistema de automatización y control DOM se sustenta sobre una
arquitectura de aplicación web de componentes, que permite el acceso al servicio a
multitud de usuarios que únicamente necesitan disponer de un navegador web en sus
PCs.
La principal motivación en que se ha apoyado la ejecución del proyecto no ha
sido otra que la pretensión de obtener un sistema domótico/inmótico que empleara
Internet y tecnologías afines para desarrollar un sistema de gestión para el mismo. La
utilización de estas tecnologías permite eliminar barreras geográficas y temporales que
limitan en muchas ocasiones a esta clase de sistemas, simplificando el acceso a los
mismos y extendiendo su utilización a un número mayor de usuarios.
En cuanto a la metodología utilizada dos han sido los principales paradigmas
empleados en el desarrollo del Sistema: metodología lineal y metodología evolutiva. La
primera ha sido especialmente importante en las tareas de identificación de necesidades
Sistema de automatización y control DOM
4
y toma de requisitos, ya que estás han sido identificadas desde un primer momento sin
sufrir apenas modificaciones. En el caso de la metodología evolutiva, ésta ha jugado un
papel esencial en el diseño de los componentes software y de las estructuras de datos,
ya que a un diseño inicial le han seguido una serie de evoluciones que han ido
perfeccionando dicho diseño hasta permitir la obtención del Sistema final. En este
proceso de diseño ha jugado también un papel esencial el Lenguaje de Modelado
Unificado (UML) que ha permitido obtener un diseño software ajustado a las
necesidades y requisitos especificados para el sistema inicialmente.
Como resultado de todo este proceso se ha obtenido un sistema
domótico/inmótico que permite monitorizar y controlar de forma remota diferentes
aspectos relacionados con un inmueble, empleando para ello las numerosas ventajas que
ofrece Internet, así como otras nuevas tecnologías (applet, servlet, XML, HTTP,
aplicaciones web…).
Finalmente, a modo de conclusión, se podría destacar la gran originalidad y el
carácter innovador de un proyecto plenamente funcional que tiene un marcado carácter
universitario, mas que comercial. Sin embargo, en contraste con este primer análisis,
también sería de justicia comentar que la actual infraestructura de Internet y el modo de
en que funcionan las nuevas tecnologías no ofrecen suficientes garantías para la
implementación un sistema de tiempo real. Un sistema de tiempo real normalmente esta
sujeto a una serie de fortísimas restricciones que no pueden tolerar la pérdida del
servicio por un fallo en el sistema de comunicación o por no tener instalada una versión
determinada de un software. Tendrá que pasar mucho tiempo hasta que sea posible
desarrollar un sistema comercial de este tipo que ofrezca las suficientes garantías en lo
que a tiempo de respuesta, disponibilidad, fiabilidad, mantenibilidad y seguridad
respecta.
Proyecto fin de carrera
5
INDICE
i. INTRODUCCIÓN 8
1. IDENTIFICACIÓN DE NECESIDADES 10
1.1 DOCUMENTO DE CONCEPTOS DEL SISTEMA
1.1.1 Objetivos del Sistema 12
1.1.2 Alcance del Sistema 13
1.1.3 Tipología de usuarios finales 14
1.1.4 Restricciones del Sistema 15
2. ANÁLISIS DE REQUISITOS 16
2.1 RECONOCIMIENTO DEL PROBLEMA
2.1.1 Ámbito del proyecto 18
2.1.2 Contexto del Sistema 19
2.2 LISTA DE REQUISITOS 22
3. SOLUCIÓN PROPUESTA 38
3.1 DISEÑO DEL SISTEMA 39
3.1.1 Arquitectura 40
3.1.2 Necesidades hardware 42
3.1.3 Necesidades software 42
3.1.4 Necesidades de comunicación 43
3.2 DISEÑO DE COMPONENTES 44
3.2.1 CLIENTE
3.2.1.1 Funciones propias 45
3.2.1.2 DISEÑO INTERNO
3.2.1.2.1 Diagrama de caso de uso 47
3.2.1.2.2 Diagramas de clases 50
3.2.1.2.3 Diagramas de secuencia 62
Sistema de automatización y control DOM
6
3.2.2 SERVIDOR
3.2.2.1 Funciones propias 64
3.2.2.2 DISEÑO INTERNO
3.2.2.2.1 Diagramas de clases 66
3.2.2.2.2 Diagramas de secuencia 75
3.2.2.2.3 Diagramas de colaboración 90
3.2.2.3 Comportamiento del Servidor 95
3.3 COMUNICACIÓN CLIENTE-SERVIDOR 101
3.4 MODELO DE DATOS 104
3.4.1 Protocolo de control DOM 1.0 105
3.4.2 Archivo config.xml 109
3.4.3 Archivo historico.xml 113
3.4.4 Archivo actualizacion.xml 114
3.4.5 Archivo contraseña.txt 117
3.4.6 Archivo log.txt 117
4. RESULTADOS 118
4.1 CASOS DE USO
4.1.1 Inicio de sesión en el Sistema 119
4.1.2 Recopilación periódica de datos de los sensores 121
4.1.3 Control del comportamiento de los actuadores 122
4.2 Secuencia intercambio de mensajes del protocolo de control DOM 124
5. CONCLUSIONES 129
5.1 Conclusiones finales 130
6. FUTUROS DESARROLLOS 132
6.1 Futuros desarrollos 133
ANEXO A 134
ANEXO B 147
ANEXO C 159
Sistema de automatización y control DOM
8
INTRODUCCIÓN
El gran avance producido en las últimas dos décadas en los ámbitos de la
informática, la electrónica y las telecomunicaciones ha propiciado la aparición, y en
muchos otros casos la consolidación, de tecnologías que han contribuido a mejorar la
calidad de vida de las personas. Éste ha sido el caso de la domótica y la inmótica, dos
de los campos que mayor crecimiento han experimentado en los últimos tiempos.
Tradicionalmente, tanto la domótica como la inmótica, se han desarrollado
partiendo de la electrónica y de las telecomunicaciones, relegando a un segundo plano a
la informática. Sin embargo, con la democratización de esta última, influenciada de
manera decisiva por el abaratamiento del PC y la aparición de Internet, esta situación se
ha revertido traduciéndose en un notable aumento de la importancia de la informática en
ambos campos.
El proyecto de fin de carrera “Sistema de automatización y control DOM” se ha
beneficiado precisamente de esta colaboración entre ciencias para obtener el diseño y la
implementación de un sistema de automatización y control ‘soft’ de tiempo real. Sin
embargo, aunque la presencia de la electrónica y de las telecomunicaciones en el
contexto del proyecto es incuestionable, ha correspondido a la informática desempeñar
el papel central en el proceso de elaboración del Sistema, llegando a actuar en ocasiones
como un elemento de cohesión entre las citadas ciencias.
Muchos han sido los sistemas domótico/inmóticos diseñados e implementados a
lo largo del tiempo, sin embargo muy pocos o ninguno han sabido aprovechar las
excelentes oportunidades que brinda Internet como red de interconexión global.
Contrariamente a esta tendencia, el proyecto “Sistema de automatización y control
DOM” ha utilizado Internet como plataforma de integración entre los diferentes
componentes del sistema domótico/inmótico. De esta manera, el Sistema ha pasado a
beneficiarse, automáticamente, de todas y cada una de las ventajas que ofrece Internet
por el mero hecho de utilizar la Red como plataforma de comunicación.
Proyecto fin de carrera
9
La posibilidad de unir sistemas heterogéneos mediante la utilización de
protocolos ampliamente extendidos, la oportunidad de escalar los sistemas de forma
ágil y eficiente, la transparencia con que se opera (acceso, ubicación, concurrencia,
replicación, fallo, movilidad y rendimiento) o la tolerancia a fallos que ofrece son
algunas de las características de las que se ha apropiado el Sistema. Sin embargo, no
todo han sido beneficios derivados de la utilización de Internet como sistema de
interconexión. Algunos inconvenientes han sido también heredados por el Sistema
motivo de esa utilización premeditada de la Red.
De cualquier manera, y dado que el Sistema originalmente fue concebido con
fines académicos y nunca comerciales, se debe entender el mismo como un intento de
innovación dentro de los ámbitos de la domótica/inmótica. De ahí que finalmente haya
primado la eficiencia en el funcionamiento del Sistema por encima de algunas otras
cuestiones.
Proyecto fin de carrera
11
El objetivo de esta etapa es exponer el entorno global del problema en estudio
especificando:
• Objetivos del Sistema
• Alcance del Sistema
• Tipología de usuarios finales
• Restricciones
Sistema de automatización y control DOM
12
1.1 DOCUMENTO DE CONCEPTOS DEL SISTEMA
1.1.1 Objetivos del Sistema
Se ha desarrollado un pequeño sistema de automatización y control capaz de
monitorizar la información recogida por unos sensores integrados en el Sistema, así
como de controlar el comportamiento de unos actuadores, también integrados en dicho
Sistema. El ámbito principal de aplicabilidad del Sistema será la automatización del
hogar (domótica) así como la automatización de los edificios (inmótica).
La funcionalidad principal del Sistema será, por tanto, gestionar remotamente
los dispositivos electrónicos que integran el sistema de automatización y control
desarrollado con los objetivos de:
• Recuperar y monitorizar información relacionada con magnitudes de medida
propias del entorno en el que está ubicado el inmueble como son la temperatura,
la luminosidad o la detección de movimiento.
• Permitir la gestión y el control remotos de los actuadores instalados en el
inmueble de forma eficiente y segura.
• Poner a disposición del usuario un software de gestión del Sistema fácil de
utilizar y mantener.
• Permitir registrar las acciones realizadas por el usuario, así como las respuestas
del Sistema a las mismas.
• Permitir la utilización del Sistema solamente a aquellos usuarios que tengan la
pertinente autorización.
Proyecto fin de carrera
13
1.1.2 Alcance del Sistema
La construcción del Sistema implica las funciones que se determinan a
continuación:
Monitorización de la información recogida por los sensores
Tiene como objetivo la recepción periódica de la información más actualizada
recogida por los sensores del Sistema. Además, esta información deberá ser tratada en
el lado del cliente de forma que se pueda obtener una representación gráfica que pueda
ser interpretada por usuario del Sistema.
Control del comportamiento de los actuadores
Con esta función se pretende dotar al Sistema de la capacidad para gestionar y
controlar de forma remota el funcionamiento de los actuadores del Sistema. Al igual
que con la monitorización de la información recogida por los sensores, la aplicación
cliente ofrecerá un interfaz gráfico que permitirá gestionar los actuadores de forma
sencilla y eficiente.
Representación jerarquizada de la disposición física del propio Sistema.
Tiene como objetivo ofrecer una representación perfectamente interpretable por
el usuario, que permita conocer como está dispuesto el Sistema de forma física, es decir,
qué sensores y qué actuadores están en qué habitaciones, y cómo están esas
habitaciones distribuidas por el inmueble. Además, cualquier modificación que sea
realizada tanto en la ubicación de los dispositivos como en la forma en la que está
estructurado el propio inmueble, deberá ser transmitida de forma fiable al usuario, lo
que le permitirá gestionar el nuevo espacio. Por tanto, la aplicación cliente deberá ser lo
suficientemente flexible como para representar estas modificaciones sin necesidad de
tener que rehacer el código cuando surjan los citados cambios. Para la implementación
de esta funcionalidad se ha empleado el archivo config.xml que almacena una
representación en formato XML de la forma como están distribuidos los sensores y los
Sistema de automatización y control DOM
14
actuadores por el inmueble, así como las habitaciones que estructuran el mismo. La
jerarquía que representa esta distribución se ha denominado jerarquía de disposición.
Gestión de acceso al Sistema de automatización y control
Esta funcionalidad restringe la utilización del Sistema solamente a aquellos
usuarios que hayan sido registrados previamente en el Sistema. Para que un usuario
tenga autorización para utilizar el Sistema será necesario crear una dupla formada por
un identificador de usuario y una contraseña en el archivo contraseña.txt. Este archivo
es interrogado cada vez que un usuario quiere iniciar sesión en el Sistema, de forma que
solamente aquellos usuarios que conozcan una de las duplas creadas en el fichero
tendrán la oportunidad de usar el Sistema.
1.1.3 Tipología de usuarios finales
Los usuarios que utilizarán el Sistema dependerán del lugar donde éste sea
instalado. Cuando el Sistema sea instalado en una casa particular, normalmente los
usuarios del mismo serán los propietarios. Pero, si por el contrario, el inmueble donde
es instalado el Sistema es un edificio, ya sea una empresa, un hospital o un aeropuerto,
los usuarios del Sistema serán la/las persona/as encargadas del mantenimiento de dichas
instalaciones.
El segundo caso, es el escenario ideal para el que ha sido desarrollado el
Sistema. Tener la posibilidad de gestionar de forma centralizada el conjunto de
dispositivos electrónicos en inmuebles de grandes dimensiones es una tarea que, si no
está automatizada, puede requerir mucho tiempo, esfuerzo y dinero.
Por otra parte, se podría destacar una segunda figura de usuario. El Sistema,
como muchos otros, necesita de un cierto mantenimiento, tanto para la instalación de
nuevos dispositivos como para la modificación del archivo de configuración o
supervisión del archivo de log. Mientras que en el caso de la casa particular, sería la
empresa instaladora la encargada de realizar tal labor, en el caso del inmueble de
Proyecto fin de carrera
15
grandes dimensiones sería el propio servicio de mantenimiento el encargado de realizar
dichas labores.
1.1.4 Restricciones del Sistema
Los sistemas de tiempo real deben ajustarse a una serie de restricciones que
permiten obtener un producto final que se acerca al modelo que inicialmente fue
concebido. Existen dos grandes grupos que engloban todas las restricciones posibles:
funcionales y no funcionales.
Las restricciones funcionales son aquellas que están estrechamente relacionadas
con el modo en que funciona el Sistema, es decir, determinan el comportamiento del
mismo. Restricciones de tipo funcional son: restricciones causales, restricciones
temporales y restricciones matemático-lógicas. Las primeras son aquellas que dotan al
Sistema de un comportamiento causa-efecto. Las restricciones de tipo temporal limitan
el intervalo de tiempo en que debe producirse el resultado, es decir, no sólo es
importante dar un resultado correcto sino que además dicho resultado debe generarse en
un tiempo predeterminado. Y, finalmente, las restricciones de tipo matemático-lógico
que determinan criterios de tipo matemático para obtener determinados resultados.
Por otra parte, en el grupo de restricciones no funcionales, se pueden encontrar
el resto de las restricciones necesarias que no han sido mencionadas tales como los
plazos de entrega, el presupuesto económico, los estándares a emplear, el volumen de
recursos disponibles…Determinan, por tanto, aspectos mas a nivel de gestión del
proyecto en el que queda enmarcado el Sistema.
De lo expresado anteriormente se puede deducir, en lo que ha restricciones de
carácter funcional respecta, que se han tenido en cuenta tanto las causales como las
temporales. Las primeras porque el Protocolo de control DOM 1.0 emplea una serie de
transiciones para pasar de unos estados como se detalla en el Anexo A. En lo que a
restricciones temporales se refiere, se tienen que respetar los tiempos mínimos
establecidos para la propagación de los datos actualizados desde los sensores y
actuadores a los clientes.
Proyecto fin de carrera
17
El objetivo de la etapa de análisis de requisitos, es alcanzar un conocimiento
suficiente del Sistema, definiendo las necesidades, problemas y requisitos del usuario,
para expresarlos mediante la elaboración de los siguientes documentos:
• Evaluación y síntesis
• Lista de requisitos
• Modelo conceptual de datos
Sistema de automatización y control DOM
18
2.1 RECONOCIMIENTO DEL PROBLEMA
El objetivo primordial de un buen análisis es reconocer los elementos básicos
del Sistema tal y como los percibe el usuario. Para ello se parte de una especificación,
recogida en el Documento de Conceptos del Sistema, y del Plan de Proyecto. De este
modo se comprende el contexto del Sistema.
2.1.1 Ámbito del proyecto
Desde un punto de vista más técnico, las funciones del Sistema que se van a
mecanizar son las siguientes:
• Transmisión desde el servidor a los clientes de los datos recogidos por los
sensores del Sistema.
• Representación gráfica de la información recupera desde los sensores.
• Transmisión desde los clientes al servidor de los nuevos parámetros de control
de los actuadores del Sistema.
• Representación gráfica del estado de los actuadores, así como de los nuevos
parámetros de control que se van a enviar a los mismos.
• Registro en un archivo de log de todas las operaciones realizadas en el Sistema,
así como todas las respuestas del propio Sistema a éstas.
• Gestión del control del acceso al servicio.
• Representación gráfica de la forma como están dispuestos los dispositivos en el
inmueble, así como la organización de las habitaciones en el mismo.
Proyecto fin de carrera
19
2.1.2 Contexto del Sistema
MOVIMIENTO LUMINOSIDAD
Internet/Intranet
RF
CLIENTE
SERVIDOR
ACTUADORES TEMPERATURA
Sistema de automatización y control DOM
20
DIAGRAMA DE PRESENTACIÓN: Sensores
Los sensores son los dispositivos encargados de reportar información hacia el servidor.
Existen diferentes tipos de sensores según las magnitudes de medición que se quieran
reportar (temperatura, movimiento, luminosidad…)
DIAGRAMA DE PRESENTACIÓN: Actuadores
Estos dispositivos son los encargados de ejecutar sobre elementos del inmueble las
acciones tomadas por el usuario del Sistema. Al igual que los sensores, también
reportan información relacionada con el estado en que se encuentran. Dicha
información es de utilidad a otros usuarios para saber si dichos actuadores ya están
realizando la tarea que se quiere tomar sobre ellos.
DIAGRAMA DE PRESENTACIÓN: Sistema de radiofrecuencia
Este sistema permite la comunicación entre los módulos donde se encuentran los
sensores y los actuadores y el servidor central. Este servidor cuenta con una antena de
radiofrecuencia que le permite acceder al medio. El intercambio de información entre
dispositivos electrónicos y servidor se realiza mediante este sistema de comunicación.
DIAGRAMA DE PRESENTACIÓN: Servidor
El servidor es el nodo que recibe la información de los sensores y actuadores vía
radiofrecuencia, distribuyéndola posteriormente de forma periódica a los clientes.
Además, recibe las solicitudes de ejecución de acciones por parte de estos últimos para
ser enviadas a los actuadores.
DIAGRAMA DE PRESENTACIÓN: Cliente
El cliente es el nodo consumidor de la información recogida por los sensores y
actuadores. Además, selecciona las acciones a tomar empleando para ello el interfaz de
usuario disponible en el cliente.
Proyecto fin de carrera
21
DIAGRAMA DE PRESENTACIÓN: Red de comunicación
Esta red de comunicación tiene la misma función que la red de radiofrecuencia vista
anteriormente, solo que en este caso permite la comunicación entre los nodos servidor
y cliente. La red de comunicación puede ser cualquier red Ethernet que implemente el
protocolo TCP/IP tales como la red pública global (Internet) o cualquier otra red
privada (intranet).
Sistema de automatización y control DOM
22
2.2 LISTA DE REQUISITOS
La lista de requisitos es una relación de los requisitos que son necesarios para el
apropiado desarrollo del Sistema. En cada ficha, aparte de otros datos relevantes como
versión, el título o el código de requisito, se recoge la naturaleza propia del requisito.
Atendiendo a dicha naturaleza, los requisitos pueden ser:
• Funcional. Atiende a las características propias del funcionamiento del Sistema.
• Operativo. Atiende al modo en que funcionará el Sistema.
• De prestación. Atiende a las características adicionales o de menor prioridad.
• De seguridad. Atiende al control del acceso al Sistema y la privacidad.
• De fiabilidad. Atiende a la integridad y veracidad de la información.
Proyecto fin de carrera
23
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 29/03/2007
TIPO REQUISITO: Funcional IDENTIFICACIÓN: R01
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 1 de 15
TITULO: Desarrollo del Sistema de automatización y control DOM.
DESCRIPCIÓN: Se pretende desarrollar un sistema de automatización y control capaz
de recuperar información de los sensores así como controlar el comportamiento de los
actuadotes que integran el Sistema.
BENEFICIOS: Este sistema permitirá gestionar de forma remota y descentralizada el
conjunto de actuadotes que forman parte del Sistema, utilizando para ello la
información reportada por los sensores.
COMENTARIOS/SOLUCIONES SUGERIDAS
El Sistema se compondrá de una serie de módulos distribuidos por diversas
dependencias del inmueble. Cada uno de estos módulos estará compuesto de una serie
de sensores y actuadotes, hasta un máximo de catorce por módulo. Mientras los
primeros reportan información relativa a variables relacionadas con el inmueble como
la temperatura, la luminosidad o el movimiento), los segundos permiten manipular de
forma remota diversos elementos del inmueble como motores o interruptores.
Cada uno de los módulos que integran el Sistema se comunicará por radiofrecuencia
con un servidor central encargado de enviar y recibir datos a y desde las estaciones
clientes.
DOCUMENTOS RELACIONADOS
Contexto del Sistema
REQUISITOS RELACIONADOS
Sistema de automatización y control DOM
24
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 29/03/2007
TIPO REQUISITO: Operativo IDENTIFICACIÓN: R02
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 2 de 15
TITULO: Utilización de una red Ethernet/IP como red de comunicación.
DESCRIPCIÓN: Se utilizará una combinación Ehernet e IP como capas de
comunicación fisica y lógica.
BENEFICIOS: La utilización de dicha topología de red posibilitará el acceso a la
aplicación desde cualquier PC conectado a Internet.
COMENTARIOS/SOLUCIONES SUGERIDAS
Debido a ciertas limitaciones de seguridad, que afectan a la forma en la cual los datos
son transmitidos entre nodos o al carácter público de Internet, se está estudiando la
posibilidad de cifrar la información transmitida entre dichos nodos. Se pretende evitar
así que las instrucciones enviadas entre nodos sean leídas o incluso modificadas, lo que
podría suponer una grave amenaza para inmueble en cuestión.
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Proyecto fin de carrera
25
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 29/03/2007
TIPO REQUISITO: Operativo IDENTIFICACIÓN: R03
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 3 de 15
TITULO: Diseño e implementación del protocolo de control DOM 1.0.
DESCRIPCIÓN: Se diseñará e implementará un protocolo de control, llamado DOM
1.0, que hará posible el intercambio de instrucciones entre las estaciones clientes y el
servidor central.
BENEFICIOS: Este protocolo permitirá el intercambio de instrucciones entre nodos
remotos de forma eficiente y fiable.
COMENTARIOS/SOLUCIONES SUGERIDAS
La novedad más relevante que presenta el sistema en desarrollo, frente a los sistemas
domóticos/inmóticos existentes, es la utilización del lenguaje de programación
orientado a objetos Java, el lenguaje de marcas XML y el protocolo de hipertexto
HTTP para la implementación de la lógica, la codificación y el transporte del protocolo
de control en desarrollo.
La elección de Java esta motivada por la modularidad que ofrece el lenguaje para
codificar la lógica del protocolo, así como por el carácter multiplataforma del mismo.
Además, se ha optado por emplear el lenguaje de marcas XML, para la codificación de
las instrucciones, por tratarse de un formato de intercambio de datos independiente de
la plataforma. Finalmente, la utilización del protocolo HTTP pone a disposición del
Sistema todos los mecanismos de control (TCP), direccionamiento (IP) y gestión de
errores (checksum, flags…) existentes en HTTP para garantizar que la información
enviada desde un nodo es recibida por el nodo destino de forma adecuada.
DOCUMENTOS RELACIONADOS
Contexto del Sistema
REQUISITOS RELACIONADOS
R04
Sistema de automatización y control DOM
26
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 29/03/2007
TIPO REQUISITO: Operativo IDENTIFICACIÓN: R03
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 4 de 15
TITULO: Utilización de un protocolo de tipo RRA en la implementación del protocolo
de control.
DESCRIPCIÓN: Según el número de mensajes intercambiados existen tres tipos
distintos de protocolos: R, RR y RRA. En nuestro caso, para la implementación del
Protocolo de control DOM 1.0, se ha utilizado la tipología RRA: request, reply,
acknowledge reply. Este protocolo utiliza tres tipos diferentes de mensajes. El primero
de estos mensajes es el de request, que inicia el proceso de comunicación entre nodos.
Como su propio nombre indica es una solicitud. El segundo de los mensajes es el de
reply, que proporciona una respuesta al nodo que originalmente envió el mensaje de
request, además de confirmar la recepción de dicho mensaje por parte del interlocutor.
Finalmente, el tercer tipo de mensaje es el de acknowledgereply, que verifica la
recepción del mensaje reply por parte del nodo que inició la comunicación, es decir, el
nodo que originalmente envió el mensaje de request.
Por tanto, es posible apreciar que este tipo de protocolos realiza dos confirmaciones de
información recibida. Esto puede ocasionar una mayor sobrecarga tanto en los sistemas
origen y destino como en el canal de comunicación, pero ofrece un nivel de seguridad
bastante mayor.
BENEFICIOS: Permite obtener un mayor entendimiento entre los nodos que participan
en una comunicación.
COMENTARIOS/SOLUCIONES SUGERIDAS
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Proyecto fin de carrera
27
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 31/03/2007
TIPO REQUISITO: Operativo IDENTIFICACIÓN: R04
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 5 de 15
TITULO: Utilización de una arquitectura de aplicación de componentes de
navegador/servidor.
DESCRIPCIÓN: La arquitectura de aplicación de componentes de navegador/servidor
se utilizará para distribuir los componentes de la aplicación entre el cliente y el
servidor.
BENEFICIOS: Los principales beneficios que se derivan de la utilización de una
arquitectura de aplicaciones Web son:
� Independencia del entorno tecnológico
� Diseño de la parte servidora de la aplicación independiente de la parte cliente
� Simplificación de los procesos de distribución y mantenimiento del software de
aplicación
COMENTARIOS/SOLUCIONES SUGERIDAS
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
R05 y R06
Sistema de automatización y control DOM
28
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 31/03/2007
TIPO REQUISITO: Operativo IDENTIFICACIÓN: R05
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 6 de 15
TITULO: Diseño y desarrollo del software de servidor.
DESCRIPCIÓN: Se deberá diseñar y desarrollar un software de servidor capaz de
utilizar el protocolo de control DOM 1.0 para el intercambio de información con los
nodos clientes.
BENEFICIOS:
COMENTARIOS/SOLUCIONES SUGERIDAS
Dado que el protocolo HTTP va a ser el protocolo subyacente a DOM 1.0, parece
lógico emplear la tecnología J2EE Servlet. Esta tecnología implementa por defecto el
tratamiento de peticiones y respuestas HTTP.
El servidor de aplicaciones utilizado para gestionar los recursos requeridos por el
Servlet será Apache Tomcat 5.5.15 que implementa el contenedor JSERV para Apache
Web Server.
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Proyecto fin de carrera
29
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 31/03/2007
TIPO REQUISITO: Operativo IDENTIFICACIÓN: R06
VERSIÓN: 1.0 PRIORIDAD: Alta VERSIÓN: 1.0 Pág: 7 de 15
TITULO: Diseño y desarrollo del software de cliente.
DESCRIPCIÓN: Se deberá diseñar y desarrollar un software cliente capaz de
representar de forma jerárquica como están distribuidos los dispositivos en el
inmueble, así como representar gráficamente tanto la información recuperada de los
sensores como el comportamiento de los actuadotes.
Otras características que deberá poseer el software cliente desarrollado son: facilidad
de uso y mantenimiento, alta disponibilidad y fiabilidad, así como proveer un
mecanismo de control de acceso al Sistema.
BENEFICIOS: La utilización de la tecnología Java Applet permite la utilización de
clientes ligeros en el contexto de la aplicación. Los applets dotan a las aplicaciones de
funcionalidad en el lado de los clientes sin sacrificar la seguridad de los mismos.
Quizá, como única pega se pudiera destacar el bajo rendimiento que ofrecen en
ocasiones los applets demasiado complejos, así como la necesidad de contar con la
máquina virtual de java (JVM) integrada en el navegador de los clientes.
COMENTARIOS/SOLUCIONES SUGERIDAS
Tratando de satisfacer todas las características recogidas en el requisito R06, se va a
desarrollar un software cliente capaz de ser gestionado desde un cliente ligero, es decir,
un cliente que únicamente utilice un navegador web. Será, por tanto, la tecnología
J2SE Applet la encargada de proveer los niveles de gestión, mantenimiento,
disponibilidad, fiabilidad y seguridad requeridos.
Será necesaria la instalación en los clientes del software Java Virtual Machina (JVM)
versión 1.4.2_10-b03 o superior.
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Sistema de automatización y control DOM
30
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 31/03/2007
TIPO REQUISITO: Operativo IDENTIFICACIÓN: R07
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 8 de 15
TITULO: Diseño e implementación de un espacio de memoria compartida.
DESCRIPCIÓN: Será necesario diseñar e implementar un espacio de memoria
compartida que permita la transmisión de datos entre el Sistema de automatización y
control DOM y el Sistema ¿?.
En lo que al Sistema de automatización y control DOM se refiere, dicho espacio será
utilizado para leer los datos más actualizados procedentes de los sensores,
proporcionados por el otro sistema, así como para escribir las últimas modificaciones
que deberán ser ejecutadas sobre los actuadores, consumidas por el otro sistema.
BENEFICIOS: Implementar un espacio de memoria compartida, que pueda ser
utilizado por dos sistemas independientes para comunicarse, ofrece la ventaja de que
dicho espacio puede tener ya implementado un mecanismo de sincronización entre
procesos que impida el solapamiento de las actividades de los mismos.
COMENTARIOS/SOLUCIONES SUGERIDAS
La solución propuesta para hacer efectivo el cumplimiento de este requisito será la
utilización de archivos XML como soporte para el almacenamiento de datos que
deberán ser pasados entre sistemas.
Mientras el archivo historico.xml será de donde se lean los últimos datos recogidos por
los sensores, el archivo acualización.xml será donde se escriban la últimas comandos
que deberán ser enviados a los actuadores.
Debido a que estos recursos serán utilizados de forma simultanea por dos sistemas
independientes que actúan de forma independiente, será el propio sistema de archivos
del Sistema Operativo el encargado de gestionar los bloqueos sobre los recursos a fin
de mantener la integridad de los datos.
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Proyecto fin de carrera
31
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 02/04/2007
TIPO REQUISITO: Prestación IDENTIFICACIÓN: R08
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 9 de 15
TITULO: Flexibilidad del software de control para reflejar las cambios producidos en
el modelo físico.
DESCRIPCIÓN: El software que monitoriza y controla los sensores y los actuadotes
deberá ser capaz de reflejar cualquier cambio o adición que pueda ser realizado en el
sistema de dispositivos electrónicos instalado en el inmueble, siempre y cuando estas
modificaciones se ajusten al modelo acordado.
BENEFICIOS: De esta manera, cualquier cambio que se realice con respecto al
sistema físico original tendrá reflejo en el software de control.
COMENTARIOS/SOLUCIONES SUGERIDAS
El Lenguaje de Marcas Extensible XML es el principal artífice de la flexibilidad con la
que cuenta el Sistema. En el servidor web/aplicación existe un archivo config.xml que
almacena una representación xml del sistema físico. Cuando se realiza alguna
modificación en el dicho sistema, que está integrado por los sensores/actuadores y la
forma en que éstos se disponen en el inmueble, automáticamente se edita dicho archivo
para dejar constancia de las modificaciones realizadas en el modelo real. Así, y gracias
también al proceso de parseado que se realiza en el cliente, se puede enviar el archivo
de configuración con la información más actualizada del Sistema para que el software
cliente pueda representarlo de forma apropiada.
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Sistema de automatización y control DOM
32
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 02/04/2007
TIPO REQUISITO: Operativo IDENTIFICACIÓN: R09
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 10 de 15
TITULO: Control del estado de la sesión en el protocolo DOM 1.0
DESCRIPCIÓN: Como se ha comentado anteriormente, el protocolo DOM 1.0 utiliza
las múltiples funcionalidades que HTTP pone a su disposición como protocolo
subyacente. Sin embargo, todas aquellas funcionalidades requeridas por DOM 1.0 que
no son soportadas por el protocolo HTTP deberán ser implementadas por el primero.
Este es el caso del control del estado de la sesión en DOM 1.0.
Como es conocido, HTTP es un protocolo del tipo ‘Request/Reply’ que no realiza
ningún tipo de control sobre el estado de la sesión. De esta forma, dada esta limitación,
será necesario implementar el control del estado de la sesión en DOM 1.0.
BENEFICIOS: Normalmente, los protocolos que ofrecen control del estado de la
sesión son aquellos que tienen un nivel de complejidad mayor que los del tipo
‘Request/Reply’, grupo al que pertenece HTTP. Este es el caso de DOM 1.0, que
además de ser un protocolo de tipo Request/Reply/AcknowledgeReply’, tiene un juego
de instrucción bastante mas amplio que HTTP. Éste, precisamente, es el mayor
beneficio que aporta el dotar a un protocolo de control del estado de la sesión; permitir
desarrollar protocolos con multitud de estados que tienen la posibilidad de realizar un
mayor número de operaciones.
COMENTARIOS/SOLUCIONES SUGERIDAS
La solución que se propone implementar para dotar al protocolo DOM 1.0 de control
del estado de la sesión es utilizar un sistema de cookies que permita identificar de
forma unívoca a cada nodo cliente en cada una de las sesiones en las que participa.
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Proyecto fin de carrera
33
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 02/04/2007
TIPO REQUISITO: Operativo IDENTIFICACIÓN: R10
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 11 de 15
TITULO: Obtención en tiempo real de los últimos valores recogidos por los sensores.
DESCRIPCIÓN: Una de las principales características de los sistemas de control y
automatización es la importancia del tiempo. En un sistema domótico/inmótico el
periodo de muestreo establecido para que los nodos clientes puedan recibir datos desde
los sensores debe ser el mayor que, sin penalizar el rendimiento del Sistema, pueda
proporcionar los datos mas actualizados.
BENEFICIOS: Un sistema de control que utiliza un periodo de muestreo apropiado es
capaz de llevar información desde el origen hasta el destino en un tiempo tal que dicha
información sigue teniendo valor para el Sistema cuando alcanza este último. De otra
forma, si el intervalo de tiempo transcurrido entre la toma del valor por parte del sensor
y la visualización del mismo en el cliente no fuera el adecuado, tanto por exceso como
por defecto, probablemente se estaría trabajando con datos que no se corresponden con
la realidad, pudiéndose derivar errores de ello.
COMENTARIOS/SOLUCIONES SUGERIDAS
El muestreo periódico de los valores recogidos por los sensores se realizará por medio
de un hilo de ejecución independiente del principal en los nodos clientes, que
interrogará a un servlet especialmente diseñado para responder a las continuas
peticiones de valores actuales de los sensores que realizan los clientes. Dicho servlet
proporcionará los datos más recientes almacenados en un fichero con nombre
historico.xml.
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Sistema de automatización y control DOM
34
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 06/04/2007
TIPO REQUISITO: Prestación IDENTIFICACIÓN: R11
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 12 de 15
TITULO: Transmisión de instrucciones de control (actualización) agrupadas por
módulos.
DESCRIPCIÓN: Este requisito está principalmente relacionado con la forma en que
son enviadas las instrucciones de control a los actuadores. En lugar de enviar de forma
individual cada modificación realizada sobre un actuador en la interfaz de usuario, se
procederá a agrupar y almacenar en estructuras de memoria el conjunto de
modificaciones realizadas para posteriormente ser enviadas de forma conjunta.
BENEFICIOS: El principal beneficio que se obtiene, una vez implementado este
requisito, es una reducción considerablemente del tráfico generado con motivo del
envío de instrucciones de control a los actuadores.
COMENTARIOS/SOLUCIONES SUGERIDAS
Mediante la utilización de estructuras residentes en memoria, la interfaz de usuario será
capaz de almacenar temporalmente las modificaciones realizadas por el usuario en los
actuadores, que a la postre se traducen en instrucciones de actualización, para ser
posteriormente enviadas de forma conjunta empleando una única instrucción.
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Proyecto fin de carrera
35
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 06/04/2007
TIPO REQUISITO: Seguridad IDENTIFICACIÓN: R12
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 13 de 15
TITULO: Gestión del control de acceso al Sistema
DESCRIPCIÓN: Debido a la naturaleza sensible de las acciones que se pueden realizar
con el Sistema, es aconsejable limitar el acceso al Sistema a aquellas personas que
tengan la pertinente autorización.
BENEFICIOS: Limitar el acceso al Sistema a un pequeño grupo de individuos reduce
notablemente los problemas que se puedan derivar de una utilización negligente o
accidental del Sistema.
COMENTARIOS/SOLUCIONES SUGERIDAS
El proceso de gestión del control de acceso comienza con el registro de los usuarios
autorizados para la utilización del Sistema en un archivo llamado contraseña.txt. En
dicho archivo se escribirá un registro, nombre de usuario y contraseña, por cada uno de
los usuarios autorizados a utilizar el Sistema. Posteriormente, cuando el usuario trate
de acceder éste será requerido para proporcionar la información de autenticación que le
ha sido asignada y que nadie más deberá conocer. Finalmente, si el nombre de usuario
y la contraseña proporcionados son correctos entonces obtendrá acceso al Sistema, de
lo contrario el usuario tendrá nuevamente una oportunidad para proporcionar los datos
de acceso correctos.
Este proceso se apoya en la utilización de la instrucción Conexión que soporta el
protocolo DOM 1.0
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Sistema de automatización y control DOM
36
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 06/04/2007
TIPO REQUISITO: Seguridad IDENTIFICACIÓN: R13
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 14 de 15
TITULO: Gestión del control de salida del Sistema
DESCRIPCIÓN: De la misma forma que se realiza una gestión del control de acceso al
Sistema, será necesario implementar una gestión de control de abandono del Sistema.
Se pretende evitar la salida accidental o intencionada del Sistema mientras se está
ejecutando una tarea delicada de monitorización de datos o control del comportamiento
de los dispositivos electrónicos.
BENEFICIOS: Repercute en un nivel de seguridad del Sistema aún mayor.
COMENTARIOS/SOLUCIONES SUGERIDAS
Se va a utilizar un procedimiento similar al empleado en la gestión del control de
acceso para gestionar la salida del Sistema. El usuario que quiera abandonar la
aplicación deberá proporcionar la contraseña que utilizó inicialmente para acceder al
Sistema. Si la contraseña es correcta se podrá abandonar el Sistema liberando en el
servidor todos los recursos utilizados hasta el momento por dicho usuario. En caso
contrario la petición de abandono será denegada continuando con normalidad cualquier
proceso que estuviera siendo ejecutado en ese momento.
Este proceso se apoya tanto en la utilización del archivo de texto plano contraseña.txt
como en la instrucción Desconexión que soporta el protocolo DOM 1.0 para tal fin.
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Proyecto fin de carrera
37
HOJA DE REQUISITOS
PROYECTO: Sistema de automatización y control DOM
AUTOR: Alberto Carrasco Sánchez FECHA: 06/04/2007
TIPO REQUISITO: Prestación IDENTIFICACIÓN: R14
VERSIÓN: 1.0 PRIORIDAD: Alta ESTADO: Aceptado Pág: 15 de 15
TITULO: Registro de la actividad del Sistema en una archivo de log
DESCRIPCIÓN: Se pretende registrar la actividad del Sistema en el archivo log.txt. En
este archivo, que estará ubicado en el servidor web/aplicación, quedará constancia de
todas las acciones realizadas por los usuarios. Por cada solicitud de ejecución de
instrucción serán escritos tres registros. El primero de ellos para la instrucción de
Request. El segundo para la instrucción de Reply, que confirma la recepción de la
primera instrucción. Y el tercero para la instrucción Acknowledgement-Reply, que
confirma la recepción de la confirmación. Además, en cada uno de los registros del
citado fichero se escribirá la hora y la fecha en la que se ejecutó la instrucción, el
usuario que la ejecuto, así como el resultado de la ejecución.
BENEFICIOS: En los sistemas de control y automatización es muy común la
utilización de los archivos de log para registrar la actividad de los mismos. La
existencia de los archivos de log permite detectar cualquier anomalía que pudiera
ocurrir en el Sistema para, posteriormente, corregirla.
COMENTARIOS/SOLUCIONES SUGERIDAS
DOCUMENTOS RELACIONADOS
REQUISITOS RELACIONADOS
Proyecto fin de carrera
39
3.1 DISEÑO DEL SISTEMA
El objetivo de esta etapa es la obtención del diseño del Sistema. Este diseño se
apoya en las necesidades y requisitos recogidos anteriormente de forma que sea posible
obtener un modelo aproximado de la realidad. Para la obtención del este modelo se van
a emplear herramientas tales como gráficos, diagramas, lenguajes especiales o tablas.
El diseño del Sistema abarca diferentes aspectos como son la arquitectura, el
diseño interno de los distintos componentes que integran el Sistema o el modelo de
datos físico que va a ser utilizado. En lo que a la arquitectura se refiere, se exponen las
razones que hacen de esta solución la más apropiada, al tiempo que se muestra un
gráfico que detalla en qué componentes se ubican los elementos que forman parte de
esta arquitectura. En el caso del diseño de los componentes del Sistema, éste ha sido
dividido en dos partes: cliente y servidor. En ambos casos se exponen que partes del
comportamiento global del Sistema se ubican en qué componentes. Además, se
proporcionan diversas representaciones UML de los subsistemas que se localizan en
estos componentes del Sistema. En último lugar se ofrece una visión detallada del
modelo de datos que va a ser implementado en el Sistema.
Sistema de automatización y control DOM
40
3.1.1 Arquitectura
La arquitectura de aplicación elegida para implantar el Sistema es una
arquitectura de componentes de navegador/servidor. Esta alternativa es una ampliación
de la arquitectura web tradicional. El motivo por el que se ha tomado esta decisión es
porque, si se desea construir una aplicación web en tres niveles: presentación, lógica y
acceso a datos, se requiere una arquitectura más compleja que la arquitectura web.
Mientras que los mecanismos de presentación se han desarrollado pensando en
el cliente, las lógicas de aplicación y datos son desarrolladas con el servidor en mente.
Es conveniente resaltar que, desde el inicio del proyecto, se ha tenido muy claro cual
iba a ser la tecnología de servidor sobre la que se iban a desarrolla los componente de
servidor para la implementación de las lógicas de aplicación y datos. Esta tecnología no
ha sido otra que los Java Servlets, que permiten, a través de la máquina virtual java
(JVM), ejecutar rutinas en base a unos flujos de entradas y salida. Los servlets
interactúan con los clientes web a través de un mecanismo implementado por un
contenedor de servlets, funcionalmente similar al empleado por los CGIs, pero con
mucho mayor rendimiento ya que no son sobrecargados con cada nueva petición que
realiza un cliente. En nuestro caso, el contenedor de servlet escogido ha sido el JSERV
de Apache Web Server.
Sin embargo, la parte cliente no estuvo ni mucho menos clara en un principio.
Desde el inicio, se ha tenido la intención de desarrollar una aplicación cliente potente a
la vez que ligera. Estas características han reducido el abanico de tecnologías
disponibles a tres: páginas html, Java Server Faces y Java Applets. Si bien el primero
fue descartado por ser demasiado limitado, el segundo lo fue por excesivamente
complejo, quedando solo como opción viable los java applets. La tecnología Java
Applet son rutinas cargadas por el web server en el cliente para ser ejecutadas por el
browser. Al ser código java, éste es independiente de la plataforma donde reside el
cliente, con las ventajas de seguridad que aporta. No obstante, los applets presentan
algunas limitaciones como son el pobre rendimiento que ofrecen y la carencia de
estructuras para construir algunos tipos de aplicación. Además, otro de los problemas
que surgen a la hora de utilizar la tecnología Java Applet es la versión del navegador a
utilizar, pues no todos utilizan la misma máquina virtual de java, por lo que es posible
Proyecto fin de carrera
41
que un mismo applet funcione sobre un navegador y no sobre otro. De cualquier forma,
y a pesar de estos aspectos negativos, la tecnología java applet ha sido elegida por ser la
única que proporciona en la actualidad capacidad de procesamiento en el lado del
cliente, de un modo mas o menos ‘inteligente’.
A continuación se muestra un gráfico a modo de esquema que pretende aclarar
los conceptos expuestos anteriormente:
En el gráfico superior se puede observar como se traslada del papel a la realidad
una arquitectura de componente de navegador/servidor. Por un lado, se puede apreciar
como un servidor web recibe las peticiones desde los clientes en formato Http,
devolviendo respuestas en el mismo formato. Entre medias, todo un proceso que puede
ir desde la elaboración de una salida en función de la entrada, hasta la realización de
cualquier clase de operación contra una estructura de datos (archivo, BBDD,
repositorio…).
En el otro lado del canal de comunicación, en este caso Internet, podemos
encontrar al cliente. Equipado con un navegador convencional provisto de la máquina
virtual de java (JVM), éste puede ejecutar código de forma segura respondiendo a la
CLIENTE
SISTEMA ARCHIVOS
IE EXPLORER
URL + parámetros
RED
APACHE TOMCAT
WEB SERVER
Respuesta HTML
JSERV
CONTENEDOR SERVLET
JAVA APPLET
SERVIDOR
Sistema de automatización y control DOM
42
información que le es enviada desde el servidor y a través del canal de comunicación.
La gran ventaja, como ya se ha comentado con anterioridad, a la hora de contar con la
tecnología Java Applet en el lado del cliente es que permite dotar a la aplicación cliente
de cierta lógica que de otra forma no sería posible, es decir, esta tecnología permite
tomar decisiones en función de que la información que llega desde el servidor sea una u
otra.
3.1.2 Necesidades hardware
1. Sistemas Operacionales: Son las máquinas donde residen los sistemas operativos.
Existen máquinas con los siguientes sistemas operativos:
• Windows 2000 Server: Este sistema operativo está instalado en el
servidor que da acceso al servicio. Dicha máquina estará conectada
directamente a la red ethernet de manera que pueda empezar a escuchar
peticiones de servicio al puerto 80.
• Los usuarios finales no necesitan instalar ningún software específico en
sus PCs. A través de su navegador web podrán tener acceso a la
aplicación cliente.
3.1.3 Necesidades software
1. Recepción de las peticiones http: Apache Tomcat Web Server es un software que
atiende solicitudes http. Además, este software lleva integrado un servidor de
aplicaciones que permite ejecutar código java en base a una entrada de datos. Dicho
software permitirá dotar al servidor de la lógica necesaria para atender a las peticiones
que le realicen los clientes en cada momento.
2. Gestión y control del Sistema: En el lado del cliente será necesaria la existencia de un
navegador web con la maquina virtual de java (JVM). La idea principal es que un applet
Proyecto fin de carrera
43
sea capaz de interpretar y monitorizar la información recibida desde el servidor, así
como seleccionar y enviar información de actualización al mismo.
3.1.4 Necesidades de comunicación
Los requerimientos para la comunicación en los nodos del Sistema son muy
básicos. Tanto en el caso del servidor como en el del cliente, ambas máquinas deben
disponer de una tarjeta de comunicación instalada y configurada adecuadamente, así
como de la correspondiente pila de protocolos TCP/IP también instalada. Además, se
deberá contar con un punto de conexión a una red que proporcionará la comunicación
entre los diferentes nodos que participan en el Sistema.
Precisamente, es la sencillez en las necesidades de comunicación la que dota al
Sistema de una gran flexibilidad, postulando a cualquier usuario que disponga de una
tarjeta de red y de una conexión a Internet/intranet como un usuario potencial del
Sistema.
Sistema de automatización y control DOM
44
3.2 DISEÑO DE COMPONENTES
En esta fase se identifican y diseñan los diversos componentes software del
Sistema, describiendo detalladamente sus especificaciones. Dependiendo de la
arquitectura elegida para el Sistema final, estos componentes pueden tener una
naturaleza muy diversa. Esta naturaleza permite dividir el sistema diseñado en pequeños
subsistemas, atendiendo a la tipología de los procesos, y así especificar y diseñar sus
componentes.
En este proceso de identificación y diseño se ha utilizado el Lenguaje Unificado
de Modelado (UML) que permite modelar, construir y documentar los distintos
componentes que integran un sistema software orientado a objetos. Este lenguaje ofrece
una amplia gama de diagramas que permiten representar la estructura, el
comportamiento y la interacción entre componentes. Los diagramas que han sido
empleados en el proceso de definición y diseño del Sistema son los siguientes:
• Diagrama de caso de uso
• Diagramas de clases
• Diagramas de secuencia
• Diagramas de colaboración
Proyecto fin de carrera
45
3.2.1 CLIENTE
3.2.1.1 Funciones propias
El componente Cliente del Sistema es aquel que se encuentra localizado en el
usuario final. El diseño de este componente se ha desarrollado teniendo en mente la idea
de obtener finalmente un cliente ligero (thin). Por cliente ligero se entiende aquel que
no requiere de instalaciones ni mantenimientos de software para desarrollar su
actividad. Este tipo de cliente descarga los ejecutable y demás archivos requeridos
desde un servidor central, en este caso desde el servidor web/aplicación, utilizando para
ello un software, que es el único que requiere instalación, en este caso cualquier
navegador web que se instale por defecto con el Sistema Operativo.
La razón de dividir un sistema en componentes es, entre otras, ofrecer la
posibilidad de distribuir tareas entre los nodos de forma que la carga de proceso puede
ser distribuida de una manera óptima. Además, muchas de las funciones que son
implementadas en unos componentes no tendría sentido implementarlas en otros, bien
por la relación tan fuerte que existe entre el componente y la ubicación donde es
implementado, o bien por cuestiones de rendimiento. Por ejemplo, no tendría sentido
ubicar una tarea de control de acceso a un servicio cualquiera en un cliente, pues dicha
tarea debiera residir en un servidor central que dispusiera de acceso directo a la base de
datos donde son almacenados los datos de acceso. Tampoco tendría ningún sentido,
cada vez que se tuviera que realizar una verificación del formato de unos datos, que
estos se enviasen al servidor en lugar de hacerlo en el propio cliente, ya que se
consumiría parte del canal de comunicación en una actividad que perfectamente podría
ser realizada en el cliente.
En el caso del Sistema en estudio, el componente Cliente tiene la misión de
facilitar al usuario la utilización del Sistema. Las funciones propias que deberá
implementar el componente Cliente son las siguientes:
• Implementar la parte cliente del protocolo de control DOM 1.0.
Sistema de automatización y control DOM
46
• Actuar como capa de presentación de los datos, proporcionando las
representaciones gráficas, los formatos y los rangos adecuados a los mismos.
• Permitir al usuario realizar un seguimiento de las mediciones realizadas por los
sensores del Sistema.
• Proporcionar el cuadro de mandos apropiado que permita al usuario acceder a
un dispositivo del inmueble para controlar su comportamiento.
• Realizar peticiones periódicas de actualización de la información recogida por
los dispositivos del Sistema.
• Representar la jerarquía de disposición que muestra cómo se reparten las
habitaciones en el inmueble y los módulos en dichas habitaciones.
• Permitir al usuario iniciar y finalizar sesión en el Sistema.
• Dar el formato adecuado a los mensajes de petición de información y de
ejecución de acción que son enviados a través del canal de comunicación.
• Parsear los mensajes del protocolo de control DOM que son recibidos a través
del canal de comunicación para que puedan ser interpretados correctamente por
el componente Cliente.
• Parsear el contenido del archivo de configuración enviado desde el Servidor,
obteniendo a partir del mismo la jerarquía de disposición.
• Evitar que el usuario pueda mandar un mensaje que, o bien no tenga el formato
adecuado, o bien no proceda por el instante en que se encuentra la
comunicación.
• Mostrar al usuario cualquier tipo de información en forma de aviso que pudiera
ser recibido en el contexto del Sistema.
Proyecto fin de carrera
47
3.2.1.2 Diseño interno
3.2.1.2.1 Diagrama de caso de uso
CASO DE USO: Visualizar datos sensores
DESCRIPCIÓN: Un usuario del Sistema tiene la posibilidad de monitorizar la
información recogida por cualquiera de los sensores que están distribuidos por el
inmueble.
ACTOR: Usuario
CONDICIONES PREVIAS: El usuario ha iniciado sesión en el Sistema de forma
satisfactoria introduciendo su identificador y su contraseña.
SECUENCIA BÁSICA
1. El usuario accede a la página web que proporciona el servicio.
2. Introduce el host al que se quiere conectar, el identificador de usuario y la
contraseña.
3. Una vez autenticado, el usuario navega a través de la jerarquía de disposición
hasta encontrar la habitación que desea monitorizar.
4. Seleccionando en la jerarquía el módulo en cuestión, tendrá la posibilidad de
acceder a los sensores ubicados en dicho módulo.
5. Los sensores informan en tiempo real de los valores de las distintas magnitudes
que están siendo monitorizadas.
Sistema de automatización y control DOM
48
EXCEPCIONES
1. Si el usuario no introduce correctamente el identificador de usuario y/o la
contraseña, recibirá un mensaje de error por parte del Sistema indicándole que
ha sido imposible iniciar sesión, con las consecuencias que esto implica.
CONDICIONES POSTERIORES
El usuario habrá monitorizado la información que recibe de los sensores, pudiendo
utilizar dicha información para realizar otro tipo de acciones en el Sistema.
CASO DE USO: Actualizar comportamiento actuadotes
DESCRIPCIÓN: Un usuario del Sistema tiene la posibilidad de controlar de forma
remota el comportamiento de los actuadores que están distribuidos por el inmueble.
ACTOR: Usuario
CONDICIONES PREVIAS: El usuario ha iniciado sesión en el Sistema de forma
satisfactoria introduciendo su identificador y su contraseña.
SECUENCIA BÁSICA
1. El usuario accede a la página web que proporciona el servicio.
2. Introduce el host al que se quiere conectar, el identificador de usuario y la
contraseña.
3. Una vez autenticado, el usuario navega a través de la jerarquía de disposición
hasta encontrar la habitación de la cual se desea controlar los actuadores.
4. Seleccionando en la jerarquía el módulo en cuestión, tendrá la posibilidad de
acceder a los actuadores ubicados en dicho módulo.
5. El aspecto gráfico de los actuadores, que puede ir variando en función de los
cambios que se vayan percibiendo en su estado, puede ser modificado con el fin
de variar el comportamiento de éstos.
6. Los cambios realizados por el usuario en el interfaz gráfico del actuador se
mantienen de forma temporal debido a las posibles modificaciones que puedan
ser realizadas por otros usuarios sobre los mismos dispositivos.
7. Se pulsa el botón de aceptar, lo que implica que las modificaciones son
enviadas a los dispositivos, modificando su comportamiento actual.
Proyecto fin de carrera
49
EXCEPCIONES
1. Si el usuario no introduce correctamente el identificador de usuario y/o la
contraseña, recibirá un mensaje de error por parte del Sistema indicándole que
ha sido imposible iniciar sesión, con las consecuencias que esto implica.
6. Si el usuario, una vez establecido un nuevo comportamiento en el interfaz
gráfico de un actuador, navega por la jerarquía de disposición abandonando el
módulo en el que se encontraba, los valores a los que estableció dichos
actuadotes, guardados de forma temporal, son desechados de manera que tienen
que ser reestablecidos antes de pulsar el botón aceptar.
2. Si el usuario no ha modificado el interfaz de ningún actuador, es decir, no se ha
modificado el comportamiento de ningún actuador, la aplicación lanza un
mensaje de error que advierte de ello.
CONDICIONES POSTERIORES
El usuario habrá actualizado el comportamiento de el/los actuador/es en función de sus
preferencias.
Sistema de automatización y control DOM
50
3.2.1.2.2 Diagramas de clases
prj.client.ConfigFileClientParser
Esta clase implementa el parseador del cliente que interpreta el archivo de
configuración enviado desde el servidor hacia el cliente. Internamente se ha definido
una clase mas de alcance privado: ConfigFileClientParserHandlerBase. Esta clase
define el comportamiento del parseador cuando éste encuentra los elementos y
atributos definidos en el formato XML del archivo config.xml. Es concretamente en
esta clase privada donde se construye la interfaz de la jerarquía de disposición que mas
tarde empleará el usuario para acceder a los dispositivos, que están ubicados en
diferentes habitaciones del inmueble.
Proyecto fin de carrera
51
prj.client.DOMClientParser
Esta clase implementa el parseador del cliente que interpreta las instrucciones
procedentes del servidor en el formato XML del Protocolo de control DOM 1.0.
Internamente se ha definido una clase mas de alcance privado:
DOMClientParserHandlerBase. Esta clase define el comportamiento del parseador
cuando éste encuentra los elementos y atributos definidos en el formato XML.
prj.client.HistoricoParser
Esta clase implementa el parseador del cliente que interpreta el archivo de datos
actualizados de los sensores, enviado desde el servidor hacia el cliente. Internamente se
ha definido una clase mas de alcance privado: HistoricoHandlerBase. Esta clase define
el comportamiento del parseador cuando éste encuentra los elementos y atributos
definidos en el formato XML del archivo historico.xml.
Sistema de automatización y control DOM
52
prj.client.control.TransferRequestMessage
Esta clase implementa el mecanismo para enviar un mensaje de ‘Request’ desde el
cliente hacia el servidor. Además, ofrece la posibilidad de quedar a la espera por la
respuesta del servidor.
prj.client.control.TransferAckReplyMessage
Esta clase implementa el mecanismo para enviar un mensaje de ‘AcknowledgeReply’
desde el cliente hacia el servidor. En este caso, no se ofrece la posibilidad de quedar a
la espera por la respuesta del servidor, pues un ciclo de mensajes entre el cliente y el
servidor finaliza con el envío de un mensaje de tipo ‘AcknowledgeReply’.
Proyecto fin de carrera
53
prj.client.device.DeviceGUI
Esta clase implementa los mecanismos necesarios para dotar a un objeto de tipo Device
de comportamiento gráfico en el interfaz de usuario. Actúa de superclase para las dos
tipologías de dispositivo que pueden existir: analógico y digital.
prj.client.device.Analogical
Esta clase implementa el comportamiento gráfico que debe tener un dispositivo de tipo
analógico en el Sistema. Es subclase de DeviceGUI.
prj.client.device.Digital
Esta clase implementa el comportamiento gráfico que debe tener un dispositivo de tipo
digital en el Sistema. Es subclase de DeviceGUI.
Sistema de automatización y control DOM
54
prj.client.device.HashModuleManager
Esta clase implementa los mecanismos necesarios para leer y escribir desde/a
sensores/actuadores. Implementa sincronización de forma que dos usuarios no puedan
leer o escribir de forma simultánea de/en el mismo sensor/actuador.
prj.client.device.HashModule
Esta clase ofrece una estructura que almacena referencias a los distintos módulos que
pueden existir en una habitación. Los accesos en modo lectura/escritura a la estructura
están muy optimizados de forma que se pueda recuperar y almacenar información de la
forma más eficiente posible, ya que se trata de una estructura utilizada para mejorar las
posibilidades del interfaz gráfico de usuario.
prj.client.device.ModuleKey
Esta clase implementa una clave con la que acceder a los elementos almacenados en la
estructura de tipo HashModule.
prj.client.device.HashDevice
Esta clase ofrece una estructura que almacena referencias a los distintos dispositivos
que pueden existir en un módulo. Al igual que la estructura HashModule, los accesos
en modo lectura/escritura a la estructura están muy optimizados de forma que se pueda
recuperar y almacenar información de la forma más eficiente posible, ya que se trata de
una estructura utilizada para mejorar las posibilidades del interfaz gráfico de usuario.
prj.client.device.DeviceKey
Esta clase implementa una clave con la que acceder a los elementos almacenados en la
estructura de tipo HashDevice.
Proyecto fin de carrera
55
prj.client.msg.ConexionDesconexionRequestMessage
Esta clase implementa el comportamiento de una instrucción de ‘Request’ de conexión
o desconexión. Las instrucciones de ‘Request’ son enviadas desde el cliente hacia el
servidor.
prj.client.msg.EscrituraHardRequestMessage
Esta clase implementa el comportamiento de una instrucción de ‘Request’ de escritura
de actuadores.
prj.client.msg.LecturaHardRequestMessage
Esta clase implementa el comportamiento de una instrucción de ‘Request’ de lectura de
sensores.
prj.client.msg.AckReplyMessage
Esta clase implementa el comportamiento de una instrucción de ‘AcknowledgeReply’
envíada desde el cliente hacia el servidor para confirma la recepción del mensaje de
‘Reply’ enviado previamente desde el servidor hacia el cliente.
Sistema de automatización y control DOM
56
Como ejemplo, dado que la clase EscrituraRequestMessage presenta una
implementación bastante completa, se muestran a continuación las relaciones que dicha
clase necesita establecer con otras clases de su entorno para ser capaz de crear un
mensaje que modifique el comportamiento de un actuador:
Como se aprecia en el gráfico, la clase Message es superclase de
EscrituraHardRequestMessage, es decir, ésta última amplía las funcionalidades de
la primera. El constructor de EscrituraHardRequestMessage utiliza además las clases
Device, EscrituraHardInstruction e InstructionSet para la creación de una instancia de la
clase. Un objeto de tipo Device detalla las características del actuador que se quiere
controlar tales como el módulo al que pertenece, su identificador y el nuevo valor que se
quiere asignar. Por otra parte, para relacionar un objeto de tipo Device con un mensaje
de tipo EscrituraHardRequestMessage es necesario utilizar los objetos de tipo
EscrituraHardInstruction e InstructionSet. Mientras el primero permite identificar el tipo
de instrucción que se va a asociar al mensaje, el segundo implementa la asociación
propiamente dicha. Como se puede apreciar en el nombre de la clase InstructionSet está
preparada para de una a n instrucciones de tipo EscrituraHardInstruction. Este
Proyecto fin de carrera
57
comportamiento, recogido en la etapa de Análisis de requisitos, pretende minimizar el
número de comunicaciones entre los nodos transportando el mayor número posible de
instrucciones de tipo EscrituraHardInstruction en un solo mensaje.
Sistema de automatización y control DOM
58
prj.client.thread.UpdatingComponentsThread
Esta clase implementa el mecanismo necesario para refrescar el interfaz gráfico de los
sensores y actuadotes en la aplicación cliente con los datos mas recientes de los
sensores y actuadores.
prj.client.thread.UpdatingThread
Esta clase implementa el mecanismo necesario para recuperar de forma periódica los
datos más recientes de los sensores y actuadores almacenados en el archivo
historico.xml.
Sistema de automatización y control DOM
60
prj.client.window.BaseWindow
Esta clase implementa el comportamiento básico que debe tener cualquier ventana del
Sistema. Por tanto, las clases AuthenticationWindow y ManagementWindow son
subclases de esta clase superclase.
prj.client.window.AuthenticationWindow
Esta clase implementa el aspecto gráfico y el comportamiento de la ventana de
autenticación del interfaz de usuario empleada para iniciar sesión en el Sistema.
prj.client.window.ManagementWindow
Esta clase implementa el aspecto gráfico y el comportamiento de la ventana de
administración de los dispositivos del interfaz de usuario empleada para elegir el
sensor o actuador con el que se quiera realizar una operación, además de realizar la
operación de monitorización y control propiamente dicha.
prj.client.window.WindowManager
Esta clase implementa el mecanismo encargado de cargar las diferentes ventanas que
componen el interfaz gráfico de la aplicación cliente en el espacio del la ventana del
navegador web reservado para el applet.
prj.client.window.DevicePanel
Esta clase implementa el mecanismo necesario para representar en pantalla el aspecto
grafico de los sensores y actuadotes que integran el Sistema. Realiza una
representación gráfica de los dispositivos en función de si son sensores o actuadores y
analógicos o digitales.
Proyecto fin de carrera
61
prj.client.window.DOMClientApplet
Esta clase implementa los métodos básicos para poder embeber una aplicación Java en
un navegador web.
Proyecto fin de carrera
63
UpdatingThread.run()
Esta clase permite obtener los últimos datos de los dispositivos del Sistema de forma
periódica. El método run() pertenece a la clase UpdatingThread que extiende la clase
estándar Thread. Esta clase permite crear procesos que realizan actividades en segundo
plano, sin penalizar el rendimiento de los procesos que están corriendo en primer
plano. En este caso, la función run() después de crear un mensaje de tipo
LecturaHarhRequestMessage, se conecta al servidor enviando el mensaje que ha acaba
de construir, quedando a la espera de una respuesta de forma asíncrona. Cuando la
respuesta en formato XML llega, se realiza un doble proceso de parseado. Por un lado,
se reconstruye el mensaje que viene en el flujo de entrada, y por otro lado se interpreta
parte de la información que viene adjunta al mensaje. En este caso información
referente a los últimos datos recogidos por los dispositivos electrónicos del Sistema.
Sistema de automatización y control DOM
64
3.2.2 SERVIDOR
3.2.2.1 Funciones propias
El componente Servidor es el segundo gran componente en que está dividido el
Sistema de automatización y control DOM. Este componente tiene la misión de
permanecer a la escucha de peticiones de servicio procedentes de diferentes
componentes Cliente. Se encuentra localizado en un servidor central de forma que sea
mas sencillo de acceder para los componentes Cliente, y mas sencillo para el propio
componente prestar el servicio. Aunque si bien es cierto, esta sencillez puede ser una
ventaja en lo que a tiempo de respuesta y consumo de recursos se refiere, no es menos
cierto que una excesiva sencillez puede limitar el Sistema siempre y cuando no se
implementen características vitales para un Sistema de Tiempo Real tales como
redundancia, control de flujo, detección de errores, etc. En este caso, mientras algunas
de estas características han sido implementadas de una forma básica, algunas otras se
han dejado en manos del sistema de comunicación subyacente.
En el caso del componente Servidor las tareas que le han sido asociadas tienen
mas que ver con la ubicación física donde residen y el carácter central de las mismas
que con cualquier otro aspecto. Entre las funciones propias que deberá implementar el
componente Servidor se encuentran las siguientes:
• Implementar la parte servidor del protocolo de control DOM 1.0.
• Gestionar las peticiones de inicio y fin de sesión de sesión en el Sistema que son
lanzadas desde los clientes.
• Atender las peticiones de lectura de los valores mas recientes de recogidos por
los sensores, así como de control del comportamiento de los actuadores.
• Dar el formato adecuado a los mensajes de respuesta a peticiones de
información y de ejecución de acciones que son enviados a través del canal de
comunicación.
Proyecto fin de carrera
65
• Parsear los mensajes que son recibidos a través del canal de comunicación para
que puedan ser interpretados correctamente por el componente Servidor.
• Guardar el estado de la sesión para cada uno de los usuarios que acceden al
servicio.
• Escribir en el log del Sistema cada una de las acciones realizadas por el usuario,
bien con fines de seguimiento del funcionamiento del Sistema o bien con fines
de mantenimiento correctivo.
• Evitar que el servidor pueda mandar un mensaje que, o bien no tenga el formato
adecuado, o bien no proceda por el instante en que se encuentra la
comunicación.
• Enviar información de configuración del Sistema a los usuarios.
• Determinar el estado en que se encuentra el protocolo de control DOM en el
lado del servidor. El servidor debe determinar que mensajes del protocolo de
control son aceptados en un momento dado.
• Devolver el estado de la parte del protocolo de control ejecutada en el servidor
al estado anterior en que se encontraba antes de producirse un fallo. Checkpoint-
Recuperación.
Proyecto fin de carrera
67
prj.server.DOMServerManagement
Esta clase, que implementa la clase HttPServlet, atiende las solicitudes realizadas por
los clientes en el formato XML del Protocolo de control DOM 1.0. Se trata del
componente de servidor que gestiona las solicitudes de inicio y fin de sesión,
monitorización de sensores y control de actuadores.
prj.server.DOMServerUpdating
Esta clase, que también implementa la clase HttPServlet, atiende las solicitudes de
lectura del archivo historico.xml. Como se ha detallado anteriormente, este archivo
contiene lo última versión de los datos recogidos por los sensores del sistema, de
manera que puedan ser enviados al cliente con el mínimo retardo posible.
prj.server.DOMServerParser
Esta clase implementa el parseador del servidor que interpreta las instrucciones
procedentes de los clientes en el formato XML del Protocolo de control DOM 1.0.
Internamente se han definido dos clases mas de alcance privado:
DOMServerParserContentHandler y DOMServerParserErrorHandler. La primera
define el comportamiento del parseador cuando éste encuentra los elementos y
atributos definidos en el formato XML. El segundo para manejar posibles errores que
puedan aparecer en el momento del parseo del stream de datos de entrada.
prj.server.DOMServerFileManagement
Esta clase gestiona el acceso del servlet DOMServerManagement a los archivos que
son compartidos por los usuarios del Sistema. Implementa un mecanismo de
sincronización para evitar que dos usuarios lean o escriban simultáneamente de los
archivos historico.xml y actualizacion.xml. También gestiona la sincronización para el
acceso en modo lectura y escritura a los archivos contraseña.txt y log.txt.
Sistema de automatización y control DOM
68
prj.server.DOMServerSession
La clase DOMServerSession proporciona una estructura de almacenamiento temporal
para los elementos de tipo DOMServerSessionItem. Los tiempos de acceso a dicha
estructura están muy optimizados de forma que, tanto el almacenamiento como la
recuperación de la información se hagan de la forma más rápida y eficiente posible.
prj.server.DOMServerSessionItem
La clase DOMServerSessionItem almacena la información de la sesión relacionada con
el estado en el se encuentra el Sistema tanto actualmente como anteriormente. Además,
el nombre del usuario propietario de la sesión y el identificador de la misma, de tipo
HttpSession, son otras informaciones almacenadas en la sesión. Este identificador sirve
de clave para acceder a la información de la sesión almacenada en la estructura
DOMServerSession.
Proyecto fin de carrera
69
prj.server.control.Coordinator
En esta clase se asigna a cada código de acción a ejecutar su correspondiente
implementación.
prj.server.control.ManagementActionPattern
Esta clase determina las acciones que debe tomar el Sistema según se encuentre en una
situación u otra. Las reglas están codificadas en una matriz estado/mensaje/acción.
Mientras que las filas son los estados y las columnas los mensajes que llegan al
servidor desde los clientes, cada uno de los elementos de la matriz se corresponde con
una acción a tomar. Así, es posible, sabiendo el estado actual y el mensaje de entrada,
determinar qué acción será ejecutada por el Sistema.
Sistema de automatización y control DOM
70
prj.server.control.ManagmentActionImplementation
En esta clase se implementan cada una de las acciones que han sido definidas en la
clase ManagementActionPattern. Si alguna de estas acciones emplea el sistema de
archivos del Sistema Operativo subyacente entonces se valdrá del objeto
DOMServerFileManagement para gestionar los accesos concurrentes a dicho sistema.
prj.server.control.RandomIdentifier
Esta clase implementa un generador de números de mensaje aleatorios. Cada uno de
los mensajes intercambiados en el Protocolo de control DOM 1.0 lleva asociado un
código de mensaje que lo identifica de forma única durante dicha comunicación.
prj.server.control.State
Esta clase almacena diversos detalles de la sesión en la que está inmerso el usuario. El
estado actual y anterior del Sistema, o si el usuario ha sido o no autenticado
constituyen la información almacenada.
Proyecto fin de carrera
71
prj.server.msg.Instruction
Esta clase es superclase de una serie de clases que representan diferentes tipologías de
instrucción. El comportamiento común a todas estas clases es recogido en la clase
Instruction. Entre otras, la utilización de una superclase permite aprovechar las
posibilidades que el polimorfismo ofrece, ya que en tiempo de ejecución se desconoce
por completo que tipo de instrucción va a tener que tratar el servidor.
prj.server.msg.ConexiónDesconexiónInstruction
Esta clase implementa el comportamiento de una instrucción de conexión o
desconexión al Sistema.
prj.server.msg.LecturaHardInstruction
Esta clase implementa el comportamiento de una instrucción de lectura de sensores del
Sistema.
Sistema de automatización y control DOM
72
prj.server.msg.EscrituraHardInstruction
Esta clase implementa el comportamiento de una instrucción de escritura de sensores
del Sistema.
prj.server.msg.RespuestaInstruction
Esta clase implementa el comportamiento de una instrucción de respuesta desde el
servidor hacia el cliente. Este tipo de instrucción es algo mas compleja que las
anteriores, entre otras cosas porque en función de la instrucción de ‘request’ que recibe
el servidor puede responder de cuatro formas diferentes:
• En caso de recibir una solicitud de inicio o fin de sesión, el servidor da una
respuesta de tipo ‘RespuestaConfig’ si la dupla identificador/contraseña
proporcionada es correcta. Esta respuesta, además de certificar que el inicio de
sesión se ha realizado satisfactoriamente, transfiere el archivo de configuración
del Sistema config.xml que será utilizado para la creación de la jerarquía de
disposición en el cliente.
• En caso de recibir una solicitud de inicio o fin de sesión, el servidor da una
respuesta de tipo ‘RespuestaError’ si la dupla identificador/contraseña
proporcionada es incorrecta.
• En caso de recibir una solicitud de actualización de actuadores, el servidor
puede dar una respuesta de tipo ‘ResuestaOk’ o ‘RespuestaError’ en función de
si la operación se ha realizado con éxito o no.
• En caso de recibir una solicitud de lectura de sensores, el servidor da una
respuesta de tipo ‘RespuestaHard’ que implica la transferencia del archivo
historico.xml que contiene los datos mas actualizados de los sensores del
Sistema.
Proyecto fin de carrera
73
prj.server.msg.DeviceToJComponent
Esta clase traslada el comportamiento de un desipositivo, tal y como es tratado
internamente en el Sistema, a un objeto de la clase JComponent.
prj.server.msg.Device
Esta clase implementa el comportamiento de un dispositivo del Sistema. Representa el
conjunto de características que identifican de forma unívoca a un dispositivo como son
el identificador del propio dispositivo, el módulo al que pertenece, el pin al que se
conecta en el módulo, etc.
prj.server.msg.Message
Esta clase implementa el comportamiento de un mensaje del Sistema. Un mensaje
puede contener una o mas instrucciones, pero siempre del mimos tipo.
prj.server.msg.ReplyMessage
Esta clase implementa el mecanismo para enviar un mensaje de ‘Reply’ desde el el
servidor hacia el cliente.
Sistema de automatización y control DOM
74
prj.server.msg.InstructionSet
Esta clase implementa el mecanismo que permite asociar varias instrucciones que
pertenecen al mismo mensaje. Un objeto de este tipo se asigna a un objeto de tipo
Message.
Proyecto fin de carrera
77
DOMServerManagement.doPost()
Este diagrama muestra la secuencia de eventos que ocurre cuando el sevlet que
implementa la lógica en el servidor recibe una petición http desde un cliente.
Inicialmente, se comprueba si es la primera vez que el cliente realiza una solicitud. En
tal caso, se le asigna un identificador único que se obtiene mediante el método getId()
de la clase HttpSession. Además, dicho identificador es almacenado en un objeto de la
clase DOMServerSessionItem, que a su vez, es almacenado en un objeto de la clase
DOMServerSession. La finalidad de esta serie de almacenamientos de referencias no es
otra que guardar el identificador de sesión durante el tiempo que dura la comunicación
entre el cliente y el servidor. Al mismo tiempo, el objeto de la clase
DOMServerSessionItem almacena una referencia a un objeto de la clase State, que
permite guardar información relacionada con la sesión y que será utilizada
posteriormente en la toma de acciones. Después de esto, una vez que el servidor tiene
identificado al cliente, el propio servidor deberá dar formato al stream de entrada. Para
ello utilizará los métodos parseMessage() y getMessage() del parserador definido en la
clase DOMServerParser (DOMServerParser y DOMClientParser son los parser
encargados de dar formato a los streams de entrada tanto en el servidor como en el
cliente). Una vez que el servidor ha logrado convertir el flujo de datos de entrada a un
objeto Message, se dispone a llevar a cabo la acción que el usuario ha solicitado por
medio del mensaje. Para lograr esto, el servidor emplea la clases Coordinator, que
como su propio nombre indica coordina la ejecución de acciones en la parte servidora.
Mediante el método executeAction(), la citada clase consigue llevar a cabo la acción
solicitada en el mensaje, siempre y cuando el estado del Sistema lo permita.
Finalmente, executeAction() devuelve una cadena que contiene el mensaje con la
respuesta que el Sistema da al usuario sobre el éxito o no de su solicitud. Dicho
mensaje es enviada al usuario antes de finalizar la ejecución del método doPost().
Sistema de automatización y control DOM
78
Coordinador.executeAction()
Este diagrama de secuencia esquematiza el comportamiento consistente en seleccionar
una acción en función del mensaje de entrada y del estado en que se encuentre el
Sistema. Posteriormente, una instancia de la clase ManagementActionImplementation
será la encarga de invocar al método encargado de implementar la acción
correspondiente.
Sistema de automatización y control DOM
80
ManagementActionImplementation.logonAction()
El método logonAction() es una de las cinco acciones que pueden ser invocadas desde
el método executeAction() de la clase Coordinator. Concretamente, este método
permite al usuario iniciar sesión en el Sistema. Como se puede apreciar en el diagrama
de secuencia, una vez que se obtiene una referencia al mensaje entrante, se extraen del
mismo el identificador de usuario y la contraseña. Después, se comprueba que, tanto el
identificador de usuario como la contraseña que vienen en el mensaje, son correctos.
Posteriormente, una vez que se ha verificado la validez de la información de inicio de
sesión, se almacena en el objeto de tipo State el nombre del usuario para tener acceso
al mismo durante la sesión. Además, se escribe en el log del Sistema la acción que
acaba de suceder, se recupera del fichero config.txt la configuración del Sistema
enviándosela al usuario de vuelta.
ManagementActionImplementation.logoffAction()
La implementación de este método es exactamente igual que la implementación del
método logonAction().
Sistema de automatización y control DOM
82
ManagementActionImplementation.writeAction()
El método writeAction() es otra de las cinco acciones que pueden ser tomadas desde el
método executeAction() de la clase Coordinator. Este método permite al usuario
controlar el comportamiento de los actuadores del Sistema. Como se puede apreciar en
el diagrama de secuencia, en primer lugar se invoca el método writeActuadorFile() de
la clase DOMServerFileManagementuna para escribir los nuevos parámetros de
control en el archivo actualización.xml. Después, , se escribe en el log del Sistema la
acción que acaba de suceder y se envía una respuesta de operación realizada al usuario,
siempre y cuando todo haya finalizado correctamente. Si hubiera ocurrido cualquier
problema a la hora de ejecutar el método writeAction(), se hubiera enviado de igual
forma un mensaje al usuario, pero en este caso de error.
Proyecto fin de carrera
83
ManagementActionImplementation.logonAction()
El método changeStateAction() es otra de las cinco acciones que pueden ser invocadas
desde el método executeAction() de la clase Coordinator. El método
changeStateAction() permite al Sistema cambiar el estado que la sesión del usuario
mantiene en el servidor. Esta acción es ejecutada cuando el usuario responde al
servidor con un mensaje de tipo ‘AcknowledgeReply’. En este caso, aparte de
establecer el estado en el que queda el Sistema, escribe en el log el evento que ha
ocurrido y, solamente en esta acción, no se envía respuesta al usuario pues el ciclo de
intercambio de mensajes entre cliente y servidor termina con un mensaje de tipo
‘AcknowledgeReply’.
Sistema de automatización y control DOM
84
ManagementActionImplementation.errorAction()
El método errorAction() es otra de las cinco acciones que pueden ser invocadas desde
el método executeAction() de la clase Coordinator. Se ejecuta esta acción cuando
ocurre un error en el orden en que son intercambiados los mensajes, de forma que el
método intenta coordinar nuevamente al servidor con el cliente. En este caso, se
mantiene el estado del Sistema sin realizar variación alguna en el mismo y se escribe el
evento ocurrido en el log.
Sistema de automatización y control DOM
86
DOMServerUpdating.doPost()
Este diagrama muestra la secuencia de eventos que ocurre cuando el sevlet encargado
de despachar la información más actualizada de los dispositivos del Sistema, recibe
una petición http desde un cliente. Dado que para tener acceso a esta información es
necesario haber iniciado sesión previamente de forma correcta, lo primero que hará el
servlet será recuperar los datos asociados a la sesión del usuario que realiza la
solicitud. La información sobre la sesión será recuperada desde el objeto
DOMSeverSessionItemInicialmente asociado al usuario por medio de la cookie que
éste envía desde su navegador. Después de esto, una vez que el servidor tiene
identificado al cliente, el propio servidor deberá dar formato al stream de entrada Para
ello, vuelve a utilizar los métodos parseMessage() y getMessage() del parserador
DOMServerParser, como ya hiciera en el servlet implementado en la clase
DOMServerManagement. Una vez que el servidor ha logrado convertir el flujo de
datos de entrada a un objeto Message, se dispone a llevar a cabo la acción que el
usuario ha solicitado por medio del mensaje. En este caso, recuperar la información
mas reciente de los sensores y actuadores del Sistema que ha sido previamente
almacenada en el archivo historico.xml. Para lograr esto, el servidor emplea el método
readHistoricoFile() de la clase DOMServerFileManagement, que recupera el contenido
del archivo que será enviado al usuario. Para realizar tal envío, el servlet crea un
mensaje de respuesta, utilizando la clase ReplyMessage, en el que incluirá el contenido
del archivo recuperado.
Proyecto fin de carrera
89
AuthenticationWindow.actionPerformed()
Este diagrama es un ejemplo muy ilustrativo que muestra el conjunto de eventos que
ocurren en el programa cliente a la hora de enviar un mensaje al servidor. En este caso,
el tipo de mensaje que se está enviando es ConexionDesconexionRequestMessage, un
mensaje de solicitud de inicio de sesión. Inicialmente, para enviar un mensaje, se
requiere crear una instancia del objeto encargado de enviar el mensaje de ‘request’,
TransferRequestMessage, pasándole la referencia del tipo de mensaje creado
anteriormente. Una vez creado el objeto, se conecta con el host destino del mensaje, se
envía el mensaje y se permanece a la espera de una respuesta, mensaje de
‘reply’.Cuando la respuesta llega, esta lo hace en forma de stream de entrada, por lo
que será necesario parsearla para que el software cliente pueda entenderla. El
encargado de realizar tal labor es un objeto de la clase DOMClientParser. Finalmente,
una vez que se conoce la respuesta del servidor al mensaje de ‘request’, el cliente se
dispone a enviar un nuevo mensaje, ahora de tipo ‘AcknowledgeReply’, utilizando un
objeto de la clase AckReplyMessage. Para el envío del mensaje se emplea ahora un
objeto de la clase TransferAckReplyMessage, que lleva adherido el mensaje que se
quiere transmitir. La razón por la cual se emplean dos objetos de dos clases distintas
para el envío de mensajes es que, mientras la clase TransferRequestMessage tiene un
método para permanecer esperando por una respuesta de forma síncrona, la clase
TransferAckReplyMessage no ofrece tal posibilidad debido a que, como ya se ha
recalcado en numerosas ocasiones, un mensaje de tipo ‘AcknowledgeReply’ finaliza el
ciclo de mensajes intercambiados entre dos nodos del Sistema.
Sistema de automatización y control DOM
90
3.2.2.2.3 Diagramas de colaboración
DOMServerFileManagement.readHistoricoFile()
Este diagrama de colaboración representa la interacción que existe entre las distintas
clases a la hora de realizar una actividad periódica como es la lectura del archivo
historico.xml. En él se puede apreciar, siguiendo la numeración que figura al lado de
los nombres de los métodos, el orden en que éstos van siendo invocados. Un diagrama
similar se genera para los métodos readConfigFile() y checkContraseñaFile(),
utilizados para leer el archivo config.xml y chequear el archivo contraseña.txt en
busca de duplas con la información de inicio de sesión proporcionada.
Sistema de automatización y control DOM
92
DOMServerFileManagement.writeLogFile()
Este diagrama representa el flujo de mensajes invocados entre diferentes clases para
escribir en el fichero log.txt. Este diagrama es similar al diagrama de colaboración del
método writeActuatorFile(). La única diferencia destacable sería que en el caso del
método que escribe en el log del Sistema es necesaria la instanciación de objetos de
tipo Date y DateFormat, pues en el log en cada registro se incluye la fecha en que fue
añadido.
Sistema de automatización y control DOM
94
ConfigFileClientParser.ConfigFileClientParserHandlerBase.startElement()
Este diagrama muestra la colaboración que se establece entre diferentes clases para
parsear el contenido del archivo config.xml. Es en dicho proceso donde se construye la
jerarquía de disposición que permite al cliente acceder a los distintos dispositivos
ubicados en un área determinada del inmueble. La jerarquía de disposición está
construida utilizando el componente DefaultMutableTreeNode, que proporciona una
apariencia jerárquica del conjunto de habitaciones en que está estructurado el
inmueble. Si se observan las distintas llamadas que se intercambian las clases que
participan de este proceso, es posible apreciar como se crean instancias de la clase
DefaultMutableTreeNode llamadas building, Hindex, room o floor. Estas referencias
representan cada uno de los niveles de la jerarquía tales como el edificio para el que se
está creando la jerarquía, las plantas que tiene dicho edificio o el conjunto de
habitaciones que se distribuyen en cada planta.
Proyecto fin de carrera
95
3.2.2.3 Comportamiento del Servidor
A continuación se muestra la tabla de estado actual/mensaje � estado futuro-
acción. Esta tabla recoge las transiciones entre los estados posibles en el
comportamiento del componente Servidor, así como las acciones asociadas a las
mismas, cuando el Sistema se encuentra en un estado determinado y recibe un mensaje
concreto:
Para cada combinación de estado actual/mensaje existe uno o varios estados a
los que se puede llegar, así como una acción asociada que se tiene que ejecutar.
Mientras que el nuevo estado al que se llega se indica en la parte superior izquierda de
cada celda, en la parte inferior derecha se indica la acción a ejecutar. Por ejemplo,
supongamos que un usuario que se hubiera autenticado previamente decide enviar
nuevos parámetros de control a un actuador del Sistema. Para ello, estando el servidor
en estado 1. Autenticado, recibiría un mensaje de tipo EscrituraHard que provocaría una
transición del estado 1. Autenticado al estado 2. RespuestaOK o 3. RespuestaError, en
1 5
n/a n/a
1 5
1 5
2, 3 4
0 5
1 5
n/a n/a
1 5
1 5
1 5
3, 5 1
n/a n/a
n/a n/a
n/a n/a
n/a n/a
n/a n/a
n/a n/a
1 3
n/a n/a
0, 1 3
1 3
1 5
0 5
1 5
n/a n/a
1 5
1 5
2, 3 2
0 5
1 5
n/a n/a
1 5
1 5
1 5
0 5
0.
NoAutenticado
1.
Autenticado
3.
RespuestaError
4.
RespuestaWait
5.
RespuestaConfig
2.
RespuestaOK
Estado actual
Mensaje
Mensaje erróneo
EscrituraHard
RespuestaOK
RespuestaError
Conexión
Desconexión
Sistema de automatización y control DOM
96
función de si la operación se ha realizado con o sin éxito. Además de la transición a uno
de estos dos estados, el Sistema ejecutará una acción que actualizará el comportamiento
del actuador con los nuevos parámetros enviados.
Este comportamiento se ha trasladado al código del servlet mediante la
implementación de la clase ManagementActionPattern. Esta clase utiliza un array
bidimensional para llevar a la práctica el comportamiento recogido en la tabla anterior.
El código de la clase ManagementActionPattern se reproduce a continuación por su
interés:
/*
* Creado el 07-ago-2006
*
* TODO Para cambiar la plantilla de este archivo generado, vaya a
* Ventana - Preferencias - Java - Estilo de código - Plantillas de código
*/
package prj.server.control;
/**
* @author Alberto Carrasco
*
* TODO Para cambiar la plantilla de este comentario generado, vaya a
* Ventana - Preferencias - Java - Estilo de código - Plantillas de código
*/
import java.util.Iterator;
import prj.server.msg.*;
//Esta clase representa el 'patrón de acción' para el servlet DOMServletManagement.
//Por patrón de acción se entiende como actúa el sistema en función del estado en
//que se encuentra la sesión del usuario en el sistema en un momento dado y de la
//entrada(mensaje) que recibe dicho sistema en ese mismo momento.
public class ManagementActionPattern {
//Constantes que definen los diferentes mensajes que, según la clase ManagementActionPattern,
//pueden llegar al servlet DOMServletManagement.
static final int ERROR_MSG = 0;
static final int ESCRITURAHARD_MSG = 1;
static final int RESPUESTAOK_MSG = 2;
static final int RESPUESTAERROR_MSG = 3;
static final int CONEXION_MSG = 4;
static final int DESCONEXION_MSG = 5;
Proyecto fin de carrera
97
//Constantes que definen las distintas acciones que pueden ser almacenadas en la matriz
//messageStateActionMatrix
static final int LOGON_ACTION = 1;
static final int WRITE_ACTION = 2;
static final int CHANGESTATE_ACTION = 3;
static final int LOGOFF_ACTION = 4;
static final int ERROR_ACTION = 5;
//Esta es la matriz de decisión que hará elegir una acción en función de una serie de valores
//de entrada:
// - El estado actual en el que se encuentra la sesión del usuario en el sistema
// en un instante dado.
// - El mensaje que llega al servlet DOMServerManagement en instante dado.
//
//La matriz quedaria tal que así:
//
// x1'x2'x3'x4'x5'x6' LEYENDA xn(Estado): Leyenda xn'(Mensaje):
//x1 5 5 5 5 1 5 x1-> NOAUTHENTICATED_STATE x1'-> ERROR_MSG
//x2 5 2 5 5 5 4 x2-> AUTHENTICATED_STATE x2'-> ESCRITURAHARD_MSG
//x3 5 5 3 3 5 5 x3-> RESPUESTAOK_STATE x3'-> RESPUESTAOK_MSG
//x4 5 5 3 5 5 5 x4-> RESPUESTAERROR_STATE x4'-> REPUESTAERROR_MSG
//x5 5 5 3 5 5 5 x5-> RESPUESTAWAIT_STATE x5'-> CONEXION_MSG
//x6 5 5 3 5 5 5 x6-> RESPUESTACONFIG_STATE x6'-> DESCONEXION_MSG
//IMPORTANTE!
//Para añadir una nueva acción al sistema bastará con crear una nueva constante xxxxx_ACTION
//e insertarla dentro de la matriz messageStateActionMatrix en la posición que corresponda.
//Posteriormente, en la clase Coordinator se deberá crear una nueva entrada 'case' en la
//función executeAction() para la nueva acción, así como una nueva función en la clase
//ManagementActionImplementation que implemente dicha nueva acción.
private int[][] messageStateActionMatrix;
public ManagementActionPattern(){
messageStateActionMatrix = new int[6][6];
}
Sistema de automatización y control DOM
98
//Este método transforma el identificador de la instrucción utilizado en el documento xml
//en el identificador utilizado en el patrón de comportamiento establecido en la clase
//ManagementActionPattern.
private int fromInstructionToManagementActionPatternMessage(Message msg){
Iterator itr = msg.getInstructionSet().getInstructions();
int msgMAPValue = -1;
switch(((Instruction)itr.next()).getType()){
case 2:
msgMAPValue = ESCRITURAHARD_MSG;
break;
case 3:
msgMAPValue = RESPUESTAOK_MSG;
break;
case 4:
msgMAPValue = RESPUESTAERROR_MSG;
break;
case 8:
msgMAPValue = CONEXION_MSG;
break;
case 9:
msgMAPValue = DESCONEXION_MSG;
break;
default:
msgMAPValue = RESPUESTAERROR_MSG;
break;
}
return msgMAPValue;
}
Proyecto fin de carrera
99
//Devuelve la acción a tomar en función de el estado actual y del mensaje obtenido
public int getActionIndex(State st, Message msg){
//Se obtiene el identificador del estado correspondiente a la fila de la matriz
//messageStateActionMatrix
int currentState = st.getCurrentStatus();
//Se obtiene el identificador del mensaje correspondiente a la columna de la matriz
//messageStateActionMatrix
int currentMessage = fromInstructionToManagementActionPatternMessage(msg);
//Se comprueba si la función fromInstructionToManagementActionPatternMessage(Message msg)
//devuelve -1. En tal caso se sustituye dicho valor por la constante RESPUESTAERROR_MSG
//cuyo valor es 3 para que pueda hacerse la búsqueda correctamente en la matriz
//messageStateActionMatrix
if(currentMessage == -1)
currentMessage = RESPUESTAERROR_MSG;
//Se extrae el valor de la matriz messageStateActionMatrix
if((currentState >= 0 && currentState < 6) && (currentMessage >= 0 && currentMessage < 6))
return messageStateActionMatrix[currentState][currentMessage];
else
return -1;
}
//Este método inicializa la matriz messageStateActionMatrix con los valores enteros de las
//acciones pertinentes que pueden ser tomadas
public void init(){
//[x1][xn'] (n' desde 1 a 6)
messageStateActionMatrix[0][0] = ERROR_ACTION;
messageStateActionMatrix[0][1] = ERROR_ACTION;
messageStateActionMatrix[0][2] = ERROR_ACTION;
messageStateActionMatrix[0][3] = ERROR_ACTION;
messageStateActionMatrix[0][4] = LOGON_ACTION;
messageStateActionMatrix[0][5] = ERROR_ACTION;
Sistema de automatización y control DOM
100
//[x2][xn'](n' desde 1 a 6)
messageStateActionMatrix[1][0] = ERROR_ACTION;
messageStateActionMatrix[1][1] = WRITE_ACTION;
messageStateActionMatrix[1][2] = ERROR_ACTION;
messageStateActionMatrix[1][3] = ERROR_ACTION;
messageStateActionMatrix[1][4] = ERROR_ACTION;
messageStateActionMatrix[1][5] = LOGOFF_ACTION;
//[x3][xn'] (n' desde 1 a 6)
messageStateActionMatrix[2][0] = ERROR_ACTION;
messageStateActionMatrix[2][1] = ERROR_ACTION;
messageStateActionMatrix[2][2] = CHANGESTATE_ACTION;
messageStateActionMatrix[2][3] = ERROR_ACTION;
messageStateActionMatrix[2][4] = ERROR_ACTION;
messageStateActionMatrix[2][5] = ERROR_ACTION;
//[x4][yn] (xn' desde 1 a 6)
messageStateActionMatrix[3][0] = ERROR_ACTION;
messageStateActionMatrix[3][1] = ERROR_ACTION;
messageStateActionMatrix[3][2] = CHANGESTATE_ACTION;
messageStateActionMatrix[3][3] = ERROR_ACTION;
messageStateActionMatrix[3][4] = ERROR_ACTION;
messageStateActionMatrix[3][5] = ERROR_ACTION;
//[x5][xn'] (xn' desde 1 a 6)
messageStateActionMatrix[4][0] = ERROR_ACTION;
messageStateActionMatrix[4][1] = ERROR_ACTION;
messageStateActionMatrix[4][2] = CHANGESTATE_ACTION;
messageStateActionMatrix[4][3] = ERROR_ACTION;
messageStateActionMatrix[4][4] = ERROR_ACTION;
messageStateActionMatrix[4][5] = ERROR_ACTION;
//[x6][xn'] (xn' desde 1 a 6)
messageStateActionMatrix[5][0] = ERROR_ACTION;
messageStateActionMatrix[5][1] = ERROR_ACTION;
messageStateActionMatrix[5][2] = CHANGESTATE_ACTION;
messageStateActionMatrix[5][3] = ERROR_ACTION;
messageStateActionMatrix[5][4] = ERROR_ACTION;
messageStateActionMatrix[5][5] = ERROR_ACTION;
}
}
Proyecto fin de carrera
101
3.3 COMUNICACIÓN CLIENTE-SERVIDOR
La comunicación entre los componentes Cliente y Servidor se realiza mediante
servlets. Java Servlet Technology es una tecnología propiedad de la compañía
norteamericana SUN Microsystems, que se enmarca dentro del paquete Java 2
Enterprise Edition (J2EE), que permite generar contenido dinámico en formato HTML
como respuesta a una petición previa realizada por un interlocutor, generalmente una
petición recibida desde un navegador web o incluso desde otro servlet.
El Protocolo de Transferencia de Hipertexto (HTTP) es un protocolo de nivel de
aplicación utilizado por los navegadores web para realizar peticiones a los servidores
web recibiendo respuesta de estos. HTTP funciona mediante el intercambio de mensajes
request-reply entre los nodos involucrados. El formato de dichos mensajes es distinto ya
que cada uno está pensado para realizar una función diferente.
En formato del mensaje de request está formado por el nombre del método, la
URL del recurso que se quiere acceder, la versión del protocolo, alguna información de
cabecera y un cuerpo de mensaje opcional. Mientras, en el caso del mensaje de reply,
éste está formado por la versión del protocolo, un código de estado, razón, alguna
información de cabecera y un cuerpo de mensaje opcional. A continuación se muestra
un esquema de ambos formatos:
POST http://www... HTTP/1.1
Método URL Versión HTTP Cabeceras Cuerpo
Mensaje HTTP de Request
HTTP/1.1 200 OK Datos
Versión HTTP Estado Razón
Cabeceras Cuerpo
Mensaje HTTP de Reply
Datos
Sistema de automatización y control DOM
102
HTTP dispone de varios métodos que se pueden incluir en el mensaje de
request: GET, POST, HEAD, PUT… Para el envío de mensajes de request se ha se
elegido el método POST. Este método permite transportar cantidades importantes de
información en los mensajes de solicitud, lo que lo hace idóneo para insertar
información de control y datos del protocolo de control DOM. Esta información se
transporta en el campo opcional Cuerpo del mensaje. Es cierto que el método GET
también tiene la capacidad de contener datos, pero el número es ciertamente mas
limitado que el anterior ya que se anexan al campo URL del mensaje de solicitud, que
no está preparado para transportar grandes cantidades de información. En el caso del
mensaje de reply, la información devuelta se almacena también en el campo opcional
Cuerpo del mensaje. Así, mientras los mensajes HTTP de request son enviados desde el
cliente al servidor, los mensajes HTTP de reply son enviados en sentido contrario, es
decir, desde el servidor al cliente.
Por tanto, los servlets no son entidades que permanecen ajenas a este
intercambio de mensajes HTTP, sino que participan activamente recibiendo mensajes
de request y devolviendo mensajes de reply. Y, precisamente, es la lógica que pueden
implementar los servlets la que les permite enviar un mensaje u otro en función del
mensaje de solicitud que se haya recibido del cliente. Se puede actuar en repuesta a
algo. El proceso de comunicación cliente-servidor se muestra en detalle en los
siguientes gráficos:
CLIENTE SERVIDOR
Mensaje HTTP de Request
<?xml version=”1.0” encoding=” ISO-8859-1” …?> <!DOCTYPE mensaje SYSTEM ""> <mensaje idMensaje=”” idMensajeAck=””> </mensaje>
SERVLET
post www HTTP Datos
Proyecto fin de carrera
103
CLIENTE SERVIDOR
Mensaje HTTP de Reply
<?xml version=”1.0” encoding=” ISO-8859-1” …?> <!DOCTYPE mensaje SYSTEM ""> <mensaje idMensaje=”” idMensajeAck=””> </mensaje>
SERVLET
HTTP 200 OK Datos
Sistema de automatización y control DOM
104
3.4 MODELO DE DATOS
El modelo de datos es un documento necesario para la obtención de una
arquitectura de datos consistente. A partir del modelo de datos se van a obtener las
estructuras físicas de datos que permitirán procesar y almacenar la información relativa
al Sistema. Pero no solamente las estructuras físicas serán deducidas a partir de este
modelo, anteriormente a éstas también serán deducidas las características principales
del modelo de datos del Sistema.
A diferencia de otros proyectos, las estructuras que finalmente se obtendrán
como resultado del documento no serán tablas relacionales sino archivos. Estos
archivos, a fin de obtener una arquitectura de datos coherente con el sistema que se está
diseñando, serán normalizados evitando redundancias derivadas de un proceso erróneo
de colección de datos.
A continuación se desarrolla el modelo de datos. Este modelo pretende servir
como presentación para cada uno de los archivos necesarios para el correcto
funcionamiento del Sistema. Además, dicho modelo pretende detallar la parte del
proceso en la cual están implicados estos archivos, así como todos y cada uno de los
elementos que los integran, con su correspondiente descripción y el rango de valores
posibles.
Proyecto fin de carrera
105
3.4.1 Protocolo de control DOM 1.0
A pesar de que el Protocolo de control DOM 1.0 no puede ser considerado una
estructura de almacenamiento de información permanente, no es menos cierto que dicho
protocolo emplea una estructura XML para dar formato a la información que es
intercambiada entre nodos. Esta estructura XML es utilizada de forma temporal, es
decir, no se guarda en ningún dispositivo de almacenamiento que no sea la memoria
RAM, que tiene carácter volátil.
Sin embargo, el mero hecho de que esta estructura tenga un ciclo de vida
bastante mas corto que muchas otras que forman parte del Sistema, como los archivos
XML de configuración, histórico o actualización, no hace su estudio menos importante.
Por esta razón, a continuación se muestra la estructura XML general de elementos y
atributos utilizada para el intercambio de información entre nodos por el Protocolo de
Control DOM 1.0:
<?xml version=”1.0” encoding=” ISO-8859-1” standalone=”no”?> <!DOCTYPE mensaje SYSTEM ""> <mensaje idMensaje=”” idMensajeAck=””>
<conjuntoInstrucciones idConjuntoInstrucciones=””> <instruccion idInstruccion=”” tipo=”” descripcionTipo=””> <texto> <identificacion></identificacion> <contrasenya></contrasenya> <informacion tipo=”” descripcionTipo=””></informacion> </texto>
<dispositivo idModulo=”” idDispositivo=”” tipo=”” pin=“” valor=””/> </instruccion>
</conjuntoInstrucciones> </mensaje>
En primer lugar, los únicos elementos que se mantienen iguales en todos los
mensajes son el elemento <?xml version=”1.0” encoding=” ISO-8859-1”
standalone=”no”?> y el elemento <!DOCTYPE mensaje SYSTEM "">. El resto de
los elementos y atributos que dan formato a la información del protocolo intercambiada
entre nodos se detalla a continuación:
• El elemento <mensaje> representa un mensaje intercambiado entre el
cliente y el servidor o viceversa. Un elemento <mensaje> puede
Sistema de automatización y control DOM
106
contener únicamente 1 elemento <conjuntoInstrucciones>. El atributo
idMensaje identifica unívocamente cada uno de los mensajes
transmitidos por cualquier nodo del sistema durante la comunicación.
Estos identificadores serán inicializados de forma aleatoria en cada uno
de los nodos participantes en la comunicación. Además, los
identificadores se irán incrementando en uno a partir del valor tomado
inicialmente, volviendo al valor 1 cuando se haya producido
rebosamiento. Por su parte, el atributo idMensajeACK fue concebido
inicialmente con la idea de confirmar la recepción, por parte del
interlocutor, de un mensaje enviado con anterioridad. Actualmente, el
protocolo no utiliza este campo para realizar confirmaciones pues deja
esta función en manos del protocolo TCP, que es el protocolo de
transporte empleado por HTTP, y su mecanismo de envío y recepción de
confirmaciones ACK.
NOTA: Se excluye el cero del rango de valores posibles para el atributo
idMensaje, ya que este valor será utilizado en el atributo
idMensajaACK, no para confirmar la recepción del mensaje con
idMensaje a cero, sino para indicar que el mensaje actual no está
confirmando ningún mensaje recibido con anterioridad.
• El elemento <conjuntoInstrucciones> representa el conjunto de
instrucciones transmitidas entre el nodo cliente y el servidor en un
instante de tiempo concreto. Un elemento <conjuntoInstrucciones>
puede contener de 0 a n elementos <instruccion>, siendo n de 1 a ∞. Si
<instruccion> contiene cero elementos significará que se está realizando
una Lectura “Hard” o que se trata de una instrucción de tipo
Acknowledge reply que confirma una repuesta desde la PDA al servidor.
El atributo idConjuntoInstrucciones identifica unívocamente un
conjunto de instrucciones en la secuencia de comunicación del protocolo,
siendo su valor igual al del atributo idMensaja del elemento
<mensaje>.
Proyecto fin de carrera
107
• El elemento <instruccion> representa una instrucción transmitida entre
el nodo cliente y el servidor. El atributo idInstruccion identifica
unívocamente una instrucción dentro del grupo de instrucciones
transmitidas de manera simultánea. El atributo tipo identifica el tipo de
instrucción realizada (1, 2, 3, 4, 5, 6, 7, 8, y 9). El atributo
descripcionTIpo describe el tipo de instrucción solicitada (Lectura
“Hard”, Escritura “Hard”, Respuesta OK, Respuesta Error, Respuesta
Wait, Respuesta Configuración, Respuesta “Hard”, Conexión y
Desconexión). Un elemento <instruccion> debe contener
exclusivamente bien un elemento <texto> bien un elemento
</dispositivo>, o nada. Si la instrucción contiene cualquier otra
información (autenticación, mensajes informativos…) entonces el
elemento <instrucción> contendrá un elemento <texto>.
NOTA: La instrucción Conexión enviará al servidor la información
necesaria para poder dar inicio al proceso de transmisión de instrucciones
(<identificacion><contrasenya>). El servidor responderá a este
mensaje retornando el archivo config.xml, donde reside la configuración
del sistema, confirmando a su vez la recepción de la instrucción de
conexión enviada anteriormente. Además, la instrucción Desconexión
permitirá dar por finalizado el proceso de comunicación, procediendo a la
correspondiente liberación de recursos.
Por otra parte, existen otros cinco tipos de instrucciones: Lectura “Hard”,
Escritura “Hard”, Respuesta, Conexión y Desconexión. Las denominadas
Lectura “Hard” y Escritura “Hard” están destinadas a realizar lecturas y
escrituras sobre los sensores/actuadotes. Una instrucción del tipo Lectura
“Hard” será confirmada por medio de una instrucción Respuesta “Hard”.
La instrucción Lectura “Hard” será solicitada automáticamente por el
sistema con la periodicidad que se requiera, siendo a su vez respondida
de forma automática por el sistema central.
Finalmente, la instrucción Respuesta (Respuesta OK, Respuesta Error,
Respuesta Wait, Respuesta Configuración, Respuesta “Hard”) pretende
Sistema de automatización y control DOM
108
indicar el estado en que se encuentra una solicitud de operación realizada
con anterioridad.
• El elemento <texto> representa el contenido de una instrucción cuando
esta no contiene información de dispositivo o fichero. El elemento
<texto> puede, bien contener a los elementos <identificacion> y
<contrasenya> bien al elemento <informacion>, pero nunca cualquier
otra combinación de estos.
• El elemento <identificacion> representa la identificación requerida por
el Sistema para autenticarse frente al mismo.
• El elemento <contrasenya> representa la contraseña requerida por el
Sistema para autenticarse frente al mismo.
• El elemento <informacion> representa cualquier otra información de
carácter alfanumérico que deba ser intercambiada entre el nodo cliente y
el servidor. El atributo tipo determina el carácter de la información
transmitida. El atributo descripcionTipo detalla con una cadena de texto
el tipo de información transmitida.
• El elemento <dispositivo> representa el dispositivo (sensor/actuador)
sobre el cual se va a realizar la operación de lectura o escritura definida
en el elemento <instruccion> al que pertenece este elemento. El atributo
idModulo identifica unívocamente el módulo dentro del inmueble. El
atributo idDispositivo identifica unívocamente el dispositivo dentro del
inmueble. El atributo pin identifica el pin dentro del módulo en cuestión.
El atributo valor contiene los nuevos datos que deben ser escritos en el
actuador. El atributo tipo identifica el tipo de actuador sobre el que
estamos realizando la acción. Los valores que admite el atributo tipo son
PWM y 01.
Proyecto fin de carrera
109
3.4.2 Archivo config.xml
La principal misión de este archivo en el Sistema es almacenar la configuración
del sistema físico, es decir, cuáles, cuántos y cómo están distribuidos en cada uno de los
espacios del inmueble los sensores y los actuadotes que integran el Sistema. A partir de
la información almacenada en este archivo se construirá una jerarquía visual que
permitirá monitorizar y controlar cada uno de los dispositivos de cada una de las
dependencias del inmueble. Por último, este archivo debe ser actualizado con las
modificaciones que se realicen sobre el sistema físico. Cualquier cambio que se realice,
tanto en la adhesión o en la eliminación de sensores y actuadotes como en la forma en
que se disponen en el inmueble, deberá ser registrada en este archivo para que exista
una correspondencia exacta entre la realidad y la representación software.
A continuación se muestra la estructura XML general de elementos y atributos
de almacenamiento de la configuración del sistema físico:
<?xml version=”1.0” encoing=”ASCII” standalone=”yes”?> <Edificio nombre=””> <Planta numero=””> <Habitacion tipo=”” descripcionTipo=””> <HIndice id=”” nombre=””> <Modulo id=””> <Dispositivo id=”” tipo=”” descripcionTipo=”” nombreModelo=”” descripcionModelo=”” pin=””> <Analogico texto=”” descripción=”” clase=”” valorMax=”” valorMin=”” unidades=””/> <Digital texto=”” descripción=”” clase=””/> </Dispositivo> </Modulo> </HIndice> </Habitacion> </Planta> </Edificio>
Los elementos y atributos que forman parte de esta estructura XML se detallan a
continuación:
• El elemento <Edificio> representa el inmueble donde se instalará el
sistema de control y automatización. Un elemento <Edificio> puede
contener tantos elementos <Planta> como plantas tenga el inmueble. El
Sistema de automatización y control DOM
110
atributo nombre proporciona, como el propio atributo sugiere, un
nombre con el que identificar al inmueble.
• El elemento <Planta> representa una planta del inmueble. El elemento
<Planta> puede contener tantos elementos <Habitación> como
habitaciones diferentes haya en el inmueble. El atributo numero indica
la posición que ocupa la planta en cuestión dentro del inmueble.
• El elemento <Habitacion> representa un tipo de habitación de una
planta del inmueble. El atributo tipo indica la tipología de la habitación.
A este respecto, se han definido una serie de valores para este atributo
tales como H1, H2, H3, H4, H5, H6, H7, H8. Estos valores tienen su
correspondiente descripción en el atributo descripciónTipo tales como
Salón, Habitación, Cocina, Pasillo, Servicios, Terraza, Garaje,
Exteriores.
• El elemento <HIndice> representa, dentro cada una de las tipologías
definidas, una habitación física del inmueble. Por ejemplo, si hay dos
despachos en una planta, existirá un elemento <Habitacion> que
recogerá la existencia de dicha tipología, y dos elementos <HIndice>
que recogerán la existencia de dos habitaciones físicas de tipo despachos.
Los atributos de este elemento son id y nombre. El primero .identifica
unívocamente una habitación de una tipología concreta dentro de una
planta del inmueble determinada. El segundo, por su parte, dota de un
nombre concreto a la habitación física. Por otra parte, un elemento
<HIndice> no tiene ninguna restricción para contener tanto elementos
<Modulo> como se quiera, la única limitación aquí será el propio
sentido común.
• El elemento <Modulo> representa un módulo dentro del inmueble. Un
módulo puede dar cabida a un número determinado de sensores y
actuadores. Concretamente, un elemento <Modulo> puede contener
tantos elementos <Dispositivo> como pines haya disponibles en el
Proyecto fin de carrera
111
mismo. El atributo id identifica unívocamente un módulo dentro del
inmueble.
• El elemento <Dispositivo> representa un dispositivo asociado a un
módulo que se encuentra en una dependencia de una planta del inmueble.
Un dispositivo en este contexto puede ser tanto un sensor como un
actuador. Además, ese dispositivo puede ser de tipo analógico o digital,
quedando reflejada esta naturaleza según se contenga un elemento
<Analogico> o <Digital> respectivamente. Por tanto, un elemento
<Dispositivo> deberá contener al menos un elemento <Analógico> o
<Digital>, pero en ningún caso mas de uno. Este elemento cuenta con un
grupo nutrido de atributos que pretenden detallar las características del
dispositivo. El atributo id identifica unívocamente al sensor o actuador
dentro del modulo en el que se encuentra contenido. Es importante
especificar que es posible que exista otro dispositivo con el mismo
identificador dentro de otro módulo diferente, pero esto no supone
ningún problema para el correcto funcionamiento del Sistema. El atributo
tipo determina el tipo de dispositivo electrónico, habiéndose definido
cuatro valores para dicho atributo tales como S1, S2, A1, A2. Estos
valores encuentran una descripción en el atributo descripcionTipoque
puede contener los valores Sensor_analogico, Sensor_digital,
Actuador_tipo_0/1, Actuador_tipo_PWM respectivamente. Por otro lado,
el atributo nombreModelo define el nombre del modelo de sensor o
actuador utilizado, mientras que el atributo descripcionModelo
proporciona una descripción del modelo. Finalmente, el atributo pin
determina el pin que utilizará el dispositivo dentro del módulo, no
pudiendo coincidir con el pin empleado por otro dispositivo en el mismo
módulo.
• El elemento <Analogico> representa una tipología de sensor o actuador,
según haya quedado definido en el atributo tipo del elemento
<Dispositivo>. El elemento <Analogico> posee seis atributos. El
primero es texto que asocia un texto alfanumérico a la representación
gráfica del dispositivo. El segundo es descripción que amplia la
Sistema de automatización y control DOM
112
información provista por el atributo anterior. El tercero es clase que
viene a indicar el archivo.class que será empleado para realizar una
representación grafica del dispositivo en la interfaz de usuario. El cuarto
y el quinto son valorMax y valorMin que, dado que el elemento descrito
es de tipo analógico, servirán para establecer el rango de valores con el
que trabaja dicho dispositivo. El sexto y último atributo es unidades que
pretende proporcionar las unidades con las que trabaja el dispositivo,
solamente con fines informativos.
• El elemento <Digital> es la otra variante de la tipología que puede
contener el elemento <Dispositivo>. Los tres atributos de este elemento
son exactamente los mismos que los tres primeros del elemento
<Analogico>.
Proyecto fin de carrera
113
3.4.3 Archivo historico.xml
La función principal que desempeña el archivo historico.xml en el Sistema es
almacenar los últimos datos relativos al estado actual de los sensores y actuadores.
Estos datos son almacenados en dicho archivo por el sistema físico paralelo, mientras
que de su recuperación periódica se encarga el Sistema de control y automatización
DOM. La actualización periódica de este archivo por parte del sistema físico es
fundamental, de otra forma los datos que recuperaría el Sistema de control y
automatización DOM no estarían reflejando la realidad de las magnitudes de medida
propias del entorno en el que está ubicado el inmueble (temperatura, luminosidad,
movimiento…)
A continuación se muestra la estructura XML general de elementos y atributos
que almacena los últimos valores recuperados desde los dispositivos electrónicos del
sistema físico:
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ?>
<Historico>
<Modulo id="">
<Dispositivo idDispositivo="" valor=""/>
</Modulo>
</Historico>
Los elementos y atributos que forman parte de esta estructura XML se detallan a
continuación:
• El elemento <Historico> representa una agrupación de módulos con sus
respectivos dispositivos. Este elemento puede contener tantos elementos
<Modulo> como módulos existan en el Sistema. Realmente, el elemento
<Historico> no tiene ninguna función especial, simplemente pretende
ofrecer un elemento raíz para el archivo XML que permita agrupar
elementos de nivel inferior, es este caso los elementos de tipo
<Modulo>.
Sistema de automatización y control DOM
114
• El elemento <Modulo> representa un módulo ubicado en un punto
cualquiera del inmueble. Este elemento tiene la intención de agrupar
dispositivos por módulo, pudiendo contener un máximo de elementos
<Dispositivo> igual al número de pines disponibles en el módulo. El
atributo id pretende identificar de forma unívoca un módulo dentro del
inmueble.
• El elemento <Dispositivo> representa un dispositivo del que se está
recuperando un valor en un momento determinado. Este elemento tiene
dos atributos. El primero de ellos es idDispositivo que identifica al
dispositivo de forma unívoca en el propio módulo donde esta ubicado. El
segundo es valor que como su nombre indica recupera el valor del
dispositivo.
Proyecto fin de carrera
115
3.4.4 Archivo actualizacion.xml
El archivo actualizacion.xml tiene como función principal almacenar las últimas
modificaciones realizadas sobre los actuadotes por el usuario. Dichas modificaciones
serán transmitidas posteriormente al sistema físico que las aplicará sobre los actuadotes
implicados. En este caso, será el Sistema de control y automatización DOM el
encargado de llenar con datos el archivo para que, posteriormente, sea consumido por el
sistema físico paralelo. La actualización de este archivo, a diferencia de historico.xml,
no se realiza de forma periódica si no a petición del usuario.
A continuación se muestra la estructura XML general de elementos y atributos
que almacena las últimas modificaciones realizadas sobre los actuadotes por parte del
usuario:
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<Actuadores>
<Modulo idModulo="">
<Dispositivo idDispositivo="" pin="" valor=""/>
</Modulo>
</Actuadores>
Los elementos y atributos que forman parte de esta estructura XML se detallan a
continuación:
• El elemento <Actuadores> no tiene ninguna función especial, simplemente
pretende ofrecer un elemento raíz para el archivo XML que permita contener un
elemento de tipo <Modulo>.
• El elemento <Modulo> representa un módulo ubicado en un punto cualquiera
del inmueble. Este elemento agrupa los dispositivos que han sido actualizados
por el usuario, pudiendo contener un máximo de elementos <Dispositivo> igual
al número de pines disponibles en el propio módulo. El atributo id pretende
identificar de forma unívoca un módulo dentro del inmueble.
Sistema de automatización y control DOM
116
• El elemento <Dispositivo> representa un dispositivo que se ha actualizado, en
este caso siempre será un actuador ya que los sensores solo pueden ser
monitorizados y no controlados. Este elemento tiene tres atributos. El primero de
ellos es idDispositivo que identifica al dispositivo de forma unívoca en el propio
módulo donde esta ubicado. El segundo es pin que determina el pin que utilizará
el dispositivo dentro del módulo para realizar la actualización del actuador. Y el
tercero es valor que como su nombre indica asigna un nuevo valor al actuador
que esta siendo actualizado.
Proyecto fin de carrera
117
3.4.5 Archivo contraseña.txt
El archivo contraseña.txt almacena las duplas formadas por identificador de
usuario y contraseña. Esta dupla está separada por el carácter ‘:’, de manera que el
proceso que lee dicho archivo sepa discernir de un identificador de usuario y la
contraseña perteneciente al mismo. Cada una de las filas del archivo almacena una
dupla para un nuevo usuario.
3.4.6 Archivo log.txt
El archivo log.txt registra las acciones que los usuarios realizan en el Sistema.
Cada uno de los registros del archivo representa una operación realizada por un usuario
en la fecha y la hora especificados. Estos registros están formados por un número entero
que indica el orden en el que ocurrieron las acciones, la fecha y la hora, el usuario que
invoco la acción y un texto que detalla que acción fue realizada por el usuario o el
Sistema.
Proyecto fin de carrera
119
4. RESULTADOS
4.1 CASOS DE USO
Los casos de uso pretenden ofrecer una visión detallada del modo en que
funciona el Sistema en determinadas circunstancias. Inicialmente, para cada caso de
uso, se presenta el escenario de partida desde el que se desea realizar la acción
especificada. Este escenario tiene una serie de elementos
4.1.1 Inicio de sesión en el Sistema
Tipo usuario: Usuario estándar
Acción objetivo: Se pretende iniciar sesión en el Sistema de automatización y control
DOM.
Acciones previas: Anteriormente al inicio de sesión en el Sistema, el usuario deberá
haber iniciado una instancia del navegador web tecleando la dirección de acceso al
servicio en la barra de dirección del mismo. La dirección que se debe teclear es la
siguiente: http://localhost/proyecto.html.
Restricciones: El usuario que deseé iniciar sesión en el Sistema deberá contar con un
identificador de usuario y una contraseña dados de alta en el Sistema, concretamente en
el archivo contrasenya.txt.
Caso de uso: En primer lugar, cuando un usuario quiere acceder al Sistema s necesario
que cumplimente toda la información que aparece en la ventana de autenticación que se
carga automáticamente en su navegador una vez que a tecleado la dirección URL
mencionada anteriormente. La información requerida es el nombre DNS o dirección IP
del servidor que le va a proporcionar el servicio, y por tanto el que debe validarle, el
identificador de usuario y la contraseña, que han debido serle proporcionados
previamente.
Una vez introducida la información, pulsando el botón Aceptar la aplicación
cliente abrirá un canal de comunicación al servidor que proporciona el servicio,
utilizando la dirección IP provista anteriormente, un protocolo de transmisión, un puerto
y un directorio en el servidor web donde encontrar el servlet que va a tratar la
información enviada. Dicho canal será utilizado para enviar los datos introducidos en la
Sistema de automatización y control DOM
120
ventana de autenticación. Además, este canal es aprovechado por el servidor para
responder al usuario que realizó la petición original. Esto se hace fundamentalmente
para ahorrar recursos, aumentando la eficiencia del proceso de respuesta.
Cuando el servidor web recibe la petición HTTP, éste la redirecciona al servlet
especificado, en este caso /servlet/prj.server.DOMServerManagement. Inicialmente,
este servlet comprueba si el navegador web del usuario ha insertado una cookie en el
lugar del mensaje de request que corresponde. Esta comprobación es necesaria porque
los usuarios identifican el estado de su sesión a través de estas cookies. En caso de que
el usuario no proporcione una cookie, cosa que sucederá pues es la primera vez que
accede al servicio, el Sistema generará un identificador único, al tiempo que construye
un contexto del estado de la sesión del usuario en memoria, que asignará al usuario y
que éste, a su vez, devolverá en forma de cookie en sucesivas peticiones.
A continuación, utilizando este contexto y el identificador de la acción que el
usuario desea ejecutar, que viene insertado en el mensaje, el Sistema es capaz de
ejecutar la dicha acción. Para esto, se emplea una tabla de decisión (sección 3.2.2.3
Comportamiento) que permite saber, dado el estado actual en el que se encuentra la
sesión del usuario y la acción solicitada a través del mensaje, si es posible o no ejecutar
la acción en cuestión y cual será el estado en que quedará el sistema después ejecutarla.
En el caso de la acción de inicio de sesión, si se mira la tabla de decisión citada, se
puede comprobar que es únicamente posible estando la sesión del usuario en estado 0.
NoAutenticado, y recibiendo el mensaje de tipo Conexión, lo que provocaría una
transición al estado 0. NoAutenticado al estado 2. RespuestaOK o 3. RespuestaError, en
función de si la operación se ha realizado con o sin éxito.
Una vez que el Sistema a determinado que la acción solicitada está permitida en
el contexto de la sesión se comprueba que el usuario a proporcionado correctamente la
información de inicio de sesión, identificador de usuario y contraseña. Para ello se
recorre el archivo contrasenya.txt ubicado en el servidor web en busca de una pareja de
identificador de usuario y contraseña que coincida con la información proporcionada
por el usuario. Si la información provista es correcta el usuario accederá a la ventana de
gestión de los dispositivos electrónicos, en caso contrario recibirá un mensaje de error
debiendo realizar el proceso de inicio de sesión nuevamente.
Proyecto fin de carrera
121
4.1.2 Recopilación periódica de datos de los sensores
Tipo usuario: Usuario estándar
Acción objetivo: Se pretende actualizar el interfaz de usuario de forma periódica con
datos procedentes de los sensores del Sistema.
Acciones previas: Previo a empezar a actualizar el interfaz de la aplicación cliente con
información procedente de los sensores, el usuario ha debido iniciar sesión en el
Sistema. Después, éste ha tenido que seleccionar el módulo de la habitación cuyos
sensores desea empezar a monitorizar.
Restricciones: Cada dos segundos, el Sistema envía información actualizada
procedente de los sensores a la aplicación cliente. Al tratarse de una aplicación de
tiempo real ‘sof’ no es necesario, aunque sí deseable, que se respete el intervalo de
tiempo fijado de dos segundos entre la llegada de datos actualizados. Esta restricción
temporal se debe al hecho de que algunos sensores, como es el caso del sensor de
movimiento, no son capaces de mantener activa la señal de detección de un
determinado evento más de dos segundos. Por tanto, si el intervalo de refresco de datos
del Sistema fuera mayor de dos segundos se correría un riesgo de no detección del
evento.
Caso de uso: Una vez que el usuario ha obtenido acceso al Sistema, en el panel de la
izquierda de la ventana de administración de dispositivos se cargará automáticamente la
jerarquía de disposición, que permitirá al usuario navegar hasta la habitación del
inmueble que desea monitorizar y controlar. Esta jerarquía de navegación es generada
de forma automática por la aplicación cliente a partir del archivo de configuración
config.xml enviado por el servidor cuando el inicio de sesión ha sido correcto. El
contenido de dicho archivo es interpretado, mediante la utilización de un parseador, que
es utilizado para construir de forma flexible y automática la jerarquía.
Una vez que se ha cargado completamente la jerarquía, es posible acceder al
espacio del inmueble que se desea monitorizar o controlar. Si se selecciona uno de los
módulos de dicho espacio, se cargan automáticamente, en el panel derecho de la
ventana de administración de dispositivos, los sensores y actuadores del módulo. Acto
seguido, se lanza un proceso en modo secundario, para que no afecte al proceso
principal que gestiona el comportamiento del interfaz de usuario, el cual recopila los
datos de los sensores en función del intervalo de tiempo establecido, dos segundos en
Sistema de automatización y control DOM
122
este caso. Por tanto, la aplicación cliente recibirá cada dos segundos datos actualizados
desde los sensores. Estos datos serán utilizados para ir modificando el aspecto del
interfaz de usuario de manera que éste sea capaz de representar la información que le
llega desde los sensores de forma inteligible para el usuario.
Para intentar degradar el rendimiento del Sistema lo menos posible, la
comunicación entre el componente Cliente y el Servidor se realiza utilizando un
segundo servlet. Por tanto, mientras un primer sevlet supervisa la ejecución de tareas
tales como el inicio o fin de sesión, la transmisión del archivo de configuración o la
modificación del comportamiento, un segundo servlet gestiona el proceso de
distribución periódica de datos. En todo momento se ha pretendido evitar que un
proceso periódico pudiera penalizar el funcionamiento de otro proceso esporádico.
El mecanismo utilizado en este segundo servlet es el mismo que en el anterior.
Por un lado el cliente envía solicitudes de lectura de los sensores, mediante el envío de
mensajes del protocolo de control embebidos en mensajes HTTP, mientras que por otro
lado el servidor responde a esos mensajes con el envío de mensajes de respuesta de
lectura de los sensores, que también embebe en mensajes HTTP.
4.1.3 Control del comportamiento de los actuadores
Tipo usuario: Usuario estándar
Acción objetivo: Se pretende controlar el comportamiento de los actuadores del
Sistema de forma remota.
Acciones previas: Antes de realizar cualquier acción que permita controlar el
comportamiento de cualquiera de los actuadores que integran el Sistema, el usuario ha
debido iniciar sesión en el Sistema. Después, éste ha tenido que seleccionar el módulo
de la habitación cuyos dispositivos de actuación desea controlar.
Restricciones: Únicamente es posible tomar acciones simultáneamente sobre los
actuadores que se encuentran en un mismo módulo.
Caso de uso: Una vez que el usuario ha obtenido acceso al Sistema, en el panel de la
izquierda de la ventana de administración de dispositivos se cargará automáticamente la
jerarquía de disposición, que permitirá al usuario navegar hasta la habitación del
Proyecto fin de carrera
123
inmueble que desea monitorizar y controlar. Una vez allí, en usuario seleccionará el
módulo donde se encuentran el/los actuador/es cuyo comportamiento desea controlar.
El funcionamiento interno del proceso de control de los sensores del Sistema es
similar a la forma en que se comporta el Sistema para recabar información de los
sensores y enviarla a la aplicación cliente. Sólo que, en este caso, los mensajes que
intercambian cliente y servidor son mensajes de solicitud de acción sobre un actuador y
respuesta del éxito o fracaso de la ejecución de dicha solicitud. La forma de
intercambiarlos es la misma que la utilizada en la recuperación de datos desde los
sensores, es decir, se continúa utilizando el protocolo HTTP como protocolo
subyacente.
Cuando un usuario ha accedido al módulo donde se encuentra el actuador que
desea gestionar, éste utiliza el interfaz de dicho actuador para definir un nuevo
comportamiento para el mismo. En el caso de los actuadores, a pesar que el interfaz de
los mismos es actualizado con la misma periodicidad que el de los sensores,
simplemente por el hecho de monitorizar el comportamiento que están teniendo en el
momento actual, una vez que sus interfaces han sido modificados ya no admiten ser
refrescados, para permitir al usuario enviar los nuevos parámetros de comportamiento
que ha seleccionado. Una vez que estos parámetros han sido establecidos, sólo se
requerirá apretar el botón Aceptar y las información será enviada, recibiendo un
mensaje de respuesta del éxito o fracaso de la operación.
El funcionamiento de la operación de envío del mensaje de solicitud de acción
sobre un actuador es exactamente igual que el del mensaje de solicitud de inicio de
sesión. En primer lugar se abrirá un canal de comunicación hacia el servidor que
proporciona el servicio, utilizando la dirección IP provista en la ventana de
autenticación, un protocolo de transmisión, un puerto y un directorio en el servidor web
donde encontrar el servlet que va a tratar la información enviada. Dicho canal será
utilizado para enviar los datos de control de comportamiento del actuador o actuadores
seleccionados, ya que es posible enviar un mensaje para controlar el comportamiento de
varios actuadores, siempre y cuando se encuentren en el mismo módulo. Además, este
canal será aprovechado por el servidor para responder al usuario que realizó la petición
original, ahorrando recursos y aumentando la eficiencia del proceso de respuesta.
Sistema de automatización y control DOM
124
4.2 Secuencia intercambio de mensajes del protocolo de control DOM
A continuación se muestra de forma detallada lo que podría considerarse una
secuencia típica de intercambio de mensajes entre nodos del Sistema empleando el
Protocolo de control DOM 1.0, documentado con anterioridad en el apartado 2.3
Modelo conceptual de datos:
Paso 1. Establecimiento de conexión (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5505” idMensajeAck=”0”>
<conjuntoInstrucciones idConjuntoInstrucciones=”5505”> <instruccion idInstruccion=”1” tipo=”8” descripcionTipo=”conexion”> <texto> <identificacion>[email protected]</identificacion> <contrasenya>xxxx</contrasenya> </texto>
</instruccion> </conjuntoInstrucciones>
</mensaje> Paso 2. Contraseña errónea (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23588” idMensajeAck=”5505”>
<conjuntoInstrucciones idConjuntoInstrucciones=”23588”> <instruccion idInstruccion=”1” tipo=”4” descripcionTipo=”respuestaError”> <texto>
<informacion tipo=”2” descripcionTipo=”error”>Contrasenya errónea</informacion>
</texto> </instruccion>
</conjuntoInstrucciones> </mensaje>
Paso 3. Confirmación de la respuesta (Acknowledge-reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5506” idMensajeAck=”23588”>
<conjuntoInstrucciones idConjuntoInstrucciones=”5506”> <instruccion idInstruccion=”1” tipo=”3” descripcionTipo=”respuestaOk”> </instruccion>
Proyecto fin de carrera
125
</conjuntoInstrucciones> </mensaje>
Paso 4. Nuevo intento de establecimiento de conexión (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5507” idMensajeAck=”0”>
<conjuntoInstrucciones idConjuntoIntrucciones=”5507”> <instruccion idInstruccion=”1” tipo=”8” descripcionTipo=”conexion”> <texto> <identificacion> [email protected] </identificacion> <contrasenya>xxxx</contrasenya> </texto>
</instruccion> </conjuntoInstrucciones>
</mensaje> Paso 5. Contrasenya correcta (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23589” idMensajeAck=”5507”>
<conjuntoInstrucciones idConjuntoInstrucciones=”23589”> <instruccion idInstruccion=”1” tipo=”6” descripcionTipo=”respuestaConfig”> <texto>
<informacion tipo=”3” descripcionTipo=”datos”> <![CDATA[<Archivo de configuración XML>]]> </informacion>
</texto> </instruccion>
</conjuntoInstrucciones> </mensaje>
Paso 6. Archivo de configuración recibido (Acknowledge-reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5508” idMensajeAck=”23589”>
<conjuntoInstrucciones idConjuntoInstrucciones=”5508”> <instruccion idInstruccion=”1” tipo=”3” descripcionTipo=”respuestaOk”> </instruccion> </conjuntoInstrucciones> </mensaje>
Sistema de automatización y control DOM
126
Paso 7. Petición de lectura sensores (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5509” idMensajeAck=”0”>
<conjuntoInstrucciones idConjuntoInstrucciones=”5509”> <instruccion idInstruccion=”1” tipo=”1” descripcionTipo=”lecturaHard”>
</instruccion> </conjuntoInstrucciones>
</mensaje> Paso 8. Respuesta de lectura sensores (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23590” idMensajeAck=”5509”>
<conjuntoInstrucciones idConjuntoInstrucciones=”23590”> <instruccion idInstruccion=”1” tipo=”7” descripcionTipo=”respuestaHard”> <texto>
<informacion tipo=“3” descripcionTipo=”datos”> <![CDATA[<Archivo XML histórico>]]> </informacion>
</texto> </instruccion>
</conjuntoInstrucciones> </mensaje> Paso 10. Escritura en actuador (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5511” idMensajeAck=”0”>
<conjuntoInstrucciones idConjuntoInstrucciones=”55011”> <instruccion idInstruccion=”1” tipo=”2” descripcionTipo=”escrituraHard”>
<dispositivo idModulo=”7” idDispositivo=”76” pin=“23” valor=”25” tipo=”PWM”/>
</instruccion> <instruccion idInstruccion=”2” tipo=”2” descripcionTipo=”escrituraHard”>
<dispositivo idModulo=”7” idDispositivo=”77” pin=“1” valor=”0” tipo=”PWM”/>
</instruccion> </conjuntoInstrucciones>
</mensaje>
Proyecto fin de carrera
127
Paso 11. Escritura correcta (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23591” idMensajeAck=”5511”>
<conjuntoInstrucciones idConjuntoInstrucciones=”23591”> <instruccion idInstruccion=”1” tipo=”3” descripcionTipo=”respuestaOk”> <texto>
<información tipo=”1” descripcionTipo=”informacion”>Escritura completada</informacion>
</texto> </instruccion>
</conjuntoInstrucciones> </mensaje>
Paso 12. Confirmación de respuesta (Acknowledge-reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5512” idMensajeAck=”23591”>
<conjuntoInstrucciones idConjuntoInstrucciones=”5512”> <instruccion idInstruccion=”1” tipo=”3” descripcionTipo=”respuestaOk”> </instruccion> </conjuntoInstrucciones> </mensaje>
Paso 13. Desconexión (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5513” idMensajeAck=”0”>
<conjuntoInstrucciones idConjuntoInstrucciones=”5513”> <instruccion idInstruccion=”1” tipo=”9” descripcionTipo=”desconexion”> <texto> <identificacion>[email protected]</identificacion> <contrasenya>xxxx</contrasenya> </texto>
</instruccion> </conjuntoInstrucciones>
</mensaje>
Sistema de automatización y control DOM
128
Paso 14. Respuesta de desconexión (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23592” idMensajeAck=”5513”>
<conjuntoInstrucciones idConjuntoInstrucciones=”23592”> <instruccion idInstruccion=”5510” tipo=”3” descripcionTipo=”respuestaOk”> <texto>
<información tipo=”1” descripcionTipo=”informacion”>Gracias por usar el sistema</informacion>
</texto> </instruccion> </conjuntoInstrucciones>
</mensaje> Paso 15. Confirmación de respuesta (Acknowledge-reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5514” idMensajeAck=”23592”>
<conjuntoInstrucciones idConjuntoInstrucciones=”5514”> <instruccion idInstruccion=”1” tipo=”3” descripcionTipo=”respuestaOk”> </instruccion> </conjuntoInstrucciones> </mensaje>
Sistema de automatización y control DOM
130
5. CONCLUSIONES
5.1 Conclusiones finales
Las principales conclusiones que se pueden extraer tras la ejecución del
proyecto Sistema de automatización y control DOM, son las siguientes:
• En primer lugar, expresar la gran satisfacción personal que supone la
finalización del proyecto, y con él la consecución de los objetivos que fueron
fijados en un principio. Al mismo tiempo, también debo expresar una ligera
decepción por no haber sido capaz de llegar a integrar el sistema software con el
sistema hardware para el que fue diseñado, como era intención inicialmente.
• También me gustaría destacar el conocimiento técnico adquirido sobre áreas tan
diversas como los Sistemas de Tiempo Real, el funcionamiento de los sensores y
los actuadores, el Lenguaje Extensible de Marcas (XML) y los parseadores o el
diseño e implementación de soluciones software con tecnologías Java como son
applet y servlet.
• Por otra parte, desde un punto de vista más técnico, considero interesante
resaltar el espíritu original y el carácter innovador del proyecto, pues se ha
intentado desde un principio diseñar e implementar un sistema de tiempo real
que fuese gestionado a través de Internet, empleando para ello nuevas
tecnologías afines a la red.
• Producto del espectacular crecimiento que está experimentando Internet en los
últimos años, es un muy habitual encontrar un número cada vez mayor de
aplicaciones que migran de arquitecturas mas pesadas, como es el caso de la
arquitectura cliente-servidor tradicional, a arquitecturas mucho mas ligeras y
escalables, como es el caso de la arquitectura web. Esta es, sin lugar a dudas, la
línea de acción que ha pretendido seguir el proyecto desde su concepción inicial.
Esto ha implicado realizar un esfuerzo importante para adaptar el modo de
operar de un sistema de automatización y control en tiempo real, como es un
Proyecto fin de carrera
131
sistema domótico/inmótico, a las características que requiere Internet. Algo que
de alguna manera mas o menos acertada se ha logrado.
• Esta migración entre arquitecturas ha propiciado una convergencia entre
tecnologías que a priori podrían parecer totalmente independientes, como son la
domótica/inmótica y las tecnologías relacionadas con Internet (xml, servlet,
applet, HTTP, etc.)
• Desde el punto de vista comercial, esta convergencia favorece y extiende la
utilización de los sistemas domóticos/inmóticos a un segmento de mercado
mucho mayor ya que, como es evidente, la utilización de Internet así como de
las nuevas tecnologías que lo rodean está mucho mas extendida que cualquier
otro sistema domótico/inmótico propietario.
• Sin embargo, contrastando con todos estos aspectos positivos, también sería de
justicia comentar que la actual infraestructura de Internet y el modo de en que
funcionan las nuevas tecnologías no ofrecen suficientes garantías para la
implementación un sistema de tiempo real. Tendrá que pasar mucho tiempo
hasta que sea posible desarrollar un sistema comercial de este tipo que ofrezca
las suficientes garantías en lo que a tiempo de respuesta, disponibilidad,
fiabilidad, mantenibilidad y seguridad respecta.
Proyecto fin de carrera
133
6. FUTUROS DESARROLLOS
6.1 Futuros desarrollos
El Sistema de control y automatización DOM, una vez concluido el proyecto, es
plenamente operativo, realizando todas las tareas para las que fue concebido
inicialmente. Sin embargo, como cualquier otro sistema, es susceptible de ser mejorado
en multitud de aspectos. A continuación se citan algunos de los puntos que podrían ser
susceptibles de ser desarrollados en mayor profundidad:
• Actualmente, el Sistema es controlado completamente por el usuario. A partir de
las mediciones realizadas por los sensores el usuario puede decidir aplicar un
comportamiento u otro a los actuadores. Un futuro desarrollo muy interesante
sería intentar aplicar algo de inteligencia artificial al Sistema. Mediante la
utilización de reglas sería posible predefinir el comportamiento general del
Sistema ante la ocurrencia de una cadena de eventos.
• Otro punto del Sistema susceptible de ser mejorado es el interfaz de la
aplicación cliente. Actualmente, éste ha sido implementado mediante un applet
que permite al usuario sacar partido de todas las funcionalidades que ofrece el
Sistema. Sin embargo, los applet son sobradamente conocidos por ser grandes
consumidores de recursos. Un área de mejora que admitiría futuros desarrollos
sería buscar una alternativa a los applets para la aplicación cliente. Una solución
• En el Sistema actual no existe ningún mecanismo redundante que permita
recuperar el Sistema ante un fallo eventual. Sin embargo, el Sistema es capaz de
escribir en un archivo de log todas las acciones que va realizando de forma
secuencial. Quizás, un desarrollo futuro podría utilizar dicho log para recuperar
el Sistema hasta el momento actual, utilizando una técnica de tipo checkpoint-
recuperación.
Proyecto fin de carrera
135
MANUAL DE INSTALACIÓN Y CONFIGURACIÓN DEL SISTEMA
A continuación se describe de forma detallada el orden cronológico de los pasos
a seguir para instalar y configurar el Sistema. De esta manera es posible, en cualquier
momento, construir una replica exacta del entorno sobre el que se ha desarrollado el
Sistema.
1. Instalación y configuración del Sistema Operativo
El Sistema Operativo empleado es Windows XP en la versión Home Edition
2002. Además, el parche de mejoras y correcciones instalado es Service Pack 2.
2. Instalación del JDK 1.4.2 (Java Development Kit 1.4.2)
En primer lugar se requiere instalar y configurar Java. La especificación Servlet
y Java Server Pages utilizada es Servlet 2.4 (JSP 2.0), que requiere la instalación de
JDK 1.4 o posterior.
• JDK 1.4:
http://java.sun.com/j2se/1.4/download.html. Es conveniente asegurarse que se
descarga el JDK por completo (J2SE Development Kit), no sólo el JRE (Java
Runtime Environment). JRE únicamente permite ejecutar archivos .class ya
compilados; carece de compilador
Una vez que se ha instalado java, hay que corroborar que todo, incluyendo la
variable PATH, ha sido configurado adecuadamente. Esto puede comprobarse abriendo
una ventana de la consola y tecleando "java -version" y "javac -help". Si Java ha
sido instalado de forma correcta se debería obtener un mensaje, no un mensaje de error
de comando desconocido.
Sistema de automatización y control DOM
136
Existen dos alternativas para configurar la variable PATH:
• Escribiendo la siguiente línea en el archivo C:\autoexec.bat.
set PATH="C:\j2sdk1.4.2_10\bin";%PATH%
• Seleccionar Inicio � Configuración � Panel de control. Elegir el icono
Sistema, haciendo clic en el la solapa Avanzado, pulsar el botón Variables de
entorno situado al final de la pantalla, introduciendo el valor para la variable
PATH.
3. Instalación y configuración del servidor web Apache Tomcat 5.5.15
3.1 Descarga del software Apache Tomcat 5.5.15
El enlace para realizar la descarga del software Apache Tomcat 5.5.15 es
http://tomcat.apache.org/download-55.cgi. Además, también se deberá descargar el
archivo Compat.zip que permite la compatibilidad entre Tomcat y JDK 1.4.
Los ficheros se deben guardar en el PC, debiendo ser descomprimidos en la
ubicación elegida por el usuario. Por tanto, si se especifica un directorio de
descompresión tal como “C:\”, y el archivo .zip internamente incluye un directorio tal
como “apache-tomcat-5.5.15”, entonces el directorio resultante donde será instalado el
software será C:\apache-tomcat-5.5.17.
Nota: De ahora en adelante, esta localización será referida como install_dir.
3.2 Establecimiento de la variable JAVA_HOME
A continuación, es necesario establecer la variable JAVA_HOME que indica a
Tomcat el directorio donde está instalado Java. Esta variable debería listar el directorio
de instalación del JDK, no el directorio bin. Al igual que para la variable PATH, existen
dos formas de configurar la variable JAVA_HOME:
Proyecto fin de carrera
137
• Escribiendo la siguiente línea en el archivo C:\autoexec.bat.
set JAVA_HOME=C:\j2sdk1.4.2_10
• Seleccionar Inicio � Configuración � Panel de control. Elegir el icono
Sistema, haciendo clic en el la solapa Avanzado, pulsar el botón Variables de
entorno situado al final de la pantalla, introduciendo el valor para la variable
JAVA_HOME.
3.3 Establecer el puerto por defecto para HTTP a 80
Suponiendo que no exista otro servior web instalado en el PC que ya esté
empleando el puerto 80, será conveniente configurar Tomcat para atender las peticiones
recibidas en el puerto predeterminado de HTTP (80), en lugar del puerto 8080
configurado por defecto. Hacer este cambio permitirá utilizar URLs del tipo
http://localhost/recurso_solicitado en lugar http://localhost:8080/recurso_solicitado.
Algunas veces, el servidor web IIS (Internet Informatio Server) está configurado por
defecto para atender peticiones en el puerto 80, razón por la cual deberá ser
deshabilitado si se quiere que Tomcat utilice el puerto 80.
Para cambiar el puerto, es necesario editar el archivo install_dir/conf/server.xml
y cambiar el atributo puerto del elemento Connector de 8080 a 80, obteniendo un
resultado similar al siguiente:
<Connector port="80" ...
maxThreads="150" ...
3.4 Activar la característica Servlet Reloading
El siguiente paso consiste en configurar Tomcat para que detecte las fechas de
modificación de los archivos .class de los servlets solicitados, y proceder a la recarga de
aquellos que han cambiado después de que inicialmente fueran cargados en memoria.
La activación de esta característica produce una ligera degradación del rendimiento en
situaciones de desarrollo, por lo que dicha características está deshabilitada por defecto.
Sistema de automatización y control DOM
138
Sin embargo, no activar esta característica en un contexto de desarrollo supone reiniciar
el servidor web cada vez que se recompile una servlet que será cargado en memoria.
Para activar la característica Servlet Reloading, se edita el archivo
install_dir/conf/context.xml cambiando:
<Context>
a <Context reloadable="true">
3.5 Habilitando el Invoker Servlet
El Invoker Servlet es una característica del servidor web que permite ejecutar
los servlet sin tener que escribir un fichero web.xml en el directorio ‘WEB-INF’. Sólo
hay que arrastrar las clases del servlet dentro del directorio WEB-INF/classes y utilizar
la URL http://host/servlet/ServletName para invokar al servlet.
Para habilitar la caracteística Invoker Servlet se deben quitar los comentarios a
los elementos servlet y servlet-mapping del fichero web.xml del directorio
install_dir/conf:
<servlet>
<servlet-name>invoker</servlet-name>
<servlet-class>
org.apache.catalina.servlets.InvokerServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>
Invoker
</servlet-name>
<url-pattern>
/servlet/*
</url-pattern>
</servlet-mapping>
Proyecto fin de carrera
139
3.6 Comprobación de la instalación correcta del servidor
3.6.1 Verificación de que el servidor puede arrancar
Antes de ejecutar los servlets asociados a la aplicación se debería comprobar
que el servidor ha sido instalado y configurado adecuadamente. Para iniciar el servidor
se deberá ejecutar el archivo install_dir/bin/startup.bat. A continuación, se deberá
teclear la URL http://localhost/ en el navegador para obtener la página de bienvenida de
Tomcat, y no un mensaje de error diciendo que la página no puede ser mostrada o que
el servidor no ha sido encontrado.
Por otra parte, para detener el servidor web se deberá ejecutar el archivo
install_dir/bin/shutdown.bat. Como se detallará mas adelante, es recomendable obtener
accesos directos a los archivos startup.bat y shutdown.bat (no copias a ellos)
ubicándolos en el Escritorio de Windows XP o en el directorio principal de desarrollo
para iniciar o detener Tomcat de forma mas ágil.
3.6.2 Intentar ejecutar algunas páginas HTML y JSP sencillas
Después de haber verificado que el servidor se está ejecutando con normalidad,
se debería comprobar que es posible instalar y acceder a páginas HTML y JSP sencillas.
Si esta comprobación funciona correctamente mostrará dos cosas:
• En primer lugar, acceder a las páginas HTML y JSP significa que se ha
comprendido en qué directorios hay que ubicar las páginas HTML y las páginas
JSP, así como que URLs utilizar para acceder a las mismas.
• Además, acceder de forma satisfactoria a una página JSP implica que el
compilador de Java, no solamente la máquina virtual de Java, ha sido
configurada de forma correcta.
Por otra parte, y con fines de testeo, es posible utilizar la aplicación web por
defecto que ofrece Tomcat. Para ello, será necesario ubicar las páginas HTML y JSP en
Sistema de automatización y control DOM
140
el directorio install_dir/webapps/ROOT y accederlas empleando la URL
http://localhost/filename. Por ejemplo, si se quiere recuperar el recurso Hola.html del
servidor web, será necesario utilizar la URL http://localhost/Hola.html. Si, debido a
cualquier otra circunstancia, se decidiera ubicar el archivo Hola.html en un
subdirectorio dentro de install_dir/webapps/ROOT, la URL que se debería utilizar sería
http://localhost/nombreDirectorio/Hola.html.
Finalmente, si el servidor web fue inicializado correctamente, pero por el
contrario no es posible visualizar páginas HTML o JSP entonces, probablemente, se
está utilizando el directorio equivocado para los archivos. Pero si lo que funciona son
las páginas HTML y no las JSP es muy probable que se haya especificado de forma
incorrecta el directorio base del JDK para la variable JAVA_HOME.
3.6.3 Intentar compilar e instalar servlets
Una vez que se ha establecido el entorno de desarrollo, es necesario asegurarse
de verificar que se pueden compilar y ejecutar servlets sin ningún problema.
4. Configurar el entorno
El script de inicalización startup.bat establece el CLASSPATH del servidor de
manera que se incluya el servlet estándar y las clases JSP, así como el directorio WEB-
INF/classes, que contiene los servlets compilados de cada aplicación web. Pero son
necesarias configurciones similares, de lo contrario no será posible compilar servlets.
Configurar el sistema para desarrollar servlets inplica cuatro puntos.
4.1 Crear un directorio de desarrollo
En primer lugar, para configurar un entorno de desarrollo adecuado, es necesario
crear un directorio en el cual ubicar los servlets y las páginas JSP desarrolladas. Este
directorio puede estar en el directorio particular del usuario (C:\Documentsand
Settings\AlbertoCarrasco\Misdocumentos\Alberto\Servlets+JSP) o en cualquier otra
Proyecto fin de carrera
141
ubicación (C:\Servlets+JSP). Sin embargo, dicho directorio nunca debiera ser ubicado
en el directorio de distribución de Tomcat, en algún lugar dentro de
install_dir/webapps.
Al principio, este directorio estará organizado en diferentes aplicaciones web.
Además, con fines de testeo es posible ubicar servlets tanto directamente en el
directorio de desarrollo como en un subdirectorio que identifique el nombre del paquete
del servlet. Aunque desarrollar en el directorio de distribución de Tomcat parece más
sencillo al principio, ya que no requiere mantener copias de los archivos, esto complica
significativamente asuntos relacionados con la forma de funcionar del servidor. Mezclar
ubicaciones hace difícil separar una versión operativa de otra versión que está siendo
comprobada, hace difícil chequear en varios servidores, y hace que la forma de
organizarse sea mucho mas complicada. A pesar de esto, es muy probable que el PC
donde se está trabajando no sea el servidor de distribución definitivo, por lo que será
necesario configurar otra máquina para realizar las tareas de distribución.
Nota: Es importante que se tenga clara la diferencia entre el directorio de desarrollo,
empleado para realizar editar y modificar los fuentes, y el directorio de distribución que
es el lugar donde deben ser ubicados los servlets y/o páginas HTML y JSP que se quiere
sean accedidos por los clientes.
4.2 Crear accesos directos a los scripts que arrancan y detienen el Servidor
Resulta conveniente situar los accesos directos a los scripts que arrancan y
detienen el servidor en un lugar de fácil acceso, como pueda ser el propio directorio de
desarrollo o incluso el escritorio.
La forma mas sencilla de obtener dichos accesos directos es acudir al directorio
install_dir/bin y hacer clic con el botón derecho del ratón sobre el archivo startup.bat,
seleccionado la opción Copiar del menú emergente. Después, una vez que se está
posicionado en el directorio deseado, se hace clic con el botón derecho del ratón y se
selecciona la opción Pegar como acceso directo (nunca solamente Pegar). Se debe
repetir el proceso para el archivo install_dir/bin/shutdown.bat. Además, si se ubican en
Sistema de automatización y control DOM
142
el escritorio los accesos directos es posible asignar a éstos una combinación de teclas
que permita ejecutarlos.
4.3 Configuración de la variable de entorno Classpath
Dado que los servlets y las páginas JSP no son parte de la plataforma Java 2
Standard Edition (J2SE), es necesario identificar al compilador qué las clases emplea la
tecnología servlet. El servidor ya sabe qué clases requiere la tecnología servlet, así
como donde están ubicadas, pero al compilador (javac) que está siendo utilizado hay
que indicárselo. Por lo tanto, si no se establece la variable CLASSPATH, los intentos de
compilar sevlets, tag libraries, filters, wep app listeners u otras muchas clases que
utilizan las APIs de sevlet y JSP fallarán, generando mensajes de error acerca la
utilización de clases desconocidas. A continuación se muestran las ubicaciones estándar
de los archivos .jar necesarios para implementar lo anterior:
• install_dir/common/lib/servlet-api.jar
• install_dir/common/lib/jsp-api.jar
Ambos archivos necesitan ser incluidos en la variable CLASSPATH.
Por otra parte, además de incluir la ruta hacia el archivo .jar para servlet en la
variable CLASSPATH, también es necesario incluir en la variable la ruta al directorio de
desarrollo. Esto será conveniente cuando se desarrolle utilizando paquetes de usuario.
Compilar un archivo que está ubicado en un paquete, que además utiliza una clase que
se encuentra en un paquete definido por el usuario, requiere que la variable CLASSPATH
incluya el directorio de mayor nivel en la jerarquía de paquetes.
Finalmente, el directorio actual debería ser incluido en CLASSPATH. De otra
forma, solamente se podrán compilar clases que no pertenezcan a ningún paquete y que
se encuentren el nivel más alto del directorio de desarrollo.
Proyecto fin de carrera
143
Existen dos métodos para configurar la variable CLASSPATH:
• Editando y modificando el archivo autoexec.bat,
set CLASSPATH=.;
C:\Servlets+JSP;
install_dir\common\lib\servlet-api.jar;
install_dir\common\lib\jsp-api.jar
• Seleccionar Inicio � Configuración � Panel de control. Elegir el icono
Sistema, haciendo clic en el la solapa Avanzado, pulsar el botón Variables de
entorno situado al final de la pantalla, introduciendo el valor para la variable
CLASSPATH.
4.4 Guardar una referencia a la documentación del API de servlet y JSP
Es posible acceder a la documentación desde la home de Tomcat, pero
probablemente será necesario utilizar la documentación incluso si el servidor no está
corriendo. De esta manera, es recomendable guardar un acceso directo al API en el
escritorio o en cualquier otro lugar de fácil acceso.
Aquí se muestran las rutas por defecto donde se almacena la ayuda acerca de la API:
• Servlet API: install_dir/webapps/tomcat-docs/servletapi/index.html
• JSP API: install_dir/webapps/tomcat-docs/jspapi/index.html
5. Estableciendo un método de distribución sencillo
Ahora que ya se ha creado el directorio de desarrollo, es posible compilar
servlets que utilicen o no una jerarquía de paquetes. Se sabe a qué directorio pertenecen
las clases que requiere servlet. También se conoce qué URL utilizar para acceder a
Sistema de automatización y control DOM
144
dichos servlets (http://hostname/servlet/ServletName es la URL por defecto). Pero,
¿cómo se transportan los archivos .class desde el directorio de desarrollo al directorio
de distribución? En principio, la idea de copiar a mano cada vez los archivos de un
directorio a otro es un método que puede provocar errores.
La alternativa más interesante que permite simplificar este proceso es pegar un
acceso directo al directorio de distribución en el directorio de desarrollo. Para ello, una
vez posicionado en el directorio install_dir/webapps/ROOT/WEB-INF, se hace click
con botón derecho del ratón en el directorio classes y se selecciona Copiar. Entonces, se
acude al directorio de desarrollo, donde se hace clic en el botón derecho del ratón y se
selecciona Pegar como acceso directo (nunca solamente Pegar). Así, y de ahora en
adelante, cuando se compile un servlet sin paquetes solamente será necesario arrastrar
los archivos .class al acceso directo. Y cuando se desarrolle en paquetes, sólo será
necesario utilizar el ratón para arrastrar el paquete entero al acceso directo.
6. Instalando el IDE Eclipse 3.0
Eclipse 3.0 es una IDE que permite escribir, compilar y depurar aplicaciones
Java. Además, las funcionalidades de Eclipse pueden ser ampliadas si se instala
cualquiera de los plug-ins que hay disponibles en el mercado, muchos de ellos de forma
gratuita, que permiten realizar una amplia variedad de actividades, que van desde
controlar la versión de desarrollo de los archivos que integran el proyecto hasta realizar
tareas de ingeniería inversa para obtener diagramas UML desde código.
Eclipse 3.0 puede ser descargado, de forma gratuita, desde la página web de la
organización que lo ha desarrollado (http://www.eclipse.org/downloads/index.php).
Normalmente, las distribuciones se proporcionan en un archivo .zip. Una vez finalizada
la descarga, se procede a la instalación del software. Para ello, y puesto que Eclipse 3.0
todavía no facilita ningún ejecutable que facilite el proceso de instalación, se debe
descomprimir el archivo .zip en el directorio donde normalmente son instalados los
programas. Esto creará un directorio llamado eclipse. Un archivo ejecutable será
ubicado en dicho directorio con el nombre eclipse.exe. Es recomendable crear un acceso
directo a partir de este archivo que debiera ser ubicado en el escritorio de Windows XP.
Proyecto fin de carrera
145
Eclipse almacena todos proyectos que se van creando en un directorio llamado
área de trabajo. Cuando Eclipse es ejecutado por primera vez, éste preguntará donde se
debe emplazar el área de trabajo. Es posible utilizar la ubicación por defecto
seleccionando el directorio donde Eclipse fue instalado. En el caso que nos ocupa el
área de trabajo de Eclipse 3.0 ha sido ubicada en el directorio de desarrollo
anteriormente citado.
7. Ubicación de los archivos del Proyecto
Como se ha explicado a lo largo de este documento de Proyecto, el Sistema se
sirve de en un conjunto de archivos para poder desarrollar su actividad. A continuación
se citan los archivos que son necesarios para el funcionamiento del Sistema, así como el
directorio donde se ubican:
• Los archivos config.xml, actualizacion.xml, historico.xml, contraseña.txt y
log.txt se ubican en el directorio files, dentro de install_dir\webapps\ROOT.
• Los archivos b1.gif, b1r.gif y Log-Off.jpeg son archivos utilizados por el interfaz
de usuario de la herramienta cliente. Estos archivos se ubican en el directorio
install_dir\webapps\ROOT\images.
• El archivo aelfred.jar es un pequeño parseador que es descargado por el cliente
desde el servidor para permitirle interpretar el contenido de los streams XML
enviados por este último. Este archivo se ubica en el directorio
install_dir\webapps\ROOT/WEB-INF\classes.
8. Asignación de permisos mediante la utilización de un archivo java.policy
El archivo java.policy es un archivo que define una política global de permisos
para todas las aplicaciones Java que corren en la máquina virtual de Java del nodo que
implementa dicho archivo. Este archivo esta ubicado en el directorio personal que cada
usuario tiene asignado en Windows XP, C:\Documents and Settings\nombre_usuario.
Sistema de automatización y control DOM
146
De esta forma los permisos recogidos en un archivo java.policy son de aplicación única
y exclusiva en la sesión del usuario al que están asociados. El archivo de política global
de permisos utilizado en el Sistema es el siguiente:
grant codeBase "http://localhost/" {
ermission java.security.AllPermission;
};
grant codeBase "file:/C:/apache-tomcat-5.5.15/webapps/ROOT/WEB-INF/classes/" {
permission java.io.FilePermission "<<ALL FILES>>", "read";
};
Sistema de automatización y control DOM
148
MANUAL DE USUARIO
Este manual pretende servir de guía de usuario para la correcta utilización del
Sistema. A continuación se detalla el funcionamiento del interfaz de la aplicación que a
la postre servirá como elemento comunicador entre el usuario y el propio Sistema.
Además del interfaz de la aplicación, también se detallan otros elementos que son
utilizados para la gestión del Sistema, como es caso del log del Sistema.
1. Acceso al Sistema de automatización y control DOM
Para tener acceso al Sistema de automatización y control DOM es requisito
necesario teclear en la barra de dirección del navegador web la URL
http://localhost/proyecto.html. Esta dirección proporciona acceso al servicio que
soporta el Sistema.
La primera parte de la dirección (localhost) identifica el host donde se
encuentran los recursos a los que se quiere tener acceso. En este caso, localhost es un
nombre de host comodín empleado por el servicio DNS para hacer referencia al host
local. Este nombre de host es utilizado en este caso debido a que la máquina que se
quiere acceder es la misma desde la que se ejecuta el navegador web. El nombre de host
localhost mapea a la dirección IP 127.0.0.1, lo que implica que el recurso pudiera
haberse accedido tecleando en la barra de dirección del navegador la URL
http://127.0.0.1/proyecto.html. En el caso que el navegador web fuera ejecutado desde
una máquina distinta a la que almacena el recurso, entonces debería teclearse cualquiera
Proyecto fin de carrera
149
de las siguientes URL http://dirección_IP_local/proyecto.html, o también
http://nombre_host_local/proyecto.html. En el caso de la dirección IP local
posiblemente se requeriría utilizar una dirección IP privada si el Sistema quiere se
utilizado en una intranet, o una dirección IP pública si el Sistema va a ser utilizado
desde cualquier ordenador conectado a Internet. Mientras, en el caso del nombre de host
debería ser utilizado el nombre DNS empleado por el servidor de nombres que da
cobertura a esa parte de la red.
La segunda parte de la dirección identifica el nombre del recurso que se quiere
acceder en el host identificado con anterioridad. En este caso se trata del archivo
proyecto.html que lleva embebido un pequeño programa Java denominado applet, que
proporcionará el mecanismo de comunicación entre el usuario y el Sistema para acceder
a las funcionalidades que este último ofrece.
2. Pantalla de autenticación del usuario
La pantalla de autenticación del Sistema permite controlar el acceso al mismo,
de forma que solamente los usuarios autorizados puedan utilizar el servicio.
Sistema de automatización y control DOM
150
Esta ventana permite el acceso al Sistema únicamente a aquellos usuarios que
hayan sido previamente registrados para utilizar el Sistema. La ventana está compuesta
de los siguientes elementos:
• Caja de texto ‘Host’, donde se introduce el host que va a proveer el servicio. Los
valores de entrada permitidos son tanto un nombre DNS como una dirección IP.
Una vez introducido el host e iniciada la sesión se permanecerá usando el mismo
host hasta que finalice la sesión y sea posible indicar un nuevo host de
provisión.
Host que va a proveer el servicio.
Identificador de usuario válido para el Sistema.
Contraseña de usuario válida para el Sistema.
Botón de inicio de sesión Botón para agregar un host de provisión de Servicio
Proyecto fin de carrera
151
• Botón ‘…’, que fuerza la aparición de la siguiente ventana emergente para la
introducción de datos, donde es posible insertar el valor que posteriormente
tomará la caja de texto ‘Host’.
• Caja de texto ‘User’, donde se introduce el identificador de usuario que será
utilizado para acceder al Sistema. Dicho identificador de usuario ha tenido que
ser previamente registrado para poder ser verificado a posteriori.
• Caja de texto ‘Password’, donde se introduce la contraseña de usuario que será
utilizada para acceder al Sistema. Dicha contraseña de usuario ha tenido que ser
previamente registrada para ser verificada a posteriori.
• Botón ‘Iniciar sesión’, que permite enviar toda la información de inicio de
sesión al host seleccionado.
En caso de que el inicio de sesión no sea satisfactorio se recibirá el siguiente
mensaje:
Sistema de automatización y control DOM
152
3. Pantalla de gestión de los dispositivos electrónicos
Una vez que el usuario ha sido autenticado por el Sistema, éste tendrá acceso a
la pantalla de administración de dispositivos del Sistema:
La pantalla de administración está divida en tres partes claramente diferenciadas.
En la parte superior se localiza la barra de herramientas con el botón ‘Exit’ que permite
finalizar la sesión en el Sistema. En la parte izquierda está ubicada la jerarquía de
disposición. Esta jerarquía muestra como están dispuestos en el inmueble los diferentes
sensores y actuadores que integran el Sistema. De esta forma, es posible acceder a
cualquier módulo del Sistema para gestionar los dispositivos asociados al mismo.
Finalmente, a la derecha de la jerarquía de disposición se muestra el interfaz de los
sensores y actuadores asociados al módulo seleccionado en el panel izquierdo, donde se
ubica la jerarquía de disposición. Mediante dichos interfaces es posible recibir
información recogida en tiempo real por los sensores, así como gestionar el
comportamiento de los actuadores.
Proyecto fin de carrera
153
A continuación se muestran con mayor detalle las diferentes partes en que se
estructura la pantalla de administración de dispositivos:
Barra de herramientas Botón de fin de sesión
Módulo al que se asocian sensores y actuadores
Interfaz de sensores y actuadores
Botones para aceptar o cancelar una acción
Jerarquía de disposición
Sistema de automatización y control DOM
154
4. Acceso a un módulo del inmueble
A través de la jerarquía de disposición es posible acceder al módulo de cuyos
sensores se quiere obtener información. Descendiendo por los diferentes niveles de
dicha jerarquía se accede al espacio del inmueble que se desea monitorizar. Una vez
aquí se debe seleccionar el módulo, ya que un mismo espacio puede tener instalados
uno o más módulos. Si se hace doble click sobre el módulo deseado se cargará
automáticamente en el panel de la derecha el interfaz de los sensores y actuadores
integrados en dicho módulo.
5. Tipos de sensores y actuadores utilizados
El Sistema cuenta con una serie de sensores y actuadores que permiten la
colección de información y el control de los elementos del inmueble respectivamente.
En función de la información que quiera ser recogida o del tipo de elemento del
inmueble que se quiera controlar se utilizarán unos sensores o actuadores.
A continuación se presentan los tipos de sensores analógicos y digitales que
están disponibles en el Sistema:
• Sensor de luz. Este sensor analógico permite medir el índice de luminosidad del
espacio donde está ubicado. El índice de luminosidad se mide de forma
porcentual, de ahí que el sensor de luz permita realizar mediciones que van
desde 0% a 100%. El aspecto del interfaz que tiene asociado este sensor en la
aplicación es el siguiente
Proyecto fin de carrera
155
• Sensor de temperatura. Este sensor analógico permite medir la temperatura del
espacio donde está ubicado. El rango de temperaturas que es posible medir va
desde -10 grados hasta 50 grados. El aspecto del interfaz que tiene asociado este
sensor en la aplicación es el siguiente
• Sensor de movimiento. Este sensor digital permite detectar el movimiento
producido en el espacio donde está ubicado. Este sensor puede tomar los valores
OK cuando no se detecta movimiento, y PRESENCIA cuando se detecta
movimiento. El aspecto del interfaz que tiene asociado este sensor en la
aplicación es el siguiente
Por otra parte, los tipos de actuadores que pueden ser gestionados por el Sistema
se muestran a continuación:
• Actuador PWM. Este actuador analógico permite controlar el comportamiento
de un motor integrado en un elemento del inmueble. De 0 a 5 son las posibles
velocidades del motor, siendo 0 totalmente parado y 5 la mayor velocidad. El
Sistema de automatización y control DOM
156
aspecto del interfaz que tiene asociado este sensor en la aplicación es el
siguiente
• Actuador 0/1. Este actuador digital permite controlar el comportamiento de un
elemento del inmueble que requiera un estado de encendido y otro de apagado.
Los posibles valores que puede tomar el actuador son encendido (verde) y
apagado (rojo). El aspecto del interfaz que tiene asociado este sensor en la
aplicación es el siguiente
6. Monitorización del estado de los dispositivos
Los sensores del Sistema que están integrados en los diferentes módulos,
transmiten de forma periódica la información recogida del entorno a la aplicación
cliente. Esto implica que el interfaz que muestra el estado en que se encuentran los
sensores se modifica periódicamente de forma que permita al usuario realizar un
seguimiento de la información recogida por los sensores.
Por otra parte, los interfaces de los actuadores también son actualizados de
forma periódica con el fin de mostrar las posibles modificaciones que otros usuarios
hayan podido realizar sobre los acuadores del Sistema.
Proyecto fin de carrera
157
7. Actualización del estado de los dispositivos
Los actuadores del Sistema ofrecen la posibilidad de controlar el
comportamiento de algunos de los elementos del inmueble. Para ello se utiliza el mismo
interfaz que ofrece el Sistema para monitorizar la información recopilada por los
sensores.
Cuando un usuario desea controlar el comportamiento de uno o varios
actuadores de forma remota, esté selecciona en la jerarquía de disposición el módulo en
que están integrados dichos actuadores. Después, en el panel derecho de la aplicación
cliente se cargarán los interfaces de los sensores y actuadores integrados en el módulo
seleccionado. Así, una vez localizado el/los interfaz/interfaces asociados al/los
actuador/es en cuestión, será posible controlar el comportamiento de los mismos.
Finalmente, se pulsa el botón ‘Aceptar’ para enviar los nuevos valores asignados a
el/los actuador/es al servidor. Si la actualización de los dispositivos se ha realizado de
forma correcta el usuario recibirá un mensaje como el siguiente
Nota: Cuando se actualiza el interfaz de el/los actuador/es que se quieren controlar,
dicho/s interfaz/es dejarán de ser actualizados durante un pequeño período de tiempo,
como se comento en el punto 6. Monitorización del estado de los dispositivos. La razón
por la cual esto ocurre así es porque si se refresca el interfaz/interfaces de el/los
actuador/es una vez que el usuario ha establecido los nuevos valores, difícilmente éstos
podrán ser enviar al servidor cuando ser pulse el botón ‘Aceptar’.
Sistema de automatización y control DOM
158
9. Finalizar la sesión en el Sistema
Cuando el usuario desea abandonar el Sistema será necesario que informe de
ello al servidor. El botón de ‘Exit’ , ubicado en la barra de herramientas, le
permitirá realizar esta acción. Una vez pulsado este botón, se mostrará la ventana de fin
de sesión. Esta ventana contiene dos cajas de texto: identificador de usuario y
contraseña. Mientras la primera de estas cajas de texto contiene el identificador de
usuario proporcionado por el mismo durante el inicio de la sesión, la segunda aparece
en blanco para que se pueda introducir la contraseña que permita verificar que el
usuario que está cerrando la sesión es el mismo que la inició, debiendo utilizar para ello
la misma contraseña.
Una vez que se ha introducido la contraseña y que se ha pulsado el botón de
‘Aceptar’ se mostrará un mensaje al usuario, que será de final de sesión correcto o
incorrecto en función de si la contraseña proporcionada por el usuario es correcta o no.
El mensaje de final de sesión correcto es similar al siguiente
Sistema de automatización y control DOM
160
ESTUDIO FINANCIERO
Para el proyecto desarrollado, si no fuese por su finalidad didáctica, se tendría
que haber presentado un presupuesto que englobase el coste que llevaría el diseño,
desarrollo y puesta en marcha del mismo. Éste debería ser valorado y estudiado por el
posible comprador para valorar si es posible o no hacer frente al proyecto.
Por el interés del proyecto y su posible puesta en marcha en el mercado, se
presenta a continuación una estimación de los costes que supondría ponerlo en
funcionamiento para poder ser valorado por cualquier empresa interesada. Los costes a
recalcar son tres, costes de desarrollo, costes de puesta en marcha y costes de
formación.
Para el desarrollo del proyecto son necesarias unas 150 horas de análisis y
diseño, para familiarizarse con las tecnologías utilizadas así como para realizar una
especificación del sistema en estudio lo mas detallada posible. La implementación de
los requisitos recogidos en la fase de análisis, es decir la programación, será larga
debido a las dimensiones del proyecto, siendo necesarias muchas líneas de código, por
lo que el tiempo total dedicado a dicha tarea asciende a unas 250 horas de trabajo. Por
último, el coste de formación destinado para aquellas personas que serán nombradas
administradoras del sistema no será demasiado elevado. Un curso de 2 días de
formación, de unas 4 horas cada día, serán suficientes para aprender a gestionar el
Sistema.
Atendiendo a los precios por horas que se manejan hoy en día en el mercado
laboral, las horas antes mencionadas traducidas a euros serán:
• Coste de implementación 150 horas x 30 euros = 4500 euros/horas
• Coste de implantación: 250 horas x 25 euros = 6250 euros/horas
• Coste de formación: 8 horas x 20 euros = 160 euros/horas
Proyecto fin de carrera
161
Por otro lado, los costes de adquisición de tecnologías es otro punto importante a
tener en cuenta. Para poder poner en funcionamiento el sistema serán necesarios
determinados equipos y determinado software con el consecuente gasto que ello
requiere.
A nivel de software en este caso no habrá gastos establecidos ya que a priori
todo el software que va a ser utilizado en su desarrollo es software libre. Sin embargo el
coste de tiempo de la instalación de todo el software ascenderá a unas 4 horas de
trabajo, que en euros asciende a 4 horas x 20 euros = 80 euros/horas.
A nivel de hardware es necesario un equipo encargado de ser el servidor de
aplicaciones web. El precio del servidor oscilará entre los 1200-1700 euros.
El total del presupuesto asciende a:
Coste de implementación: 4500 euros
Coste de implantación: 6250 euros
Coste de formación: 160 euros
Coste de instalación: 80 euros
Coste de hardware: 1700 euros
.
Coste total: 12690 euros
Proyecto fin de carrera
163
PLANIFICACIÓN
Planificación I-Alberto Carrasco Sánchez 09-oct 16-oct 23-oct 30-oct 06-nov 13-nov 20-nov 27-nov 04-dic 11-dic 18-dic 15-ene 22-ene
Especificación y diseño del protocolo de comunicaciones del exterior con el sistema Especificación de la estructura del fichero de configuración Migración de fichero de configuración a XML Instalación del servidor para desarrollo (Apache Tomcat, J2ME, Eclipse...) Estudio del tipo de interfaz de cliente Desarrollo de un servlet mono thread básico Desarrollo de un interfaz básico de cliente con comunicación con el Servlet Implementación del protocolo DOM en el cliente Intercambio de ficheros en el servlet Integración con el sistema de control
Planificación II - Alberto Carrasco Sánchez 29-ene 05-feb 05-feb 12-feb 19-feb 26-feb 05-mar 12-mar 19-mar 26-mar 02-abr 09-abr 16-abr 30-abr 14-may 28-may 11-jun
Instalación del sistema en el IIT Desarrollo de un interfaz avanzado para PC Desarrollo del servlet multi-thread Implementación y especificación de un caso real Pruebas Documentación
Proyecto fin de carrera
164
BIBLIOGRAFÍA
[BARR01] Barranco de Areba, J. “Metodología del análisis estructurado de
sistemas”, Universidad Pontificia Comillas, 2001.
[GEOG05] George Coulouris, Jean Dollimore y Tim Kindberg “Distributed Systems.
Concepts and Design”, Addison Wesley, 2005.
[ELLI05] Elliotte Rusty Harold y W. Scott Means “XML Imprescindible”, Anaya
Multimedia & O’Reilly, 2005.
[IVOR00] Ivor Horton “Beginning Java 2 JDK 1.3 Edition” Wrox Programmer to
Programmer, 2000.