Autorizada la entrega del proyecto del alumno/a: Alberto ... · PDF file3.4.5 Archivo...

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


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


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.


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


6

3.2.2 SERVIDOR

3.2.2.1 Funciones propias 64


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


7

ANEXO D 162

BIBLIOGRAFÍA 164


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.


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.


10

1. IDENTIFICACIÓN de NECESIDADES


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


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.


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


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


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.


16

2. ANÁLISIS de REQUISITOS


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


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.


19

2.1.2 Contexto del Sistema

MOVIMIENTO LUMINOSIDAD

Internet/Intranet

RF

CLIENTE

SERVIDOR

ACTUADORES TEMPERATURA


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.


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


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.


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


24

HOJA DE REQUISITOS



TIPO REQUISITO: Operativo IDENTIFICACIÓN: R02


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.


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.




25

HOJA DE REQUISITOS





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.


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.


Contexto del Sistema


R04


26

HOJA DE REQUISITOS





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.





27

HOJA DE REQUISITOS





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




R05 y R06


28

HOJA DE REQUISITOS





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:


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.




29

HOJA DE REQUISITOS




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.


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.




30

HOJA DE REQUISITOS





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.


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.




31

HOJA DE REQUISITOS



TIPO REQUISITO: Prestación IDENTIFICACIÓN: R08


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.


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.




32

HOJA DE REQUISITOS





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.


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.




33

HOJA DE REQUISITOS





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.


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.




34

HOJA DE REQUISITOS





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.


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.




35

HOJA DE REQUISITOS



TIPO REQUISITO: Seguridad IDENTIFICACIÓN: R12


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.


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




36

HOJA DE REQUISITOS



TIPO REQUISITO: Seguridad IDENTIFICACIÓN: R13


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.


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.




37

HOJA DE REQUISITOS





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.





38

3. SOLUCIÓN PROPUESTA


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.


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


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


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


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.


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


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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


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.


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.


59


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.


61

prj.client.window.DOMClientApplet

Esta clase implementa los métodos básicos para poder embeber una aplicación Java en

un navegador web.


62

3.2.1.2.3 Diagramas de secuencia


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.


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.


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.


66


3.2.2.2.1 Diagramas de clases


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.


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.


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.


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.


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.


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.


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.


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.


75

3.2.2.2.2 Diagramas de secuencia


76


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


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.


79


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


81


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.


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


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.


85


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.


87


88


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.


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.


91


92

DOMServerFileManagement.writeLogFile()

Este diagrama representa el flujo de mensajes invocados entre diferentes clases para

escribir en el fichero log.txt. Este diagrama es similar al diagrama de colaboración del

método writeActuatorFile(). La única diferencia destacable sería que en el caso del

método que escribe en el log del Sistema es necesaria la instanciación de objetos de

tipo Date y DateFormat, pues en el log en cada registro se incluye la fecha en que fue

añadido.


93


94

ConfigFileClientParser.ConfigFileClientParserHandlerBase.startElement()

Este diagrama muestra la colaboración que se establece entre diferentes clases para

parsear el contenido del archivo config.xml. Es en dicho proceso donde se construye la

jerarquía de disposición que permite al cliente acceder a los distintos dispositivos

ubicados en un área determinada del inmueble. La jerarquía de disposición está

construida utilizando el componente DefaultMutableTreeNode, que proporciona una

apariencia jerárquica del conjunto de habitaciones en que está estructurado el

inmueble. Si se observan las distintas llamadas que se intercambian las clases que

participan de este proceso, es posible apreciar como se crean instancias de la clase

DefaultMutableTreeNode llamadas building, Hindex, room o floor. Estas referencias

representan cada uno de los niveles de la jerarquía tales como el edificio para el que se

está creando la jerarquía, las plantas que tiene dicho edificio o el conjunto de

habitaciones que se distribuyen en cada planta.


95

3.2.2.3 Comportamiento del Servidor

A continuación se muestra la tabla de estado actual/mensaje � estado futuro-

acción. Esta tabla recoge las transiciones entre los estados posibles en el

comportamiento del componente Servidor, así como las acciones asociadas a las

mismas, cuando el Sistema se encuentra en un estado determinado y recibe un mensaje

concreto:

Para cada combinación de estado actual/mensaje existe uno o varios estados a

los que se puede llegar, así como una acción asociada que se tiene que ejecutar.

Mientras que el nuevo estado al que se llega se indica en la parte superior izquierda de

cada celda, en la parte inferior derecha se indica la acción a ejecutar. Por ejemplo,

supongamos que un usuario que se hubiera autenticado previamente decide enviar

nuevos parámetros de control a un actuador del Sistema. Para ello, estando el servidor

en estado 1. Autenticado, recibiría un mensaje de tipo EscrituraHard que provocaría una

transición del estado 1. Autenticado al estado 2. RespuestaOK o 3. RespuestaError, en

1 5

n/a n/a

1 5

1 5

2, 3 4

0 5

1 5

n/a n/a

1 5

1 5

1 5

3, 5 1

n/a n/a

n/a n/a

n/a n/a

n/a n/a

n/a n/a

n/a n/a

1 3

n/a n/a

0, 1 3

1 3

1 5

0 5

1 5

n/a n/a

1 5

1 5

2, 3 2

0 5

1 5

n/a n/a

1 5

1 5

1 5

0 5

0.

NoAutenticado

1.

Autenticado

3.

RespuestaError

4.

RespuestaWait

5.

RespuestaConfig

2.

RespuestaOK

Estado actual

Mensaje

Mensaje erróneo

EscrituraHard

RespuestaOK

RespuestaError

Conexión

Desconexión


96

función de si la operación se ha realizado con o sin éxito. Además de la transición a uno

de estos dos estados, el Sistema ejecutará una acción que actualizará el comportamiento

del actuador con los nuevos parámetros enviados.

Este comportamiento se ha trasladado al código del servlet mediante la

implementación de la clase ManagementActionPattern. Esta clase utiliza un array

bidimensional para llevar a la práctica el comportamiento recogido en la tabla anterior.

El código de la clase ManagementActionPattern se reproduce a continuación por su

interés:

/*

* Creado el 07-ago-2006

*

* TODO Para cambiar la plantilla de este archivo generado, vaya a

* Ventana - Preferencias - Java - Estilo de código - Plantillas de código

*/

package prj.server.control;

/**

* @author Alberto Carrasco

*

* TODO Para cambiar la plantilla de este comentario generado, vaya a

* Ventana - Preferencias - Java - Estilo de código - Plantillas de código

*/

import java.util.Iterator;

import prj.server.msg.*;

//Esta clase representa el 'patrón de acción' para el servlet DOMServletManagement.

//Por patrón de acción se entiende como actúa el sistema en función del estado en

//que se encuentra la sesión del usuario en el sistema en un momento dado y de la

//entrada(mensaje) que recibe dicho sistema en ese mismo momento.

public class ManagementActionPattern {

//Constantes que definen los diferentes mensajes que, según la clase ManagementActionPattern,

//pueden llegar al servlet DOMServletManagement.

static final int ERROR_MSG = 0;

static final int ESCRITURAHARD_MSG = 1;

static final int RESPUESTAOK_MSG = 2;

static final int RESPUESTAERROR_MSG = 3;

static final int CONEXION_MSG = 4;

static final int DESCONEXION_MSG = 5;


97

//Constantes que definen las distintas acciones que pueden ser almacenadas en la matriz

//messageStateActionMatrix

static final int LOGON_ACTION = 1;

static final int WRITE_ACTION = 2;

static final int CHANGESTATE_ACTION = 3;

static final int LOGOFF_ACTION = 4;

static final int ERROR_ACTION = 5;

//Esta es la matriz de decisión que hará elegir una acción en función de una serie de valores

//de entrada:

// - El estado actual en el que se encuentra la sesión del usuario en el sistema

// en un instante dado.

// - El mensaje que llega al servlet DOMServerManagement en instante dado.

//

//La matriz quedaria tal que así:

//

// x1'x2'x3'x4'x5'x6' LEYENDA xn(Estado): Leyenda xn'(Mensaje):

//x1 5 5 5 5 1 5 x1-> NOAUTHENTICATED_STATE x1'-> ERROR_MSG

//x2 5 2 5 5 5 4 x2-> AUTHENTICATED_STATE x2'-> ESCRITURAHARD_MSG

//x3 5 5 3 3 5 5 x3-> RESPUESTAOK_STATE x3'-> RESPUESTAOK_MSG

//x4 5 5 3 5 5 5 x4-> RESPUESTAERROR_STATE x4'-> REPUESTAERROR_MSG

//x5 5 5 3 5 5 5 x5-> RESPUESTAWAIT_STATE x5'-> CONEXION_MSG

//x6 5 5 3 5 5 5 x6-> RESPUESTACONFIG_STATE x6'-> DESCONEXION_MSG

//IMPORTANTE!

//Para añadir una nueva acción al sistema bastará con crear una nueva constante xxxxx_ACTION

//e insertarla dentro de la matriz messageStateActionMatrix en la posición que corresponda.

//Posteriormente, en la clase Coordinator se deberá crear una nueva entrada 'case' en la

//función executeAction() para la nueva acción, así como una nueva función en la clase

//ManagementActionImplementation que implemente dicha nueva acción.

private int[][] messageStateActionMatrix;

public ManagementActionPattern(){

messageStateActionMatrix = new int[6][6];

}


98

//Este método transforma el identificador de la instrucción utilizado en el documento xml

//en el identificador utilizado en el patrón de comportamiento establecido en la clase

//ManagementActionPattern.

private int fromInstructionToManagementActionPatternMessage(Message msg){

Iterator itr = msg.getInstructionSet().getInstructions();

int msgMAPValue = -1;

switch(((Instruction)itr.next()).getType()){

case 2:

msgMAPValue = ESCRITURAHARD_MSG;

break;

case 3:

msgMAPValue = RESPUESTAOK_MSG;

break;

case 4:

msgMAPValue = RESPUESTAERROR_MSG;

break;

case 8:

msgMAPValue = CONEXION_MSG;

break;

case 9:

msgMAPValue = DESCONEXION_MSG;

break;

default:

msgMAPValue = RESPUESTAERROR_MSG;

break;

}

return msgMAPValue;

}


99

//Devuelve la acción a tomar en función de el estado actual y del mensaje obtenido

public int getActionIndex(State st, Message msg){

//Se obtiene el identificador del estado correspondiente a la fila de la matriz


int currentState = st.getCurrentStatus();

//Se obtiene el identificador del mensaje correspondiente a la columna de la matriz


int currentMessage = fromInstructionToManagementActionPatternMessage(msg);

//Se comprueba si la función fromInstructionToManagementActionPatternMessage(Message msg)

//devuelve -1. En tal caso se sustituye dicho valor por la constante RESPUESTAERROR_MSG

//cuyo valor es 3 para que pueda hacerse la búsqueda correctamente en la matriz


if(currentMessage == -1)

currentMessage = RESPUESTAERROR_MSG;

//Se extrae el valor de la matriz messageStateActionMatrix

if((currentState >= 0 && currentState < 6) && (currentMessage >= 0 && currentMessage < 6))

return messageStateActionMatrix[currentState][currentMessage];

else

return -1;

}

//Este método inicializa la matriz messageStateActionMatrix con los valores enteros de las

//acciones pertinentes que pueden ser tomadas

public void init(){

//[x1][xn'] (n' desde 1 a 6)

messageStateActionMatrix[0][0] = ERROR_ACTION;




messageStateActionMatrix[0][4] = LOGON_ACTION;



100

//[x2][xn'](n' desde 1 a 6)


messageStateActionMatrix[1][1] = WRITE_ACTION;




messageStateActionMatrix[1][5] = LOGOFF_ACTION;

//[x3][xn'] (n' desde 1 a 6)



messageStateActionMatrix[2][2] = CHANGESTATE_ACTION;




//[x4][yn] (xn' desde 1 a 6)







//[x5][xn'] (xn' desde 1 a 6)







//[x6][xn'] (xn' desde 1 a 6)







}

}


