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: ……/ ……/ ……
164
Embed
Autorizada la entrega del proyecto del alumno/a: Alberto ... · PDF file3.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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
Proyecto fin de carrera
7
ANEXO D 162
BIBLIOGRAFÍA 164
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.
Sistema de automatización y control DOM
10
1. IDENTIFICACIÓN de NECESIDADES
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.
Sistema de automatización y control DOM
16
2. ANÁLISIS de REQUISITOS
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
Sistema de automatización y control DOM
38
3. SOLUCIÓN PROPUESTA
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.
Proyecto fin de carrera
59
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.
Sistema de automatización y control DOM
62
3.2.1.2.3 Diagramas de secuencia
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.
Sistema de automatización y control DOM
66
3.2.2.2 DISEÑO INTERNO
3.2.2.2.1 Diagramas de clases
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
75
3.2.2.2.2 Diagramas de secuencia
Sistema de automatización y control DOM
76
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.
Proyecto fin de carrera
79
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().
Proyecto fin de carrera
81
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.
Proyecto fin de carrera
85
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
87
Sistema de automatización y control DOM
88
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.
Proyecto fin de carrera
91
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
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
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