101

3.3 COMUNICACIÓN CLIENTE-SERVIDOR

La comunicación entre los componentes Cliente y Servidor se realiza mediante

servlets. Java Servlet Technology es una tecnología propiedad de la compañía

norteamericana SUN Microsystems, que se enmarca dentro del paquete Java 2

Enterprise Edition (J2EE), que permite generar contenido dinámico en formato HTML

como respuesta a una petición previa realizada por un interlocutor, generalmente una

petición recibida desde un navegador web o incluso desde otro servlet.

El Protocolo de Transferencia de Hipertexto (HTTP) es un protocolo de nivel de

aplicación utilizado por los navegadores web para realizar peticiones a los servidores

web recibiendo respuesta de estos. HTTP funciona mediante el intercambio de mensajes

request-reply entre los nodos involucrados. El formato de dichos mensajes es distinto ya

que cada uno está pensado para realizar una función diferente.

En formato del mensaje de request está formado por el nombre del método, la

URL del recurso que se quiere acceder, la versión del protocolo, alguna información de

cabecera y un cuerpo de mensaje opcional. Mientras, en el caso del mensaje de reply,

éste está formado por la versión del protocolo, un código de estado, razón, alguna

información de cabecera y un cuerpo de mensaje opcional. A continuación se muestra

un esquema de ambos formatos:

POST http://www... HTTP/1.1

Método URL Versión HTTP Cabeceras Cuerpo

Mensaje HTTP de Request

HTTP/1.1 200 OK Datos

Versión HTTP Estado Razón

Cabeceras Cuerpo

Mensaje HTTP de Reply

Datos


102

HTTP dispone de varios métodos que se pueden incluir en el mensaje de

request: GET, POST, HEAD, PUT… Para el envío de mensajes de request se ha se

elegido el método POST. Este método permite transportar cantidades importantes de

información en los mensajes de solicitud, lo que lo hace idóneo para insertar

información de control y datos del protocolo de control DOM. Esta información se

transporta en el campo opcional Cuerpo del mensaje. Es cierto que el método GET

también tiene la capacidad de contener datos, pero el número es ciertamente mas

limitado que el anterior ya que se anexan al campo URL del mensaje de solicitud, que

no está preparado para transportar grandes cantidades de información. En el caso del

mensaje de reply, la información devuelta se almacena también en el campo opcional

Cuerpo del mensaje. Así, mientras los mensajes HTTP de request son enviados desde el

cliente al servidor, los mensajes HTTP de reply son enviados en sentido contrario, es

decir, desde el servidor al cliente.

Por tanto, los servlets no son entidades que permanecen ajenas a este

intercambio de mensajes HTTP, sino que participan activamente recibiendo mensajes

de request y devolviendo mensajes de reply. Y, precisamente, es la lógica que pueden

implementar los servlets la que les permite enviar un mensaje u otro en función del

mensaje de solicitud que se haya recibido del cliente. Se puede actuar en repuesta a

algo. El proceso de comunicación cliente-servidor se muestra en detalle en los

siguientes gráficos:

CLIENTE SERVIDOR

Mensaje HTTP de Request

<?xml version=”1.0” encoding=” ISO-8859-1” …?> <!DOCTYPE mensaje SYSTEM ""> <mensaje idMensaje=”” idMensajeAck=””> </mensaje>

SERVLET

post www HTTP Datos


103

CLIENTE SERVIDOR

Mensaje HTTP de Reply

<?xml version=”1.0” encoding=” ISO-8859-1” …?> <!DOCTYPE mensaje SYSTEM ""> <mensaje idMensaje=”” idMensajeAck=””> </mensaje>

SERVLET

HTTP 200 OK Datos


104

3.4 MODELO DE DATOS

El modelo de datos es un documento necesario para la obtención de una

arquitectura de datos consistente. A partir del modelo de datos se van a obtener las

estructuras físicas de datos que permitirán procesar y almacenar la información relativa

al Sistema. Pero no solamente las estructuras físicas serán deducidas a partir de este

modelo, anteriormente a éstas también serán deducidas las características principales

del modelo de datos del Sistema.

A diferencia de otros proyectos, las estructuras que finalmente se obtendrán

como resultado del documento no serán tablas relacionales sino archivos. Estos

archivos, a fin de obtener una arquitectura de datos coherente con el sistema que se está

diseñando, serán normalizados evitando redundancias derivadas de un proceso erróneo

de colección de datos.

A continuación se desarrolla el modelo de datos. Este modelo pretende servir

como presentación para cada uno de los archivos necesarios para el correcto

funcionamiento del Sistema. Además, dicho modelo pretende detallar la parte del

proceso en la cual están implicados estos archivos, así como todos y cada uno de los

elementos que los integran, con su correspondiente descripción y el rango de valores

posibles.


105

3.4.1 Protocolo de control DOM 1.0

A pesar de que el Protocolo de control DOM 1.0 no puede ser considerado una

estructura de almacenamiento de información permanente, no es menos cierto que dicho

protocolo emplea una estructura XML para dar formato a la información que es

intercambiada entre nodos. Esta estructura XML es utilizada de forma temporal, es

decir, no se guarda en ningún dispositivo de almacenamiento que no sea la memoria

RAM, que tiene carácter volátil.

Sin embargo, el mero hecho de que esta estructura tenga un ciclo de vida

bastante mas corto que muchas otras que forman parte del Sistema, como los archivos

XML de configuración, histórico o actualización, no hace su estudio menos importante.

Por esta razón, a continuación se muestra la estructura XML general de elementos y

atributos utilizada para el intercambio de información entre nodos por el Protocolo de

Control DOM 1.0:

<?xml version=”1.0” encoding=” ISO-8859-1” standalone=”no”?> <!DOCTYPE mensaje SYSTEM ""> <mensaje idMensaje=”” idMensajeAck=””>

<conjuntoInstrucciones idConjuntoInstrucciones=””> <instruccion idInstruccion=”” tipo=”” descripcionTipo=””> <texto> <identificacion></identificacion> <contrasenya></contrasenya> <informacion tipo=”” descripcionTipo=””></informacion> </texto>

<dispositivo idModulo=”” idDispositivo=”” tipo=”” pin=“” valor=””/> </instruccion>

</conjuntoInstrucciones> </mensaje>

En primer lugar, los únicos elementos que se mantienen iguales en todos los

mensajes son el elemento <?xml version=”1.0” encoding=” ISO-8859-1”

standalone=”no”?> y el elemento <!DOCTYPE mensaje SYSTEM "">. El resto de

los elementos y atributos que dan formato a la información del protocolo intercambiada

entre nodos se detalla a continuación:

• El elemento <mensaje> representa un mensaje intercambiado entre el

cliente y el servidor o viceversa. Un elemento <mensaje> puede


106

contener únicamente 1 elemento <conjuntoInstrucciones>. El atributo

idMensaje identifica unívocamente cada uno de los mensajes

transmitidos por cualquier nodo del sistema durante la comunicación.

Estos identificadores serán inicializados de forma aleatoria en cada uno

de los nodos participantes en la comunicación. Además, los

identificadores se irán incrementando en uno a partir del valor tomado

inicialmente, volviendo al valor 1 cuando se haya producido

rebosamiento. Por su parte, el atributo idMensajeACK fue concebido

inicialmente con la idea de confirmar la recepción, por parte del

interlocutor, de un mensaje enviado con anterioridad. Actualmente, el

protocolo no utiliza este campo para realizar confirmaciones pues deja

esta función en manos del protocolo TCP, que es el protocolo de

transporte empleado por HTTP, y su mecanismo de envío y recepción de

confirmaciones ACK.

NOTA: Se excluye el cero del rango de valores posibles para el atributo

idMensaje, ya que este valor será utilizado en el atributo

idMensajaACK, no para confirmar la recepción del mensaje con

idMensaje a cero, sino para indicar que el mensaje actual no está

confirmando ningún mensaje recibido con anterioridad.

• El elemento <conjuntoInstrucciones> representa el conjunto de

instrucciones transmitidas entre el nodo cliente y el servidor en un

instante de tiempo concreto. Un elemento <conjuntoInstrucciones>

puede contener de 0 a n elementos <instruccion>, siendo n de 1 a ∞. Si

<instruccion> contiene cero elementos significará que se está realizando

una Lectura “Hard” o que se trata de una instrucción de tipo

Acknowledge reply que confirma una repuesta desde la PDA al servidor.

El atributo idConjuntoInstrucciones identifica unívocamente un

conjunto de instrucciones en la secuencia de comunicación del protocolo,

siendo su valor igual al del atributo idMensaja del elemento

<mensaje>.


107

• El elemento <instruccion> representa una instrucción transmitida entre

el nodo cliente y el servidor. El atributo idInstruccion identifica

unívocamente una instrucción dentro del grupo de instrucciones

transmitidas de manera simultánea. El atributo tipo identifica el tipo de

instrucción realizada (1, 2, 3, 4, 5, 6, 7, 8, y 9). El atributo

descripcionTIpo describe el tipo de instrucción solicitada (Lectura

“Hard”, Escritura “Hard”, Respuesta OK, Respuesta Error, Respuesta

Wait, Respuesta Configuración, Respuesta “Hard”, Conexión y

Desconexión). Un elemento <instruccion> debe contener

exclusivamente bien un elemento <texto> bien un elemento

</dispositivo>, o nada. Si la instrucción contiene cualquier otra

información (autenticación, mensajes informativos…) entonces el

elemento <instrucción> contendrá un elemento <texto>.

NOTA: La instrucción Conexión enviará al servidor la información

necesaria para poder dar inicio al proceso de transmisión de instrucciones

(<identificacion><contrasenya>). El servidor responderá a este

mensaje retornando el archivo config.xml, donde reside la configuración

del sistema, confirmando a su vez la recepción de la instrucción de

conexión enviada anteriormente. Además, la instrucción Desconexión

permitirá dar por finalizado el proceso de comunicación, procediendo a la

correspondiente liberación de recursos.

Por otra parte, existen otros cinco tipos de instrucciones: Lectura “Hard”,

Escritura “Hard”, Respuesta, Conexión y Desconexión. Las denominadas

Lectura “Hard” y Escritura “Hard” están destinadas a realizar lecturas y

escrituras sobre los sensores/actuadotes. Una instrucción del tipo Lectura

“Hard” será confirmada por medio de una instrucción Respuesta “Hard”.

La instrucción Lectura “Hard” será solicitada automáticamente por el

sistema con la periodicidad que se requiera, siendo a su vez respondida

de forma automática por el sistema central.

Finalmente, la instrucción Respuesta (Respuesta OK, Respuesta Error,

Respuesta Wait, Respuesta Configuración, Respuesta “Hard”) pretende


108

indicar el estado en que se encuentra una solicitud de operación realizada

con anterioridad.

• El elemento <texto> representa el contenido de una instrucción cuando

esta no contiene información de dispositivo o fichero. El elemento

<texto> puede, bien contener a los elementos <identificacion> y

<contrasenya> bien al elemento <informacion>, pero nunca cualquier

otra combinación de estos.

• El elemento <identificacion> representa la identificación requerida por

el Sistema para autenticarse frente al mismo.

• El elemento <contrasenya> representa la contraseña requerida por el

Sistema para autenticarse frente al mismo.

• El elemento <informacion> representa cualquier otra información de

carácter alfanumérico que deba ser intercambiada entre el nodo cliente y

el servidor. El atributo tipo determina el carácter de la información

transmitida. El atributo descripcionTipo detalla con una cadena de texto

el tipo de información transmitida.

• El elemento <dispositivo> representa el dispositivo (sensor/actuador)

sobre el cual se va a realizar la operación de lectura o escritura definida

en el elemento <instruccion> al que pertenece este elemento. El atributo

idModulo identifica unívocamente el módulo dentro del inmueble. El

atributo idDispositivo identifica unívocamente el dispositivo dentro del

inmueble. El atributo pin identifica el pin dentro del módulo en cuestión.

El atributo valor contiene los nuevos datos que deben ser escritos en el

actuador. El atributo tipo identifica el tipo de actuador sobre el que

estamos realizando la acción. Los valores que admite el atributo tipo son

PWM y 01.


109

3.4.2 Archivo config.xml

La principal misión de este archivo en el Sistema es almacenar la configuración

del sistema físico, es decir, cuáles, cuántos y cómo están distribuidos en cada uno de los

espacios del inmueble los sensores y los actuadotes que integran el Sistema. A partir de

la información almacenada en este archivo se construirá una jerarquía visual que

permitirá monitorizar y controlar cada uno de los dispositivos de cada una de las

dependencias del inmueble. Por último, este archivo debe ser actualizado con las

modificaciones que se realicen sobre el sistema físico. Cualquier cambio que se realice,

tanto en la adhesión o en la eliminación de sensores y actuadotes como en la forma en

que se disponen en el inmueble, deberá ser registrada en este archivo para que exista

una correspondencia exacta entre la realidad y la representación software.

A continuación se muestra la estructura XML general de elementos y atributos

de almacenamiento de la configuración del sistema físico:

<?xml version=”1.0” encoing=”ASCII” standalone=”yes”?> <Edificio nombre=””> <Planta numero=””> <Habitacion tipo=”” descripcionTipo=””> <HIndice id=”” nombre=””> <Modulo id=””> <Dispositivo id=”” tipo=”” descripcionTipo=”” nombreModelo=”” descripcionModelo=”” pin=””> <Analogico texto=”” descripción=”” clase=”” valorMax=”” valorMin=”” unidades=””/> <Digital texto=”” descripción=”” clase=””/> </Dispositivo> </Modulo> </HIndice> </Habitacion> </Planta> </Edificio>

Los elementos y atributos que forman parte de esta estructura XML se detallan a

continuación:

• El elemento <Edificio> representa el inmueble donde se instalará el

sistema de control y automatización. Un elemento <Edificio> puede

contener tantos elementos <Planta> como plantas tenga el inmueble. El


110

atributo nombre proporciona, como el propio atributo sugiere, un

nombre con el que identificar al inmueble.

• El elemento <Planta> representa una planta del inmueble. El elemento

<Planta> puede contener tantos elementos <Habitación> como

habitaciones diferentes haya en el inmueble. El atributo numero indica

la posición que ocupa la planta en cuestión dentro del inmueble.

• El elemento <Habitacion> representa un tipo de habitación de una

planta del inmueble. El atributo tipo indica la tipología de la habitación.

A este respecto, se han definido una serie de valores para este atributo

tales como H1, H2, H3, H4, H5, H6, H7, H8. Estos valores tienen su

correspondiente descripción en el atributo descripciónTipo tales como

Salón, Habitación, Cocina, Pasillo, Servicios, Terraza, Garaje,

Exteriores.

• El elemento <HIndice> representa, dentro cada una de las tipologías

definidas, una habitación física del inmueble. Por ejemplo, si hay dos

despachos en una planta, existirá un elemento <Habitacion> que

recogerá la existencia de dicha tipología, y dos elementos <HIndice>

que recogerán la existencia de dos habitaciones físicas de tipo despachos.

Los atributos de este elemento son id y nombre. El primero .identifica

unívocamente una habitación de una tipología concreta dentro de una

planta del inmueble determinada. El segundo, por su parte, dota de un

nombre concreto a la habitación física. Por otra parte, un elemento

<HIndice> no tiene ninguna restricción para contener tanto elementos

<Modulo> como se quiera, la única limitación aquí será el propio

sentido común.

• El elemento <Modulo> representa un módulo dentro del inmueble. Un

módulo puede dar cabida a un número determinado de sensores y

actuadores. Concretamente, un elemento <Modulo> puede contener

tantos elementos <Dispositivo> como pines haya disponibles en el


111

mismo. El atributo id identifica unívocamente un módulo dentro del

inmueble.

• El elemento <Dispositivo> representa un dispositivo asociado a un

módulo que se encuentra en una dependencia de una planta del inmueble.

Un dispositivo en este contexto puede ser tanto un sensor como un

actuador. Además, ese dispositivo puede ser de tipo analógico o digital,

quedando reflejada esta naturaleza según se contenga un elemento

<Analogico> o <Digital> respectivamente. Por tanto, un elemento

<Dispositivo> deberá contener al menos un elemento <Analógico> o

<Digital>, pero en ningún caso mas de uno. Este elemento cuenta con un

grupo nutrido de atributos que pretenden detallar las características del

dispositivo. El atributo id identifica unívocamente al sensor o actuador

dentro del modulo en el que se encuentra contenido. Es importante

especificar que es posible que exista otro dispositivo con el mismo

identificador dentro de otro módulo diferente, pero esto no supone

ningún problema para el correcto funcionamiento del Sistema. El atributo

tipo determina el tipo de dispositivo electrónico, habiéndose definido

cuatro valores para dicho atributo tales como S1, S2, A1, A2. Estos

valores encuentran una descripción en el atributo descripcionTipoque

puede contener los valores Sensor_analogico, Sensor_digital,

Actuador_tipo_0/1, Actuador_tipo_PWM respectivamente. Por otro lado,

el atributo nombreModelo define el nombre del modelo de sensor o

actuador utilizado, mientras que el atributo descripcionModelo

proporciona una descripción del modelo. Finalmente, el atributo pin

determina el pin que utilizará el dispositivo dentro del módulo, no

pudiendo coincidir con el pin empleado por otro dispositivo en el mismo

módulo.

• El elemento <Analogico> representa una tipología de sensor o actuador,

según haya quedado definido en el atributo tipo del elemento

<Dispositivo>. El elemento <Analogico> posee seis atributos. El

primero es texto que asocia un texto alfanumérico a la representación

gráfica del dispositivo. El segundo es descripción que amplia la


112

información provista por el atributo anterior. El tercero es clase que

viene a indicar el archivo.class que será empleado para realizar una

representación grafica del dispositivo en la interfaz de usuario. El cuarto

y el quinto son valorMax y valorMin que, dado que el elemento descrito

es de tipo analógico, servirán para establecer el rango de valores con el

que trabaja dicho dispositivo. El sexto y último atributo es unidades que

pretende proporcionar las unidades con las que trabaja el dispositivo,

solamente con fines informativos.

• El elemento <Digital> es la otra variante de la tipología que puede

contener el elemento <Dispositivo>. Los tres atributos de este elemento

son exactamente los mismos que los tres primeros del elemento

<Analogico>.


113

3.4.3 Archivo historico.xml

La función principal que desempeña el archivo historico.xml en el Sistema es

almacenar los últimos datos relativos al estado actual de los sensores y actuadores.

Estos datos son almacenados en dicho archivo por el sistema físico paralelo, mientras

que de su recuperación periódica se encarga el Sistema de control y automatización

DOM. La actualización periódica de este archivo por parte del sistema físico es

fundamental, de otra forma los datos que recuperaría el Sistema de control y

automatización DOM no estarían reflejando la realidad de las magnitudes de medida

propias del entorno en el que está ubicado el inmueble (temperatura, luminosidad,

movimiento…)


que almacena los últimos valores recuperados desde los dispositivos electrónicos del

sistema físico:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ?>

<Historico>

<Modulo id="">

<Dispositivo idDispositivo="" valor=""/>

</Modulo>

</Historico>


continuación:

• El elemento <Historico> representa una agrupación de módulos con sus

respectivos dispositivos. Este elemento puede contener tantos elementos

<Modulo> como módulos existan en el Sistema. Realmente, el elemento

<Historico> no tiene ninguna función especial, simplemente pretende

ofrecer un elemento raíz para el archivo XML que permita agrupar

elementos de nivel inferior, es este caso los elementos de tipo

<Modulo>.


114

• El elemento <Modulo> representa un módulo ubicado en un punto

cualquiera del inmueble. Este elemento tiene la intención de agrupar

dispositivos por módulo, pudiendo contener un máximo de elementos

<Dispositivo> igual al número de pines disponibles en el módulo. El

atributo id pretende identificar de forma unívoca un módulo dentro del

inmueble.

• El elemento <Dispositivo> representa un dispositivo del que se está

recuperando un valor en un momento determinado. Este elemento tiene

dos atributos. El primero de ellos es idDispositivo que identifica al

dispositivo de forma unívoca en el propio módulo donde esta ubicado. El

segundo es valor que como su nombre indica recupera el valor del

dispositivo.


115

3.4.4 Archivo actualizacion.xml

El archivo actualizacion.xml tiene como función principal almacenar las últimas

modificaciones realizadas sobre los actuadotes por el usuario. Dichas modificaciones

serán transmitidas posteriormente al sistema físico que las aplicará sobre los actuadotes

implicados. En este caso, será el Sistema de control y automatización DOM el

encargado de llenar con datos el archivo para que, posteriormente, sea consumido por el

sistema físico paralelo. La actualización de este archivo, a diferencia de historico.xml,

no se realiza de forma periódica si no a petición del usuario.


que almacena las últimas modificaciones realizadas sobre los actuadotes por parte del

usuario:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>

<Actuadores>

<Modulo idModulo="">

<Dispositivo idDispositivo="" pin="" valor=""/>

</Modulo>

</Actuadores>


continuación:

• El elemento <Actuadores> no tiene ninguna función especial, simplemente

pretende ofrecer un elemento raíz para el archivo XML que permita contener un

elemento de tipo <Modulo>.

• El elemento <Modulo> representa un módulo ubicado en un punto cualquiera

del inmueble. Este elemento agrupa los dispositivos que han sido actualizados

por el usuario, pudiendo contener un máximo de elementos <Dispositivo> igual

al número de pines disponibles en el propio módulo. El atributo id pretende

identificar de forma unívoca un módulo dentro del inmueble.


116

• El elemento <Dispositivo> representa un dispositivo que se ha actualizado, en

este caso siempre será un actuador ya que los sensores solo pueden ser

monitorizados y no controlados. Este elemento tiene tres atributos. El primero de

ellos es idDispositivo que identifica al dispositivo de forma unívoca en el propio

módulo donde esta ubicado. El segundo es pin que determina el pin que utilizará

el dispositivo dentro del módulo para realizar la actualización del actuador. Y el

tercero es valor que como su nombre indica asigna un nuevo valor al actuador

que esta siendo actualizado.


117

3.4.5 Archivo contraseña.txt

El archivo contraseña.txt almacena las duplas formadas por identificador de

usuario y contraseña. Esta dupla está separada por el carácter ‘:’, de manera que el

proceso que lee dicho archivo sepa discernir de un identificador de usuario y la

contraseña perteneciente al mismo. Cada una de las filas del archivo almacena una

dupla para un nuevo usuario.

3.4.6 Archivo log.txt

El archivo log.txt registra las acciones que los usuarios realizan en el Sistema.

Cada uno de los registros del archivo representa una operación realizada por un usuario

en la fecha y la hora especificados. Estos registros están formados por un número entero

que indica el orden en el que ocurrieron las acciones, la fecha y la hora, el usuario que

invoco la acción y un texto que detalla que acción fue realizada por el usuario o el

Sistema.


118

4. RESULTADOS


119

4. RESULTADOS

4.1 CASOS DE USO

Los casos de uso pretenden ofrecer una visión detallada del modo en que

funciona el Sistema en determinadas circunstancias. Inicialmente, para cada caso de

uso, se presenta el escenario de partida desde el que se desea realizar la acción

especificada. Este escenario tiene una serie de elementos

4.1.1 Inicio de sesión en el Sistema

Tipo usuario: Usuario estándar

Acción objetivo: Se pretende iniciar sesión en el Sistema de automatización y control

DOM.

Acciones previas: Anteriormente al inicio de sesión en el Sistema, el usuario deberá

haber iniciado una instancia del navegador web tecleando la dirección de acceso al

servicio en la barra de dirección del mismo. La dirección que se debe teclear es la

siguiente: http://localhost/proyecto.html.

Restricciones: El usuario que deseé iniciar sesión en el Sistema deberá contar con un

identificador de usuario y una contraseña dados de alta en el Sistema, concretamente en

el archivo contrasenya.txt.

Caso de uso: En primer lugar, cuando un usuario quiere acceder al Sistema s necesario

que cumplimente toda la información que aparece en la ventana de autenticación que se

carga automáticamente en su navegador una vez que a tecleado la dirección URL

mencionada anteriormente. La información requerida es el nombre DNS o dirección IP

del servidor que le va a proporcionar el servicio, y por tanto el que debe validarle, el

identificador de usuario y la contraseña, que han debido serle proporcionados

previamente.

Una vez introducida la información, pulsando el botón Aceptar la aplicación

cliente abrirá un canal de comunicación al servidor que proporciona el servicio,

utilizando la dirección IP provista anteriormente, un protocolo de transmisión, un puerto

y un directorio en el servidor web donde encontrar el servlet que va a tratar la

información enviada. Dicho canal será utilizado para enviar los datos introducidos en la


120

ventana de autenticación. Además, este canal es aprovechado por el servidor para

responder al usuario que realizó la petición original. Esto se hace fundamentalmente

para ahorrar recursos, aumentando la eficiencia del proceso de respuesta.

Cuando el servidor web recibe la petición HTTP, éste la redirecciona al servlet

especificado, en este caso /servlet/prj.server.DOMServerManagement. Inicialmente,

este servlet comprueba si el navegador web del usuario ha insertado una cookie en el

lugar del mensaje de request que corresponde. Esta comprobación es necesaria porque

los usuarios identifican el estado de su sesión a través de estas cookies. En caso de que

el usuario no proporcione una cookie, cosa que sucederá pues es la primera vez que

accede al servicio, el Sistema generará un identificador único, al tiempo que construye

un contexto del estado de la sesión del usuario en memoria, que asignará al usuario y

que éste, a su vez, devolverá en forma de cookie en sucesivas peticiones.

A continuación, utilizando este contexto y el identificador de la acción que el

usuario desea ejecutar, que viene insertado en el mensaje, el Sistema es capaz de

ejecutar la dicha acción. Para esto, se emplea una tabla de decisión (sección 3.2.2.3

Comportamiento) que permite saber, dado el estado actual en el que se encuentra la

sesión del usuario y la acción solicitada a través del mensaje, si es posible o no ejecutar

la acción en cuestión y cual será el estado en que quedará el sistema después ejecutarla.

En el caso de la acción de inicio de sesión, si se mira la tabla de decisión citada, se

puede comprobar que es únicamente posible estando la sesión del usuario en estado 0.

NoAutenticado, y recibiendo el mensaje de tipo Conexión, lo que provocaría una

transición al estado 0. NoAutenticado al estado 2. RespuestaOK o 3. RespuestaError, en

función de si la operación se ha realizado con o sin éxito.

Una vez que el Sistema a determinado que la acción solicitada está permitida en

el contexto de la sesión se comprueba que el usuario a proporcionado correctamente la

información de inicio de sesión, identificador de usuario y contraseña. Para ello se

recorre el archivo contrasenya.txt ubicado en el servidor web en busca de una pareja de

identificador de usuario y contraseña que coincida con la información proporcionada

por el usuario. Si la información provista es correcta el usuario accederá a la ventana de

gestión de los dispositivos electrónicos, en caso contrario recibirá un mensaje de error

debiendo realizar el proceso de inicio de sesión nuevamente.


121

4.1.2 Recopilación periódica de datos de los sensores


Acción objetivo: Se pretende actualizar el interfaz de usuario de forma periódica con

datos procedentes de los sensores del Sistema.

Acciones previas: Previo a empezar a actualizar el interfaz de la aplicación cliente con

información procedente de los sensores, el usuario ha debido iniciar sesión en el

Sistema. Después, éste ha tenido que seleccionar el módulo de la habitación cuyos

sensores desea empezar a monitorizar.

Restricciones: Cada dos segundos, el Sistema envía información actualizada

procedente de los sensores a la aplicación cliente. Al tratarse de una aplicación de

tiempo real ‘sof’ no es necesario, aunque sí deseable, que se respete el intervalo de

tiempo fijado de dos segundos entre la llegada de datos actualizados. Esta restricción

temporal se debe al hecho de que algunos sensores, como es el caso del sensor de

movimiento, no son capaces de mantener activa la señal de detección de un

determinado evento más de dos segundos. Por tanto, si el intervalo de refresco de datos

del Sistema fuera mayor de dos segundos se correría un riesgo de no detección del

evento.

Caso de uso: Una vez que el usuario ha obtenido acceso al Sistema, en el panel de la

izquierda de la ventana de administración de dispositivos se cargará automáticamente la

jerarquía de disposición, que permitirá al usuario navegar hasta la habitación del

inmueble que desea monitorizar y controlar. Esta jerarquía de navegación es generada

de forma automática por la aplicación cliente a partir del archivo de configuración

config.xml enviado por el servidor cuando el inicio de sesión ha sido correcto. El

contenido de dicho archivo es interpretado, mediante la utilización de un parseador, que

es utilizado para construir de forma flexible y automática la jerarquía.

Una vez que se ha cargado completamente la jerarquía, es posible acceder al

espacio del inmueble que se desea monitorizar o controlar. Si se selecciona uno de los

módulos de dicho espacio, se cargan automáticamente, en el panel derecho de la

ventana de administración de dispositivos, los sensores y actuadores del módulo. Acto

seguido, se lanza un proceso en modo secundario, para que no afecte al proceso

principal que gestiona el comportamiento del interfaz de usuario, el cual recopila los

datos de los sensores en función del intervalo de tiempo establecido, dos segundos en


122

este caso. Por tanto, la aplicación cliente recibirá cada dos segundos datos actualizados

desde los sensores. Estos datos serán utilizados para ir modificando el aspecto del

interfaz de usuario de manera que éste sea capaz de representar la información que le

llega desde los sensores de forma inteligible para el usuario.

Para intentar degradar el rendimiento del Sistema lo menos posible, la

comunicación entre el componente Cliente y el Servidor se realiza utilizando un

segundo servlet. Por tanto, mientras un primer sevlet supervisa la ejecución de tareas

tales como el inicio o fin de sesión, la transmisión del archivo de configuración o la

modificación del comportamiento, un segundo servlet gestiona el proceso de

distribución periódica de datos. En todo momento se ha pretendido evitar que un

proceso periódico pudiera penalizar el funcionamiento de otro proceso esporádico.

El mecanismo utilizado en este segundo servlet es el mismo que en el anterior.

Por un lado el cliente envía solicitudes de lectura de los sensores, mediante el envío de

mensajes del protocolo de control embebidos en mensajes HTTP, mientras que por otro

lado el servidor responde a esos mensajes con el envío de mensajes de respuesta de

lectura de los sensores, que también embebe en mensajes HTTP.

4.1.3 Control del comportamiento de los actuadores


Acción objetivo: Se pretende controlar el comportamiento de los actuadores del

Sistema de forma remota.

Acciones previas: Antes de realizar cualquier acción que permita controlar el

comportamiento de cualquiera de los actuadores que integran el Sistema, el usuario ha

debido iniciar sesión en el Sistema. Después, éste ha tenido que seleccionar el módulo

de la habitación cuyos dispositivos de actuación desea controlar.

Restricciones: Únicamente es posible tomar acciones simultáneamente sobre los

actuadores que se encuentran en un mismo módulo.

Caso de uso: Una vez que el usuario ha obtenido acceso al Sistema, en el panel de la

izquierda de la ventana de administración de dispositivos se cargará automáticamente la

jerarquía de disposición, que permitirá al usuario navegar hasta la habitación del


123

inmueble que desea monitorizar y controlar. Una vez allí, en usuario seleccionará el

módulo donde se encuentran el/los actuador/es cuyo comportamiento desea controlar.

El funcionamiento interno del proceso de control de los sensores del Sistema es

similar a la forma en que se comporta el Sistema para recabar información de los

sensores y enviarla a la aplicación cliente. Sólo que, en este caso, los mensajes que

intercambian cliente y servidor son mensajes de solicitud de acción sobre un actuador y

respuesta del éxito o fracaso de la ejecución de dicha solicitud. La forma de

intercambiarlos es la misma que la utilizada en la recuperación de datos desde los

sensores, es decir, se continúa utilizando el protocolo HTTP como protocolo

subyacente.

Cuando un usuario ha accedido al módulo donde se encuentra el actuador que

desea gestionar, éste utiliza el interfaz de dicho actuador para definir un nuevo

comportamiento para el mismo. En el caso de los actuadores, a pesar que el interfaz de

los mismos es actualizado con la misma periodicidad que el de los sensores,

simplemente por el hecho de monitorizar el comportamiento que están teniendo en el

momento actual, una vez que sus interfaces han sido modificados ya no admiten ser

refrescados, para permitir al usuario enviar los nuevos parámetros de comportamiento

que ha seleccionado. Una vez que estos parámetros han sido establecidos, sólo se

requerirá apretar el botón Aceptar y las información será enviada, recibiendo un

mensaje de respuesta del éxito o fracaso de la operación.

El funcionamiento de la operación de envío del mensaje de solicitud de acción

sobre un actuador es exactamente igual que el del mensaje de solicitud de inicio de

sesión. En primer lugar se abrirá un canal de comunicación hacia el servidor que

proporciona el servicio, utilizando la dirección IP provista en la ventana de

autenticación, un protocolo de transmisión, un puerto y un directorio en el servidor web

donde encontrar el servlet que va a tratar la información enviada. Dicho canal será

utilizado para enviar los datos de control de comportamiento del actuador o actuadores

seleccionados, ya que es posible enviar un mensaje para controlar el comportamiento de

varios actuadores, siempre y cuando se encuentren en el mismo módulo. Además, este

canal será aprovechado por el servidor para responder al usuario que realizó la petición

original, ahorrando recursos y aumentando la eficiencia del proceso de respuesta.


124

4.2 Secuencia intercambio de mensajes del protocolo de control DOM

A continuación se muestra de forma detallada lo que podría considerarse una

secuencia típica de intercambio de mensajes entre nodos del Sistema empleando el

Protocolo de control DOM 1.0, documentado con anterioridad en el apartado 2.3

Modelo conceptual de datos:

Paso 1. Establecimiento de conexión (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5505” idMensajeAck=”0”>

<conjuntoInstrucciones idConjuntoInstrucciones=”5505”> <instruccion idInstruccion=”1” tipo=”8” descripcionTipo=”conexion”> <texto> <identificacion>[email protected]</identificacion> <contrasenya>xxxx</contrasenya> </texto>

</instruccion> </conjuntoInstrucciones>

</mensaje> Paso 2. Contraseña errónea (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23588” idMensajeAck=”5505”>

<conjuntoInstrucciones idConjuntoInstrucciones=”23588”> <instruccion idInstruccion=”1” tipo=”4” descripcionTipo=”respuestaError”> <texto>

<informacion tipo=”2” descripcionTipo=”error”>Contrasenya errónea</informacion>

</texto> </instruccion>


Paso 3. Confirmación de la respuesta (Acknowledge-reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5506” idMensajeAck=”23588”>

<conjuntoInstrucciones idConjuntoInstrucciones=”5506”> <instruccion idInstruccion=”1” tipo=”3” descripcionTipo=”respuestaOk”> </instruccion>


125


Paso 4. Nuevo intento de establecimiento de conexión (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5507” idMensajeAck=”0”>

<conjuntoInstrucciones idConjuntoIntrucciones=”5507”> <instruccion idInstruccion=”1” tipo=”8” descripcionTipo=”conexion”> <texto> <identificacion> [email protected] </identificacion> <contrasenya>xxxx</contrasenya> </texto>


</mensaje> Paso 5. Contrasenya correcta (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23589” idMensajeAck=”5507”>

<conjuntoInstrucciones idConjuntoInstrucciones=”23589”> <instruccion idInstruccion=”1” tipo=”6” descripcionTipo=”respuestaConfig”> <texto>

<informacion tipo=”3” descripcionTipo=”datos”> <![CDATA[<Archivo de configuración XML>]]> </informacion>



Paso 6. Archivo de configuración recibido (Acknowledge-reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5508” idMensajeAck=”23589”>

<conjuntoInstrucciones idConjuntoInstrucciones=”5508”> <instruccion idInstruccion=”1” tipo=”3” descripcionTipo=”respuestaOk”> </instruccion> </conjuntoInstrucciones> </mensaje>


126

Paso 7. Petición de lectura sensores (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5509” idMensajeAck=”0”>

<conjuntoInstrucciones idConjuntoInstrucciones=”5509”> <instruccion idInstruccion=”1” tipo=”1” descripcionTipo=”lecturaHard”>


</mensaje> Paso 8. Respuesta de lectura sensores (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23590” idMensajeAck=”5509”>

<conjuntoInstrucciones idConjuntoInstrucciones=”23590”> <instruccion idInstruccion=”1” tipo=”7” descripcionTipo=”respuestaHard”> <texto>

<informacion tipo=“3” descripcionTipo=”datos”> <![CDATA[<Archivo XML histórico>]]> </informacion>


</conjuntoInstrucciones> </mensaje> Paso 10. Escritura en actuador (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5511” idMensajeAck=”0”>

<conjuntoInstrucciones idConjuntoInstrucciones=”55011”> <instruccion idInstruccion=”1” tipo=”2” descripcionTipo=”escrituraHard”>

<dispositivo idModulo=”7” idDispositivo=”76” pin=“23” valor=”25” tipo=”PWM”/>

</instruccion> <instruccion idInstruccion=”2” tipo=”2” descripcionTipo=”escrituraHard”>

<dispositivo idModulo=”7” idDispositivo=”77” pin=“1” valor=”0” tipo=”PWM”/>


</mensaje>


127

Paso 11. Escritura correcta (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23591” idMensajeAck=”5511”>

<conjuntoInstrucciones idConjuntoInstrucciones=”23591”> <instruccion idInstruccion=”1” tipo=”3” descripcionTipo=”respuestaOk”> <texto>

<información tipo=”1” descripcionTipo=”informacion”>Escritura completada</informacion>



Paso 12. Confirmación de respuesta (Acknowledge-reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5512” idMensajeAck=”23591”>


Paso 13. Desconexión (Request message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5513” idMensajeAck=”0”>

<conjuntoInstrucciones idConjuntoInstrucciones=”5513”> <instruccion idInstruccion=”1” tipo=”9” descripcionTipo=”desconexion”> <texto> <identificacion>[email protected]</identificacion> <contrasenya>xxxx</contrasenya> </texto>


</mensaje>


128

Paso 14. Respuesta de desconexión (Reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”23592” idMensajeAck=”5513”>

<conjuntoInstrucciones idConjuntoInstrucciones=”23592”> <instruccion idInstruccion=”5510” tipo=”3” descripcionTipo=”respuestaOk”> <texto>

<información tipo=”1” descripcionTipo=”informacion”>Gracias por usar el sistema</informacion>

</texto> </instruccion> </conjuntoInstrucciones>

</mensaje> Paso 15. Confirmación de respuesta (Acknowledge-reply message) <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE mensaje SYSTEM "dtd/DOM.dtd"> <mensaje idMensaje=”5514” idMensajeAck=”23592”>



129

5. CONCLUSIONES


130

5. CONCLUSIONES

5.1 Conclusiones finales

Las principales conclusiones que se pueden extraer tras la ejecución del

proyecto Sistema de automatización y control DOM, son las siguientes:

• En primer lugar, expresar la gran satisfacción personal que supone la

finalización del proyecto, y con él la consecución de los objetivos que fueron

fijados en un principio. Al mismo tiempo, también debo expresar una ligera

decepción por no haber sido capaz de llegar a integrar el sistema software con el

sistema hardware para el que fue diseñado, como era intención inicialmente.

• También me gustaría destacar el conocimiento técnico adquirido sobre áreas tan

diversas como los Sistemas de Tiempo Real, el funcionamiento de los sensores y

los actuadores, el Lenguaje Extensible de Marcas (XML) y los parseadores o el

diseño e implementación de soluciones software con tecnologías Java como son

applet y servlet.

• Por otra parte, desde un punto de vista más técnico, considero interesante

resaltar el espíritu original y el carácter innovador del proyecto, pues se ha

intentado desde un principio diseñar e implementar un sistema de tiempo real

que fuese gestionado a través de Internet, empleando para ello nuevas

tecnologías afines a la red.

• Producto del espectacular crecimiento que está experimentando Internet en los

últimos años, es un muy habitual encontrar un número cada vez mayor de

aplicaciones que migran de arquitecturas mas pesadas, como es el caso de la

arquitectura cliente-servidor tradicional, a arquitecturas mucho mas ligeras y

escalables, como es el caso de la arquitectura web. Esta es, sin lugar a dudas, la

línea de acción que ha pretendido seguir el proyecto desde su concepción inicial.

Esto ha implicado realizar un esfuerzo importante para adaptar el modo de

operar de un sistema de automatización y control en tiempo real, como es un


131

sistema domótico/inmótico, a las características que requiere Internet. Algo que

de alguna manera mas o menos acertada se ha logrado.

• Esta migración entre arquitecturas ha propiciado una convergencia entre

tecnologías que a priori podrían parecer totalmente independientes, como son la

domótica/inmótica y las tecnologías relacionadas con Internet (xml, servlet,

applet, HTTP, etc.)

• Desde el punto de vista comercial, esta convergencia favorece y extiende la

utilización de los sistemas domóticos/inmóticos a un segmento de mercado

mucho mayor ya que, como es evidente, la utilización de Internet así como de

las nuevas tecnologías que lo rodean está mucho mas extendida que cualquier

otro sistema domótico/inmótico propietario.

• Sin embargo, contrastando con todos estos aspectos positivos, también sería de

justicia comentar que la actual infraestructura de Internet y el modo de en que

funcionan las nuevas tecnologías no ofrecen suficientes garantías para la

implementación un sistema de tiempo real. Tendrá que pasar mucho tiempo

hasta que sea posible desarrollar un sistema comercial de este tipo que ofrezca

las suficientes garantías en lo que a tiempo de respuesta, disponibilidad,

fiabilidad, mantenibilidad y seguridad respecta.


132

6. FUTUROS DESARROLLOS


133

6. FUTUROS DESARROLLOS

6.1 Futuros desarrollos

El Sistema de control y automatización DOM, una vez concluido el proyecto, es

plenamente operativo, realizando todas las tareas para las que fue concebido

inicialmente. Sin embargo, como cualquier otro sistema, es susceptible de ser mejorado

en multitud de aspectos. A continuación se citan algunos de los puntos que podrían ser

susceptibles de ser desarrollados en mayor profundidad:

• Actualmente, el Sistema es controlado completamente por el usuario. A partir de

las mediciones realizadas por los sensores el usuario puede decidir aplicar un

comportamiento u otro a los actuadores. Un futuro desarrollo muy interesante

sería intentar aplicar algo de inteligencia artificial al Sistema. Mediante la

utilización de reglas sería posible predefinir el comportamiento general del

Sistema ante la ocurrencia de una cadena de eventos.

• Otro punto del Sistema susceptible de ser mejorado es el interfaz de la

aplicación cliente. Actualmente, éste ha sido implementado mediante un applet

que permite al usuario sacar partido de todas las funcionalidades que ofrece el

Sistema. Sin embargo, los applet son sobradamente conocidos por ser grandes

consumidores de recursos. Un área de mejora que admitiría futuros desarrollos

sería buscar una alternativa a los applets para la aplicación cliente. Una solución

• En el Sistema actual no existe ningún mecanismo redundante que permita

recuperar el Sistema ante un fallo eventual. Sin embargo, el Sistema es capaz de

escribir en un archivo de log todas las acciones que va realizando de forma

secuencial. Quizás, un desarrollo futuro podría utilizar dicho log para recuperar

el Sistema hasta el momento actual, utilizando una técnica de tipo checkpoint-

recuperación.


134

ANEXO A


135

MANUAL DE INSTALACIÓN Y CONFIGURACIÓN DEL SISTEMA

A continuación se describe de forma detallada el orden cronológico de los pasos

a seguir para instalar y configurar el Sistema. De esta manera es posible, en cualquier

momento, construir una replica exacta del entorno sobre el que se ha desarrollado el

Sistema.

1. Instalación y configuración del Sistema Operativo

El Sistema Operativo empleado es Windows XP en la versión Home Edition

2002. Además, el parche de mejoras y correcciones instalado es Service Pack 2.

2. Instalación del JDK 1.4.2 (Java Development Kit 1.4.2)

En primer lugar se requiere instalar y configurar Java. La especificación Servlet

y Java Server Pages utilizada es Servlet 2.4 (JSP 2.0), que requiere la instalación de

JDK 1.4 o posterior.

• JDK 1.4:

http://java.sun.com/j2se/1.4/download.html. Es conveniente asegurarse que se

descarga el JDK por completo (J2SE Development Kit), no sólo el JRE (Java

Runtime Environment). JRE únicamente permite ejecutar archivos .class ya

compilados; carece de compilador

Una vez que se ha instalado java, hay que corroborar que todo, incluyendo la

variable PATH, ha sido configurado adecuadamente. Esto puede comprobarse abriendo

una ventana de la consola y tecleando "java -version" y "javac -help". Si Java ha

sido instalado de forma correcta se debería obtener un mensaje, no un mensaje de error

de comando desconocido.


136

Existen dos alternativas para configurar la variable PATH:

• Escribiendo la siguiente línea en el archivo C:\autoexec.bat.

set PATH="C:\j2sdk1.4.2_10\bin";%PATH%

• Seleccionar Inicio � Configuración � Panel de control. Elegir el icono

Sistema, haciendo clic en el la solapa Avanzado, pulsar el botón Variables de

entorno situado al final de la pantalla, introduciendo el valor para la variable

PATH.

3. Instalación y configuración del servidor web Apache Tomcat 5.5.15

3.1 Descarga del software Apache Tomcat 5.5.15

El enlace para realizar la descarga del software Apache Tomcat 5.5.15 es

http://tomcat.apache.org/download-55.cgi. Además, también se deberá descargar el

archivo Compat.zip que permite la compatibilidad entre Tomcat y JDK 1.4.

Los ficheros se deben guardar en el PC, debiendo ser descomprimidos en la

ubicación elegida por el usuario. Por tanto, si se especifica un directorio de

descompresión tal como “C:\”, y el archivo .zip internamente incluye un directorio tal

como “apache-tomcat-5.5.15”, entonces el directorio resultante donde será instalado el

software será C:\apache-tomcat-5.5.17.

Nota: De ahora en adelante, esta localización será referida como install_dir.

3.2 Establecimiento de la variable JAVA_HOME

A continuación, es necesario establecer la variable JAVA_HOME que indica a

Tomcat el directorio donde está instalado Java. Esta variable debería listar el directorio

de instalación del JDK, no el directorio bin. Al igual que para la variable PATH, existen

dos formas de configurar la variable JAVA_HOME:


137

• Escribiendo la siguiente línea en el archivo C:\autoexec.bat.

set JAVA_HOME=C:\j2sdk1.4.2_10




JAVA_HOME.

3.3 Establecer el puerto por defecto para HTTP a 80

Suponiendo que no exista otro servior web instalado en el PC que ya esté

empleando el puerto 80, será conveniente configurar Tomcat para atender las peticiones

recibidas en el puerto predeterminado de HTTP (80), en lugar del puerto 8080

configurado por defecto. Hacer este cambio permitirá utilizar URLs del tipo

http://localhost/recurso_solicitado en lugar http://localhost:8080/recurso_solicitado.

Algunas veces, el servidor web IIS (Internet Informatio Server) está configurado por

defecto para atender peticiones en el puerto 80, razón por la cual deberá ser

deshabilitado si se quiere que Tomcat utilice el puerto 80.

Para cambiar el puerto, es necesario editar el archivo install_dir/conf/server.xml

y cambiar el atributo puerto del elemento Connector de 8080 a 80, obteniendo un

resultado similar al siguiente:

<Connector port="80" ...

maxThreads="150" ...

3.4 Activar la característica Servlet Reloading

El siguiente paso consiste en configurar Tomcat para que detecte las fechas de

modificación de los archivos .class de los servlets solicitados, y proceder a la recarga de

aquellos que han cambiado después de que inicialmente fueran cargados en memoria.

La activación de esta característica produce una ligera degradación del rendimiento en

situaciones de desarrollo, por lo que dicha características está deshabilitada por defecto.


138

Sin embargo, no activar esta característica en un contexto de desarrollo supone reiniciar

el servidor web cada vez que se recompile una servlet que será cargado en memoria.

Para activar la característica Servlet Reloading, se edita el archivo

install_dir/conf/context.xml cambiando:

<Context>

a <Context reloadable="true">

3.5 Habilitando el Invoker Servlet

El Invoker Servlet es una característica del servidor web que permite ejecutar

los servlet sin tener que escribir un fichero web.xml en el directorio ‘WEB-INF’. Sólo

hay que arrastrar las clases del servlet dentro del directorio WEB-INF/classes y utilizar

la URL http://host/servlet/ServletName para invokar al servlet.

Para habilitar la caracteística Invoker Servlet se deben quitar los comentarios a

los elementos servlet y servlet-mapping del fichero web.xml del directorio

install_dir/conf:

<servlet>

<servlet-name>invoker</servlet-name>

<servlet-class>

org.apache.catalina.servlets.InvokerServlet

</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>

Invoker

</servlet-name>

<url-pattern>

/servlet/*

</url-pattern>

</servlet-mapping>


139

3.6 Comprobación de la instalación correcta del servidor

3.6.1 Verificación de que el servidor puede arrancar

Antes de ejecutar los servlets asociados a la aplicación se debería comprobar

que el servidor ha sido instalado y configurado adecuadamente. Para iniciar el servidor

se deberá ejecutar el archivo install_dir/bin/startup.bat. A continuación, se deberá

teclear la URL http://localhost/ en el navegador para obtener la página de bienvenida de

Tomcat, y no un mensaje de error diciendo que la página no puede ser mostrada o que

el servidor no ha sido encontrado.

Por otra parte, para detener el servidor web se deberá ejecutar el archivo

install_dir/bin/shutdown.bat. Como se detallará mas adelante, es recomendable obtener

accesos directos a los archivos startup.bat y shutdown.bat (no copias a ellos)

ubicándolos en el Escritorio de Windows XP o en el directorio principal de desarrollo

para iniciar o detener Tomcat de forma mas ágil.

3.6.2 Intentar ejecutar algunas páginas HTML y JSP sencillas

Después de haber verificado que el servidor se está ejecutando con normalidad,

se debería comprobar que es posible instalar y acceder a páginas HTML y JSP sencillas.

Si esta comprobación funciona correctamente mostrará dos cosas:

• En primer lugar, acceder a las páginas HTML y JSP significa que se ha

comprendido en qué directorios hay que ubicar las páginas HTML y las páginas

JSP, así como que URLs utilizar para acceder a las mismas.

• Además, acceder de forma satisfactoria a una página JSP implica que el

compilador de Java, no solamente la máquina virtual de Java, ha sido

configurada de forma correcta.

Por otra parte, y con fines de testeo, es posible utilizar la aplicación web por

defecto que ofrece Tomcat. Para ello, será necesario ubicar las páginas HTML y JSP en


140

el directorio install_dir/webapps/ROOT y accederlas empleando la URL

http://localhost/filename. Por ejemplo, si se quiere recuperar el recurso Hola.html del

servidor web, será necesario utilizar la URL http://localhost/Hola.html. Si, debido a

cualquier otra circunstancia, se decidiera ubicar el archivo Hola.html en un

subdirectorio dentro de install_dir/webapps/ROOT, la URL que se debería utilizar sería

http://localhost/nombreDirectorio/Hola.html.

Finalmente, si el servidor web fue inicializado correctamente, pero por el

contrario no es posible visualizar páginas HTML o JSP entonces, probablemente, se

está utilizando el directorio equivocado para los archivos. Pero si lo que funciona son

las páginas HTML y no las JSP es muy probable que se haya especificado de forma

incorrecta el directorio base del JDK para la variable JAVA_HOME.

3.6.3 Intentar compilar e instalar servlets

Una vez que se ha establecido el entorno de desarrollo, es necesario asegurarse

de verificar que se pueden compilar y ejecutar servlets sin ningún problema.

4. Configurar el entorno

El script de inicalización startup.bat establece el CLASSPATH del servidor de

manera que se incluya el servlet estándar y las clases JSP, así como el directorio WEB-

INF/classes, que contiene los servlets compilados de cada aplicación web. Pero son

necesarias configurciones similares, de lo contrario no será posible compilar servlets.

Configurar el sistema para desarrollar servlets inplica cuatro puntos.

4.1 Crear un directorio de desarrollo

En primer lugar, para configurar un entorno de desarrollo adecuado, es necesario

crear un directorio en el cual ubicar los servlets y las páginas JSP desarrolladas. Este

directorio puede estar en el directorio particular del usuario (C:\Documentsand

Settings\AlbertoCarrasco\Misdocumentos\Alberto\Servlets+JSP) o en cualquier otra


141

ubicación (C:\Servlets+JSP). Sin embargo, dicho directorio nunca debiera ser ubicado

en el directorio de distribución de Tomcat, en algún lugar dentro de

install_dir/webapps.

Al principio, este directorio estará organizado en diferentes aplicaciones web.

Además, con fines de testeo es posible ubicar servlets tanto directamente en el

directorio de desarrollo como en un subdirectorio que identifique el nombre del paquete

del servlet. Aunque desarrollar en el directorio de distribución de Tomcat parece más

sencillo al principio, ya que no requiere mantener copias de los archivos, esto complica

significativamente asuntos relacionados con la forma de funcionar del servidor. Mezclar

ubicaciones hace difícil separar una versión operativa de otra versión que está siendo

comprobada, hace difícil chequear en varios servidores, y hace que la forma de

organizarse sea mucho mas complicada. A pesar de esto, es muy probable que el PC

donde se está trabajando no sea el servidor de distribución definitivo, por lo que será

necesario configurar otra máquina para realizar las tareas de distribución.

Nota: Es importante que se tenga clara la diferencia entre el directorio de desarrollo,

empleado para realizar editar y modificar los fuentes, y el directorio de distribución que

es el lugar donde deben ser ubicados los servlets y/o páginas HTML y JSP que se quiere

sean accedidos por los clientes.

4.2 Crear accesos directos a los scripts que arrancan y detienen el Servidor

Resulta conveniente situar los accesos directos a los scripts que arrancan y

detienen el servidor en un lugar de fácil acceso, como pueda ser el propio directorio de

desarrollo o incluso el escritorio.

La forma mas sencilla de obtener dichos accesos directos es acudir al directorio

install_dir/bin y hacer clic con el botón derecho del ratón sobre el archivo startup.bat,

seleccionado la opción Copiar del menú emergente. Después, una vez que se está

posicionado en el directorio deseado, se hace clic con el botón derecho del ratón y se

selecciona la opción Pegar como acceso directo (nunca solamente Pegar). Se debe

repetir el proceso para el archivo install_dir/bin/shutdown.bat. Además, si se ubican en


142

el escritorio los accesos directos es posible asignar a éstos una combinación de teclas

que permita ejecutarlos.

4.3 Configuración de la variable de entorno Classpath

Dado que los servlets y las páginas JSP no son parte de la plataforma Java 2

Standard Edition (J2SE), es necesario identificar al compilador qué las clases emplea la

tecnología servlet. El servidor ya sabe qué clases requiere la tecnología servlet, así

como donde están ubicadas, pero al compilador (javac) que está siendo utilizado hay

que indicárselo. Por lo tanto, si no se establece la variable CLASSPATH, los intentos de

compilar sevlets, tag libraries, filters, wep app listeners u otras muchas clases que

utilizan las APIs de sevlet y JSP fallarán, generando mensajes de error acerca la

utilización de clases desconocidas. A continuación se muestran las ubicaciones estándar

de los archivos .jar necesarios para implementar lo anterior:

• install_dir/common/lib/servlet-api.jar

• install_dir/common/lib/jsp-api.jar

Ambos archivos necesitan ser incluidos en la variable CLASSPATH.

Por otra parte, además de incluir la ruta hacia el archivo .jar para servlet en la

variable CLASSPATH, también es necesario incluir en la variable la ruta al directorio de

desarrollo. Esto será conveniente cuando se desarrolle utilizando paquetes de usuario.

Compilar un archivo que está ubicado en un paquete, que además utiliza una clase que

se encuentra en un paquete definido por el usuario, requiere que la variable CLASSPATH

incluya el directorio de mayor nivel en la jerarquía de paquetes.

Finalmente, el directorio actual debería ser incluido en CLASSPATH. De otra

forma, solamente se podrán compilar clases que no pertenezcan a ningún paquete y que

se encuentren el nivel más alto del directorio de desarrollo.


143

Existen dos métodos para configurar la variable CLASSPATH:

• Editando y modificando el archivo autoexec.bat,

set CLASSPATH=.;

C:\Servlets+JSP;

install_dir\common\lib\servlet-api.jar;

install_dir\common\lib\jsp-api.jar




CLASSPATH.

4.4 Guardar una referencia a la documentación del API de servlet y JSP

Es posible acceder a la documentación desde la home de Tomcat, pero

probablemente será necesario utilizar la documentación incluso si el servidor no está

corriendo. De esta manera, es recomendable guardar un acceso directo al API en el

escritorio o en cualquier otro lugar de fácil acceso.

Aquí se muestran las rutas por defecto donde se almacena la ayuda acerca de la API:

• Servlet API: install_dir/webapps/tomcat-docs/servletapi/index.html

• JSP API: install_dir/webapps/tomcat-docs/jspapi/index.html

5. Estableciendo un método de distribución sencillo

Ahora que ya se ha creado el directorio de desarrollo, es posible compilar

servlets que utilicen o no una jerarquía de paquetes. Se sabe a qué directorio pertenecen

las clases que requiere servlet. También se conoce qué URL utilizar para acceder a


144

dichos servlets (http://hostname/servlet/ServletName es la URL por defecto). Pero,

¿cómo se transportan los archivos .class desde el directorio de desarrollo al directorio

de distribución? En principio, la idea de copiar a mano cada vez los archivos de un

directorio a otro es un método que puede provocar errores.

La alternativa más interesante que permite simplificar este proceso es pegar un

acceso directo al directorio de distribución en el directorio de desarrollo. Para ello, una

vez posicionado en el directorio install_dir/webapps/ROOT/WEB-INF, se hace click

con botón derecho del ratón en el directorio classes y se selecciona Copiar. Entonces, se

acude al directorio de desarrollo, donde se hace clic en el botón derecho del ratón y se

selecciona Pegar como acceso directo (nunca solamente Pegar). Así, y de ahora en

adelante, cuando se compile un servlet sin paquetes solamente será necesario arrastrar

los archivos .class al acceso directo. Y cuando se desarrolle en paquetes, sólo será

necesario utilizar el ratón para arrastrar el paquete entero al acceso directo.

6. Instalando el IDE Eclipse 3.0

Eclipse 3.0 es una IDE que permite escribir, compilar y depurar aplicaciones

Java. Además, las funcionalidades de Eclipse pueden ser ampliadas si se instala

cualquiera de los plug-ins que hay disponibles en el mercado, muchos de ellos de forma

gratuita, que permiten realizar una amplia variedad de actividades, que van desde

controlar la versión de desarrollo de los archivos que integran el proyecto hasta realizar

tareas de ingeniería inversa para obtener diagramas UML desde código.

Eclipse 3.0 puede ser descargado, de forma gratuita, desde la página web de la

organización que lo ha desarrollado (http://www.eclipse.org/downloads/index.php).

Normalmente, las distribuciones se proporcionan en un archivo .zip. Una vez finalizada

la descarga, se procede a la instalación del software. Para ello, y puesto que Eclipse 3.0

todavía no facilita ningún ejecutable que facilite el proceso de instalación, se debe

descomprimir el archivo .zip en el directorio donde normalmente son instalados los

programas. Esto creará un directorio llamado eclipse. Un archivo ejecutable será

ubicado en dicho directorio con el nombre eclipse.exe. Es recomendable crear un acceso

directo a partir de este archivo que debiera ser ubicado en el escritorio de Windows XP.


145

Eclipse almacena todos proyectos que se van creando en un directorio llamado

área de trabajo. Cuando Eclipse es ejecutado por primera vez, éste preguntará donde se

debe emplazar el área de trabajo. Es posible utilizar la ubicación por defecto

seleccionando el directorio donde Eclipse fue instalado. En el caso que nos ocupa el

área de trabajo de Eclipse 3.0 ha sido ubicada en el directorio de desarrollo

anteriormente citado.

7. Ubicación de los archivos del Proyecto

Como se ha explicado a lo largo de este documento de Proyecto, el Sistema se

sirve de en un conjunto de archivos para poder desarrollar su actividad. A continuación

se citan los archivos que son necesarios para el funcionamiento del Sistema, así como el

directorio donde se ubican:

• Los archivos config.xml, actualizacion.xml, historico.xml, contraseña.txt y

log.txt se ubican en el directorio files, dentro de install_dir\webapps\ROOT.

• Los archivos b1.gif, b1r.gif y Log-Off.jpeg son archivos utilizados por el interfaz

de usuario de la herramienta cliente. Estos archivos se ubican en el directorio

install_dir\webapps\ROOT\images.

• El archivo aelfred.jar es un pequeño parseador que es descargado por el cliente

desde el servidor para permitirle interpretar el contenido de los streams XML

enviados por este último. Este archivo se ubica en el directorio

install_dir\webapps\ROOT/WEB-INF\classes.

8. Asignación de permisos mediante la utilización de un archivo java.policy

El archivo java.policy es un archivo que define una política global de permisos

para todas las aplicaciones Java que corren en la máquina virtual de Java del nodo que

implementa dicho archivo. Este archivo esta ubicado en el directorio personal que cada

usuario tiene asignado en Windows XP, C:\Documents and Settings\nombre_usuario.


146

De esta forma los permisos recogidos en un archivo java.policy son de aplicación única

y exclusiva en la sesión del usuario al que están asociados. El archivo de política global

de permisos utilizado en el Sistema es el siguiente:

grant codeBase "http://localhost/" {

ermission java.security.AllPermission;

};

grant codeBase "file:/C:/apache-tomcat-5.5.15/webapps/ROOT/WEB-INF/classes/" {

permission java.io.FilePermission "<<ALL FILES>>", "read";

};


147

ANEXO B


148

MANUAL DE USUARIO

Este manual pretende servir de guía de usuario para la correcta utilización del

Sistema. A continuación se detalla el funcionamiento del interfaz de la aplicación que a

la postre servirá como elemento comunicador entre el usuario y el propio Sistema.

Además del interfaz de la aplicación, también se detallan otros elementos que son

utilizados para la gestión del Sistema, como es caso del log del Sistema.

1. Acceso al Sistema de automatización y control DOM

Para tener acceso al Sistema de automatización y control DOM es requisito

necesario teclear en la barra de dirección del navegador web la URL

http://localhost/proyecto.html. Esta dirección proporciona acceso al servicio que

soporta el Sistema.

La primera parte de la dirección (localhost) identifica el host donde se

encuentran los recursos a los que se quiere tener acceso. En este caso, localhost es un

nombre de host comodín empleado por el servicio DNS para hacer referencia al host

local. Este nombre de host es utilizado en este caso debido a que la máquina que se

quiere acceder es la misma desde la que se ejecuta el navegador web. El nombre de host

localhost mapea a la dirección IP 127.0.0.1, lo que implica que el recurso pudiera

haberse accedido tecleando en la barra de dirección del navegador la URL

http://127.0.0.1/proyecto.html. En el caso que el navegador web fuera ejecutado desde

una máquina distinta a la que almacena el recurso, entonces debería teclearse cualquiera


149

de las siguientes URL http://dirección_IP_local/proyecto.html, o también

http://nombre_host_local/proyecto.html. En el caso de la dirección IP local

posiblemente se requeriría utilizar una dirección IP privada si el Sistema quiere se

utilizado en una intranet, o una dirección IP pública si el Sistema va a ser utilizado

desde cualquier ordenador conectado a Internet. Mientras, en el caso del nombre de host

debería ser utilizado el nombre DNS empleado por el servidor de nombres que da

cobertura a esa parte de la red.

La segunda parte de la dirección identifica el nombre del recurso que se quiere

acceder en el host identificado con anterioridad. En este caso se trata del archivo

proyecto.html que lleva embebido un pequeño programa Java denominado applet, que

proporcionará el mecanismo de comunicación entre el usuario y el Sistema para acceder

a las funcionalidades que este último ofrece.

2. Pantalla de autenticación del usuario

La pantalla de autenticación del Sistema permite controlar el acceso al mismo,

de forma que solamente los usuarios autorizados puedan utilizar el servicio.


150

Esta ventana permite el acceso al Sistema únicamente a aquellos usuarios que

hayan sido previamente registrados para utilizar el Sistema. La ventana está compuesta

de los siguientes elementos:

• Caja de texto ‘Host’, donde se introduce el host que va a proveer el servicio. Los

valores de entrada permitidos son tanto un nombre DNS como una dirección IP.

Una vez introducido el host e iniciada la sesión se permanecerá usando el mismo

host hasta que finalice la sesión y sea posible indicar un nuevo host de

provisión.

Host que va a proveer el servicio.

Identificador de usuario válido para el Sistema.

Contraseña de usuario válida para el Sistema.

Botón de inicio de sesión Botón para agregar un host de provisión de Servicio


151

• Botón ‘…’, que fuerza la aparición de la siguiente ventana emergente para la

introducción de datos, donde es posible insertar el valor que posteriormente

tomará la caja de texto ‘Host’.

• Caja de texto ‘User’, donde se introduce el identificador de usuario que será

utilizado para acceder al Sistema. Dicho identificador de usuario ha tenido que

ser previamente registrado para poder ser verificado a posteriori.

• Caja de texto ‘Password’, donde se introduce la contraseña de usuario que será

utilizada para acceder al Sistema. Dicha contraseña de usuario ha tenido que ser

previamente registrada para ser verificada a posteriori.

• Botón ‘Iniciar sesión’, que permite enviar toda la información de inicio de

sesión al host seleccionado.

En caso de que el inicio de sesión no sea satisfactorio se recibirá el siguiente

mensaje:


152

3. Pantalla de gestión de los dispositivos electrónicos

Una vez que el usuario ha sido autenticado por el Sistema, éste tendrá acceso a

la pantalla de administración de dispositivos del Sistema:

La pantalla de administración está divida en tres partes claramente diferenciadas.

En la parte superior se localiza la barra de herramientas con el botón ‘Exit’ que permite

finalizar la sesión en el Sistema. En la parte izquierda está ubicada la jerarquía de

disposición. Esta jerarquía muestra como están dispuestos en el inmueble los diferentes

sensores y actuadores que integran el Sistema. De esta forma, es posible acceder a

cualquier módulo del Sistema para gestionar los dispositivos asociados al mismo.

Finalmente, a la derecha de la jerarquía de disposición se muestra el interfaz de los

sensores y actuadores asociados al módulo seleccionado en el panel izquierdo, donde se

ubica la jerarquía de disposición. Mediante dichos interfaces es posible recibir

información recogida en tiempo real por los sensores, así como gestionar el

comportamiento de los actuadores.


153

A continuación se muestran con mayor detalle las diferentes partes en que se

estructura la pantalla de administración de dispositivos:

Barra de herramientas Botón de fin de sesión

Módulo al que se asocian sensores y actuadores

Interfaz de sensores y actuadores

Botones para aceptar o cancelar una acción

Jerarquía de disposición


154

4. Acceso a un módulo del inmueble

A través de la jerarquía de disposición es posible acceder al módulo de cuyos

sensores se quiere obtener información. Descendiendo por los diferentes niveles de

dicha jerarquía se accede al espacio del inmueble que se desea monitorizar. Una vez

aquí se debe seleccionar el módulo, ya que un mismo espacio puede tener instalados

uno o más módulos. Si se hace doble click sobre el módulo deseado se cargará

automáticamente en el panel de la derecha el interfaz de los sensores y actuadores

integrados en dicho módulo.

5. Tipos de sensores y actuadores utilizados

El Sistema cuenta con una serie de sensores y actuadores que permiten la

colección de información y el control de los elementos del inmueble respectivamente.

En función de la información que quiera ser recogida o del tipo de elemento del

inmueble que se quiera controlar se utilizarán unos sensores o actuadores.

A continuación se presentan los tipos de sensores analógicos y digitales que

están disponibles en el Sistema:

• Sensor de luz. Este sensor analógico permite medir el índice de luminosidad del

espacio donde está ubicado. El índice de luminosidad se mide de forma

porcentual, de ahí que el sensor de luz permita realizar mediciones que van

desde 0% a 100%. El aspecto del interfaz que tiene asociado este sensor en la

aplicación es el siguiente


155

• Sensor de temperatura. Este sensor analógico permite medir la temperatura del

espacio donde está ubicado. El rango de temperaturas que es posible medir va

desde -10 grados hasta 50 grados. El aspecto del interfaz que tiene asociado este

sensor en la aplicación es el siguiente

• Sensor de movimiento. Este sensor digital permite detectar el movimiento

producido en el espacio donde está ubicado. Este sensor puede tomar los valores

OK cuando no se detecta movimiento, y PRESENCIA cuando se detecta

movimiento. El aspecto del interfaz que tiene asociado este sensor en la


Por otra parte, los tipos de actuadores que pueden ser gestionados por el Sistema

se muestran a continuación:

• Actuador PWM. Este actuador analógico permite controlar el comportamiento

de un motor integrado en un elemento del inmueble. De 0 a 5 son las posibles

velocidades del motor, siendo 0 totalmente parado y 5 la mayor velocidad. El


156

aspecto del interfaz que tiene asociado este sensor en la aplicación es el

siguiente

• Actuador 0/1. Este actuador digital permite controlar el comportamiento de un

elemento del inmueble que requiera un estado de encendido y otro de apagado.

Los posibles valores que puede tomar el actuador son encendido (verde) y

apagado (rojo). El aspecto del interfaz que tiene asociado este sensor en la


6. Monitorización del estado de los dispositivos

Los sensores del Sistema que están integrados en los diferentes módulos,

transmiten de forma periódica la información recogida del entorno a la aplicación

cliente. Esto implica que el interfaz que muestra el estado en que se encuentran los

sensores se modifica periódicamente de forma que permita al usuario realizar un

seguimiento de la información recogida por los sensores.

Por otra parte, los interfaces de los actuadores también son actualizados de

forma periódica con el fin de mostrar las posibles modificaciones que otros usuarios

hayan podido realizar sobre los acuadores del Sistema.


157

7. Actualización del estado de los dispositivos

Los actuadores del Sistema ofrecen la posibilidad de controlar el

comportamiento de algunos de los elementos del inmueble. Para ello se utiliza el mismo

interfaz que ofrece el Sistema para monitorizar la información recopilada por los

sensores.

Cuando un usuario desea controlar el comportamiento de uno o varios

actuadores de forma remota, esté selecciona en la jerarquía de disposición el módulo en

que están integrados dichos actuadores. Después, en el panel derecho de la aplicación

cliente se cargarán los interfaces de los sensores y actuadores integrados en el módulo

seleccionado. Así, una vez localizado el/los interfaz/interfaces asociados al/los

actuador/es en cuestión, será posible controlar el comportamiento de los mismos.

Finalmente, se pulsa el botón ‘Aceptar’ para enviar los nuevos valores asignados a

el/los actuador/es al servidor. Si la actualización de los dispositivos se ha realizado de

forma correcta el usuario recibirá un mensaje como el siguiente

Nota: Cuando se actualiza el interfaz de el/los actuador/es que se quieren controlar,

dicho/s interfaz/es dejarán de ser actualizados durante un pequeño período de tiempo,

como se comento en el punto 6. Monitorización del estado de los dispositivos. La razón

por la cual esto ocurre así es porque si se refresca el interfaz/interfaces de el/los

actuador/es una vez que el usuario ha establecido los nuevos valores, difícilmente éstos

podrán ser enviar al servidor cuando ser pulse el botón ‘Aceptar’.


158

9. Finalizar la sesión en el Sistema

Cuando el usuario desea abandonar el Sistema será necesario que informe de

ello al servidor. El botón de ‘Exit’ , ubicado en la barra de herramientas, le

permitirá realizar esta acción. Una vez pulsado este botón, se mostrará la ventana de fin

de sesión. Esta ventana contiene dos cajas de texto: identificador de usuario y

contraseña. Mientras la primera de estas cajas de texto contiene el identificador de

usuario proporcionado por el mismo durante el inicio de la sesión, la segunda aparece

en blanco para que se pueda introducir la contraseña que permita verificar que el

usuario que está cerrando la sesión es el mismo que la inició, debiendo utilizar para ello

la misma contraseña.

Una vez que se ha introducido la contraseña y que se ha pulsado el botón de

‘Aceptar’ se mostrará un mensaje al usuario, que será de final de sesión correcto o

incorrecto en función de si la contraseña proporcionada por el usuario es correcta o no.

El mensaje de final de sesión correcto es similar al siguiente


159

ANEXO C


160

ESTUDIO FINANCIERO

Para el proyecto desarrollado, si no fuese por su finalidad didáctica, se tendría

que haber presentado un presupuesto que englobase el coste que llevaría el diseño,

desarrollo y puesta en marcha del mismo. Éste debería ser valorado y estudiado por el

posible comprador para valorar si es posible o no hacer frente al proyecto.

Por el interés del proyecto y su posible puesta en marcha en el mercado, se

presenta a continuación una estimación de los costes que supondría ponerlo en

funcionamiento para poder ser valorado por cualquier empresa interesada. Los costes a

recalcar son tres, costes de desarrollo, costes de puesta en marcha y costes de

formación.

Para el desarrollo del proyecto son necesarias unas 150 horas de análisis y

diseño, para familiarizarse con las tecnologías utilizadas así como para realizar una

especificación del sistema en estudio lo mas detallada posible. La implementación de

los requisitos recogidos en la fase de análisis, es decir la programación, será larga

debido a las dimensiones del proyecto, siendo necesarias muchas líneas de código, por

lo que el tiempo total dedicado a dicha tarea asciende a unas 250 horas de trabajo. Por

último, el coste de formación destinado para aquellas personas que serán nombradas

administradoras del sistema no será demasiado elevado. Un curso de 2 días de

formación, de unas 4 horas cada día, serán suficientes para aprender a gestionar el

Sistema.

Atendiendo a los precios por horas que se manejan hoy en día en el mercado

laboral, las horas antes mencionadas traducidas a euros serán:

• Coste de implementación 150 horas x 30 euros = 4500 euros/horas

• Coste de implantación: 250 horas x 25 euros = 6250 euros/horas

• Coste de formación: 8 horas x 20 euros = 160 euros/horas


161

Por otro lado, los costes de adquisición de tecnologías es otro punto importante a

tener en cuenta. Para poder poner en funcionamiento el sistema serán necesarios

determinados equipos y determinado software con el consecuente gasto que ello

requiere.

A nivel de software en este caso no habrá gastos establecidos ya que a priori

todo el software que va a ser utilizado en su desarrollo es software libre. Sin embargo el

coste de tiempo de la instalación de todo el software ascenderá a unas 4 horas de

trabajo, que en euros asciende a 4 horas x 20 euros = 80 euros/horas.

A nivel de hardware es necesario un equipo encargado de ser el servidor de

aplicaciones web. El precio del servidor oscilará entre los 1200-1700 euros.

El total del presupuesto asciende a:

Coste de implementación: 4500 euros

Coste de implantación: 6250 euros

Coste de formación: 160 euros

Coste de instalación: 80 euros

Coste de hardware: 1700 euros

.

Coste total: 12690 euros


162

ANEXO D


163

PLANIFICACIÓN

Planificación I-Alberto Carrasco Sánchez 09-oct 16-oct 23-oct 30-oct 06-nov 13-nov 20-nov 27-nov 04-dic 11-dic 18-dic 15-ene 22-ene

Especificación y diseño del protocolo de comunicaciones del exterior con el sistema Especificación de la estructura del fichero de configuración Migración de fichero de configuración a XML Instalación del servidor para desarrollo (Apache Tomcat, J2ME, Eclipse...) Estudio del tipo de interfaz de cliente Desarrollo de un servlet mono thread básico Desarrollo de un interfaz básico de cliente con comunicación con el Servlet Implementación del protocolo DOM en el cliente Intercambio de ficheros en el servlet Integración con el sistema de control

Planificación II - Alberto Carrasco Sánchez 29-ene 05-feb 05-feb 12-feb 19-feb 26-feb 05-mar 12-mar 19-mar 26-mar 02-abr 09-abr 16-abr 30-abr 14-may 28-may 11-jun

Instalación del sistema en el IIT Desarrollo de un interfaz avanzado para PC Desarrollo del servlet multi-thread Implementación y especificación de un caso real Pruebas Documentación


164

BIBLIOGRAFÍA

[BARR01] Barranco de Areba, J. “Metodología del análisis estructurado de

sistemas”, Universidad Pontificia Comillas, 2001.

[GEOG05] George Coulouris, Jean Dollimore y Tim Kindberg “Distributed Systems.

Concepts and Design”, Addison Wesley, 2005.

[ELLI05] Elliotte Rusty Harold y W. Scott Means “XML Imprescindible”, Anaya

Multimedia & O’Reilly, 2005.

[IVOR00] Ivor Horton “Beginning Java 2 JDK 1.3 Edition” Wrox Programmer to

Programmer, 2000.

Autorizada la entrega del proyecto del alumno/a: Alberto ... · PDF file3.4.5 Archivo...

Documents

Transcript of Autorizada la entrega del proyecto del alumno/a: Alberto ... · PDF file3.4.5 Archivo...