Post on 12-Feb-2017
PROGRAMACIÓN DOMÓTICA BASADA EN SISTEMAS EXPERTOS
TRABAJO PROFESIONAL EN INGENIERÍA EN INFORMÁTICA
Laboratorio de Sistemas Inteligentes Facultad de Ingeniería
Universidad de Buenos Aires Alumno: Guillermo Luis FRÍAS Directores: Prof. Dr. Ramón GARCIA MARTINEZ Prof. M. Ing. Hernán MERLINO Prof. M. Ing. Enrique FERNANDEZ
Septiembre 2009
Programación Domótica Basada en Sistemas Expertos
i
Indice
1. RESUMEN ............................................................................................................................... 1
2. INTRODUCCIÓN ..................................................................................................................... 2
2.1. COMPONENTES DEL SISTEMA ..................................................................................................... 3 2.2. TIPOS DE ARQUITECTURA ........................................................................................................... 3
3. PRESENTACIÓN DEL PROBLEMA ...................................................................................... 4
4. OBJETIVO DEL TRABAJO PROFESIONAL ........................................................................ 4
5. ÁREA DE APLICACIÓN ......................................................................................................... 4
6. PRODUCTOS EXISTENTES EN EL MERCADO .................................................................. 5
6.1. TABLA COMPARATIVA .................................................................................................................. 7
7. REQUISITOS DEL SISTEMA ................................................................................................. 8
8. SOLUCIÓN PROPUESTA ...................................................................................................... 9
9. CASOS DE VALIDACIÓN ..................................................................................................... 13
9.1. ENCENDER LAS LUCES DEL LIVING A LAS 22:15 HORAS .......................................................... 13 9.2. ENCENDER REGADORES DEL PATIO Y ABRIR EL PORTÓN DEL GARAGE .................................. 24 9.3. REDUCIR LA TEMPERATURA DEL DORMITORIO EN 2°C SI LA MISMA SUPERA LOS 23°C ......... 30
10. CONCLUSIÓN .................................................................................................................... 40
11. REFERENCIAS .................................................................................................................. 41
A. METODOLOGÍA ..................................................................................................................... 42
A.1. DESARROLLO DE SISTEMAS DE INFORMACIÓN ........................................................................ 42 A.1.1. Estudio de Viabilidad del Sistema (EVS) ................................................................... 42
A.1.1.1. Establecimiento del alcance del sistema ............................................................................. 42 A.1.1.2. Estudio de la Situación Actual ............................................................................................... 45 A.1.1.3. Definición de los requisitos del sistema ............................................................................... 50 A.1.1.4. Estudio de Alternativas de Solución ..................................................................................... 52 A.1.1.5. Valoración de las Alternativas ............................................................................................... 58 A.1.1.6. Selección de la Solución ........................................................................................................ 61
A.1.2. Análisis del Sistema de Información ........................................................................... 63 A.1.2.1. Definición del Sistema ............................................................................................................ 63 A.1.2.2. Establecimiento de Requisitos ............................................................................................... 70 A.1.2.3. Identificación de Subsistemas de Análisis ........................................................................... 75 A.1.2.4. Análisis de los Casos de Uso ................................................................................................ 80 A.1.2.5. Análisis de las Clases ............................................................................................................. 82 A.1.2.6. Elaboración del Modelo de Datos ......................................................................................... 92 A.1.2.7. Elaboración del Modelo de Procesos ................................................................................... 92 A.1.2.8. Definición de Interfases de Usuario ...................................................................................... 92 A.1.2.9. Análisis de Consistencia y Especificación de Requisitos ................................................ 105 A.1.2.10. Especificación del Plan de Pruebas .................................................................................... 106 A.1.2.11. Aprobación del Análisis del Sistema de Información ....................................................... 110
A.1.3. Diseño del Sistema de Información .......................................................................... 111 A.1.3.1. Definición de la Arquitectura del Sistema .......................................................................... 111 A.1.3.2. Diseño de la Arquitectura de Soporte ................................................................................. 116 A.1.3.3. Diseño de los Casos de Uso Reales .................................................................................. 116 A.1.3.4. Diseño de Clases................................................................................................................... 117
Programación Domótica Basada en Sistemas Expertos
ii
A.1.3.5. Diseño de la Arquitectura de Módulos del Sistema .......................................................... 126 A.1.3.6. Diseño Físico de Datos ......................................................................................................... 126 A.1.3.7. Verificación y Aceptación de la Arquitectura del Sistema ................................................ 131 A.1.3.8. Generación de las Especificaciones de Construcción ..................................................... 132 A.1.3.9. Diseño de la Migración ......................................................................................................... 134 A.1.3.10. Especificación Técnica del Plan de Pruebas ..................................................................... 135 A.1.3.11. Establecimiento de Requisitos de Implantación ................................................................ 137 A.1.3.12. Aprobación del Diseño del Sistema de Información ......................................................... 139
A.1.4. Construcción del Sistema de Información ............................................................... 140 A.1.4.1. Preparación del Entorno de Generación y Construcción ................................................. 140 A.1.4.2. Generación del Código de los Componentes y Procedimientos .................................... 159 A.1.4.3. Ejecución de las Pruebas Unitarias .................................................................................... 159 A.1.4.4. Ejecución de las Pruebas de Integración ........................................................................... 161 A.1.4.5. Ejecución de las Pruebas de Sistema ................................................................................ 169 A.1.4.6. Elaboración de los Manuales de Usuario ........................................................................... 171 A.1.4.7. Definición de la Formación de los Usuarios Finales ......................................................... 171 A.1.4.8. Construcción de los Componentes y Procedimientos de Migración y Carga Inicial de los Datos 172 A.1.4.9. Aprobación del Sistema de Información ............................................................................. 173
Programación Domótica Basada en Sistemas Expertos
1
1. Resumen
Los actuales soluciones para la programación de los sistemas de hogar (domóticos) existentes
en el mercado tienden a mejorar la calidad de vida de los habitantes de una vivienda,
proveyendo comodidades para la activación o ajuste de dispositivos a través de controles
remotos que requieren de la acción de un individuo.
Dichas soluciones, sin embargo, se tornan demasiado complejas para el usuario promedio si se
intenta que el grado de automatización involucre a varios dispositivos, siendo necesarios
conocimientos técnicos en sistemas electrónicos y/o de información.
El proyecto en cuestión brinda una solución a la programación de los distintos dispositivos del
hogar mediante una forma gráfica e intuitiva para el usuario (convirtiendo los gráficos en
reglas ejecutables por un sistema experto) y provee al mismo tiempo una interfaz para su
control y verificación en forma remota.
Programación Domótica Basada en Sistemas Expertos
2
2. Introducción
El término domótica proviene de la unión de las palabras domus (en latín, casa) y tica (en
griego, que funciona por sí misma). Dicho término agrupa a todas aquellas soluciones
destinadas a automatizar ciertos procesos de la vida cotidiana dentro del hogar, entre los que
se destacan seguridad, confort, comunicación y ahorro de energía. Para poder llevar a cabo
estas funciones, los diversos dispositivos se encuentran interconectados por medio de redes
interiores y exteriores de comunicación, cableadas o inalámbricas, y cuyo control goza de
cierta comodidad y ubicación conveniente, dentro y fuera del hogar.
De acuerdo a [2], se denomina “Domótica” o Automatización del Hogar a la aplicación de
nuevas soluciones tecnológicas basadas en la electrónica y en las telecomunicaciones al
ambiente doméstico, con el objetivo de mejorar dispositivos existentes y proveer un mayor
número de servicios de utilidad doméstica.
La domótica surgió en los años 70, con el fin de interconectar dispositivos de iluminación y
seguridad, otorgando un nivel básico de automatización al usuario. Dicha interconexión
persigue como resultado la asistencia y la simplificación de las condiciones de confort para
todos sus usuarios.
La domótica tiene diversos usos, entre los cuales se destacan:
• Ahorro energético: puede ser alcanzado de diversas maneras, no sólo a través de la
instalación de equipos que consuman menos sino también gracias al manejo eficiente
de los mismos.
o Climatización: programación de encendido/apagado de equipos y
temperaturas de uso.
o Racionalización eléctrica: encendido/ajuste/apagado de equipos eléctricos de
iluminación y entretenimiento.
• Comfort: abarca todos los comportamientos que mejoren la comodidad de los
habitantes de la casa. Esos comportamientos pueden ser activos, pasivos o mixtos.
o Iluminación: encendido/ajuste/apagado de luces.
o Generación de macros o programas de forma sencilla para el usuario.
o Control vía internet
o Automatización de equipos
Programación Domótica Basada en Sistemas Expertos
3
• Seguridad: comprende las funciones de protección tanto de bienes personales como
de sus habitantes.
o Simulación de presencia
o Cerramiento de la propiedad
• Comunicaciones: la vivienda se comunica con el exterior tanto para regular su control
como para notificar de eventos generados.
o Control por internet vía PC, PDAs o teléfonos celulares
o Notificación de alarmas
2.1. Componentes del sistema
• Controlador: es el dispositivo informático (generalmente una PC) y el conjunto de
software que se encarga de recibir las señales provenientes del actuador, procesarlas y
generar y transmitir las órdenes apropiadas a los actuadores adecuados.
• Sensor: dispositivo que mide una cantidad física y la convierte en una señal eléctrica
que puede ser leída por el controlador.
• Actuador: componente que se encarga de transformar una señal eléctrica en una
acción, generalmente mecánica sobre otro elemento físico.
2.2. Tipos de arquitectura
Desde el punto de vista de donde reside la inteligencia del sistema domótico, existen tres
enfoques principales:
• Centralizada: un control central recibe información de los distintos sensores y, una vez
procesada, genera y transmite las órdenes adecuadas a cada actuador.
• Distribuida: la inteligencia del sistema está ubicada en los sensores y actuadores.
• Mixta: existen varios dispositivos capaces de recopilar la información de los sensores y
transmitir órdenes al resto de los dispositivos.
Programación Domótica Basada en Sistemas Expertos
4
3. Presentación del Problema
Muchas de las soluciones domóticas existentes en el mercado tienden a mejorar la calidad de
vida de los habitantes de una vivienda, proveyendo comodidades para la activación o ajuste de
dispositivos a través de controles remotos que requieren de la acción de un individuo. Los
ajustes automáticos se reducen a activaciones producto de temporizadores en dispositivos
puntuales tales como el aire acondicionado o el DVR (Digital Video Recorder, Grabador de
Video Digital). Si se intenta que el grado de automatización involucre a dos o más dispositivos,
gran parte de las opciones disponibles requieren conocimientos técnicos de programación y/o
electrónica. Además, las capacidades de visualizar el estado de la vivienda o agregar nuevos
programas estando fuera del hogar, resultan limitadas. Por ello, queda en evidencia la
necesidad de un sistema que permita automatizar (de modo sencillo para un usuario medio)
tareas que involucren a varios dispositivos y que permita decidir las condiciones de activación
de dichas tareas tales como hora, condiciones externas, etc. tanto desde el hogar como en una
ubicación remota.
4. Objetivo del Trabajo Profesional
El Objetivo del presente Trabajo Profesional es desarrollar un sistema que permita programar
la automatización de equipos de domótica vía web, representando dicha programación como
diagramas de flujo, los cuales se traducirán a código ejecutable de un sistema experto quien
será el encargado de actuar sobre los equipos según las condiciones sensadas en las variables
del ambiente. En este trabajo, no habrá una conexión real con dichos artefactos sino que los
mismos se simularán con un programa con interfaz gráfica.
5. Área de Aplicación
La aplicación está destinada a todo usuario avanzado/semi avanzado de equipos de
automatización del hogar o la oficina, que no tenga conocimientos de programación más allá
de diagramas de flujo y que desee programar sus equipos más allá del nivel básico que otorgan
las interfaces de usuario de cada uno de ellos.
Programación Domótica Basada en Sistemas Expertos
5
6. Productos existentes en el mercado
• X10: estándar internacional abierto para la comunicación entre dispositivos, utilizado
en domótica. Utiliza fundamentalmente las líneas eléctricas para señalización y
control, aunque define también un protocolo de transporte inalámbrico. Fue
desarrollado en 1975 por Pico Electronics, Escocia para permitir el control remoto de
artefactos en el hogar. Fue la primera tecnología de propósito general para redes
domóticas y aún sigue siendo la más utilizada.
Pueden conectarse hasta 256 dispositivos, aprovechando un espacio de direcciones de
8 bits. Este estándar puede considerarse un método de conexión y comunicación de
equipos, que aprovecha la red eléctrica para sus comunicaciones, por lo cual no
requiere la instalación de un cableado original, reduciendo costos pero también al
mismo tiempo podría ser considerado un método de control básico de equipos: por
ejemplo, si se pretende prender y apagar una luz en forma remota, basta con conectar
a la lámpara a un dispositivo X10 y a éste último a la red eléctrica, otorgándole un
código único dentro de la casa y del otro lado, se conecta otro artefacto compatible
con X10, el cual pueda enviar señales para el código de la lámpara. Desde este punto
de vista, puede considerarse que X10 otorga una forma de programación básica y de
fácil instalación pero al mismo tiempo, bastante limitada.
• HEYU: es un programa de consola para Linux y otras Sistemas Operativos derivados de
UNIX (Mac OS X, FreeBSD, Solaris, entre otros) para el control de luces y dispositivos
en la oficina y el hogar. El sistema es capaz de interactuar con equipos X10, temporizar
acciones y de monitorear/registrar los eventos generados.
El software permite asimismo generar scripts de acciones para su posterior ejecución.
En resumen, HEYU actúa como controlador a los sensores y actuadores basados en el
protocolo X10, brindando cierto grado de automatización pero teniendo la limitación
de ser un producto para línea de comandos con lo cual el espectro de posibles usuarios
queda restringido de gran manera. Del mismo modo, cuenta con el inconveniente que
es difícil de operar y monitorear en forma remota, cuando el usuario se encuentra
fuera de su casa.
• Home Control System (HCS) de Home Automation, Inc (HAI): este sistema propietario
puede funcionar como sistema centralizado (comprando un equipo de hardware que
Programación Domótica Basada en Sistemas Expertos
6
actúa como módulo central) o como sistema distribuido (ciertos equipos pueden
actuar de forma localizada y autónoma).
HCS permite la temporización de acciones, el envío de notificaciones y el control de
funciones de seguridad, ahorro de energía y entretenimiento. Puede ser operado
mediante una interfaz gráfica táctil (que se compra por separado) o vía telefónica. En
forma opcional puede ser controlado con control remoto a través de una PC que corra
Windows Media Center o vía internet mediante software adicional.
En pocas palabras, HCS es un sistema altamente configurable y escalable, a costa de
requerir equipo específico de hardware para poder funcionar y software adicional para
poder realizar muchas de las tareas que HEYU no permite.
• ExDomus: es un software para el Media Center de Windows XP/Vista que permite
controlar luces, cortinas, calentadores, cámaras, sistemas de seguridad, etc. usando
como protocolo de conexión X10 o KNX, según la versión. Permite la temporización de
acciones así como también la ejecución de acciones disparadas por un evento externo,
tal como la activación de la alarma.
Se trata de un software pago (aunque cuenta con una versión básica gratuita) que
permite automatizar ciertas tareas pero dentro del ámbito del hogar (no cuenta con
herramientas para la programación o visualización de eventos en forma remota).
Programación Domótica Basada en Sistemas Expertos
7
6.1. Tabla comparativa
X10 HEYU HCS ExDomus Arquitectura Distribuida
(instalación individual de equipos)
Centralizada Centralizado o Distribuido, si se dispone de pocos dispositivos a automatizar
Centralizada
Facilidad de instalación
Alta (con sólo conectar los equipos a la red eléctrica y asignarles un código único salen funcionando)
Baja. Requiere experiencia en entornos UNIX (manejo de Shell scripting y compilación a partir del código fuente)
Media Medio
Facilidad de uso
Media. A través de múltiples controles remotos
Baja. Alta Media‐Alta
Método de control
Controles remotos X10
No posee interfaz gráfica, es un programa de línea de comandos
Se utiliza un control remoto que se comunica con una PC con Windows Media Center
Se utiliza un control remoto que se comunica con una PC con Windows Media Center
Control remoto (fuera del hogar)
No disponible sin software adicional
No disponible en forma nativa
Vía telefónica, celulares o, con software adicional, vía Internet
No disponible
Facilidad de programación
Alta Media. Requiere generar scripts
Alto Media
Poder de programación
Bajo (muy básico)
Medio‐Alto Alto Media (se pueden generar secuencias de acciones desde la interfaz gráfica)
Temporización de acciones
Sólo utilizando equipos adicionales
Sí Si Si (en las versiones pagas del software)
Registro de eventos
No disponible sin software adicional
Sí Si No disponible
Programación Domótica Basada en Sistemas Expertos
8
7. Requisitos del Sistema
a. Sistema de control domótico centralizado
b. Facilidad de instalación
c. Facilidad de uso, a través de una interface gráfica sencilla pero poderosa
d. Interfaz gráfica como modo de control
e. Visualización y control tanto local como remoto (vía Internet)
f. Simplicidad de programación
g. Capacidad de temporizar acciones
h. Registro de eventos
i. Posibilidad de activar programas por la llegada de señales externas (alarma por
ejemplo)
Programación Domótica Basada en Sistemas Expertos
9
8. Solución Propuesta
La solución propuesta consta de las siguientes partes:
Programación Domótica Basada en Sistemas Expertos
10
1. Generador gráfico de programas para la automatización de la casa (editor de diagramas), que puede ser accedido vía Internet desde cualquier lugar
En el trabajo profesional, se decidió que para que este componente cumpliese con el
requisito e, la alternativa más conveniente era desarrollar un programa capaz de ser
accesible mediante un navegador web. Teniendo en cuenta los requisitos c‐d‐f, se
decidió que, para mejorar la facilidad de uso, el programa debía estar basado
fuertemente en la manipulación de elementos gráficos. Por ello, se optó por la
programación a partir de la construcción de diagramas de flujo, cuyo concepto es
similar a diagramas aprendidos durante el colegio secundario, con lo cual el grado de
instrucción para su uso inicial se ve reducido considerablemente. Cada diagrama es
almacenado en un servidor dentro de la casa para su eventual posterior edición desde
cualquier lugar. Paralelamente, se convierte el diagrama en un programa ejecutable
(ver 2).
Dentro de las posibilidades para
desarrollo web, se decidió por el
desarrollo utilizando la plataforma
web de Adobe Air/Flex, debido a su
madurez en el mercado, la
documentación disponible, la facilidad
y poder para el desarrollo y la calidad
de los productos construidos bajo la misma.
2. Traductor de los diagramas a código ejecutable
Este componente del trabajo profesional, tal como fue mencionado brevemente en 1,
es el encargado de convertir los diagramas de flujo en código ejecutable. Las opciones
disponibles en el mercado para generación de código van desde la generación de un
programa a partir de un lenguaje estructurado tal como C, pasando por lenguajes
orientados a objetos como Java o C++ y lenguajes de sistemas expertos.
Los lenguajes orientados a objetos fueron rápidamente descartados, debido a que los
diagramas de flujo modelan algoritmos que son rápidamente encapsulados dentro de
una única clase (con lo cual las ventajas de abstracción/encapsulamiento al utilizar
múltiples clases queda perdida).
Programación Domótica Basada en Sistemas Expertos
11
Los lenguajes de sistemas expertos tienen la ventaja de que pueden generar reglas del
estilo SI PRECONDICION ENTONCES POSTCONDICION, que son justamente el tipo de
estructuras que aparecen en forma predominante en los diagramas que se generarán.
Si bien esto también puede hacerse con un lenguaje estructurado, la generación de
reglas SI ENTONCES es una representación más natural. Los lenguajes de sistemas
expertos tienen, respecto a los estructurados, una ventaja adicional: al generar un
programa, el motor del sistema experto tiene herramientas para realizar una ejecución
regla por regla lo cual no sólo facilita la depuración al momento del desarrollo sino que
también provee facilidades para detectar cuando un programa entra en un bucle
infinito (las condiciones de corte no ocurren nunca), esto último es un requisito
fundamental para que la unidad descrita en 3 cumpla eficientemente con su función.
Dentro de los lenguajes de sistema experto, existen distintas opciones, pero se decidió
finalmente por CLIPS por su extensa documentación online, robustez y madurez de la
plataforma, facilidad de integración en múltiples lenguajes, además de la existencia de
múltiples ejemplos de aplicación.
3. Ejecutor de los programas, activados cuando se cumplan las condiciones de inicio definidas por el usuario De los requisitos g e i se deduce que aquella unidad encargada de ejecutar los
diagramas debe estar disponible las 24 horas del día los 7 días de la semana, con lo
cual dicha unidad deberá estar activa todo el tiempo en un servidor en el hogar. A
medida que se vayan cumpliendo las condiciones de cada programa (hora o día de la
semana, llegada de un evento externo como la activación de la alarma), se encargará
de ejecutar cada programa generado por 2. Es por ello que contará con una instancia
del motor del sistema experto. Esta unidad, se encargará además, de recibir las
notificaciones de eventos provenientes de 5 y de indicarle a éste mismo que acciones
tomar (cambiar temperatura en living, abrir portón, etc.).
4. Simulador que actúe como sustituto de los equipos que se pretenden controlar
(actuadores) Este simulador consiste en una pantalla en donde el usuario puede ver que artefactos
se han ido activando en el hogar así como también ver el registro de los eventos
Programación Domótica Basada en Sistemas Expertos
12
generados (Requisito h). Si bien este simulador, tal como se dijo en la propuesta del
presente trabajo profesional, se desarrolló con el fin de mostrar el resultado de la
ejecución de los programas (porque no hay una implementación en dispositivos físicos
en la casa) también tiene como finalidad mostrar en una pantalla al usuario el estado
actual de la casa. Según los
requisitos d y e, este simulador
también es una herramienta
web, que puede utilizarse
desde cualquier navegador,
dentro o fuera de la vivienda en
cuestión. Por idénticas razones
a 1, se desarrolló en Adobe
Flex.
5. Emulador de las variables del hogar Esta unidad se encargará de generar los eventos y valores de variables que en el
mundo real provendrían de los sensores. Además, en el mundo real, sería la encargada
de comunicarse con los dispositivos reales (termostatos, luces, puertas, etc.) para que
realicen las tareas solicitadas por los programas gobernados por 3.
Programación Domótica Basada en Sistemas Expertos
13
9. Casos de Validación
A continuación, se detallará la construcción de algunos casos de validación (ejemplos de uso) desde la perspectiva del usuario, es decir, la formulación y construcción de los diagramas, la etapa de prueba de los mismos y la verificación de los resultados en el simulador. Hay que destacar que en el servidor debe estar ejecutando los programas correspondientes al inciso 3 y 5 del punto anterior.
9.1. Encender las luces del living a las 22:15 horas Para poder realizar este programa, es necesario construir un sencillo diagrama, consistente en una figura Comienzo unida a una figura Asignación, unida a una figura Fin. La figura Asignación tiene una llamada a una función que enciende las luces del living a la intensidad deseada.
1. Iniciar el Editor de Diagramas
2. Insertar una figura comienzo
Programación Domótica Basada en Sistemas Expertos
14
3. Mover la figura hasta la ubicación deseada (Mantener botón izquierdo apretado sobre la figura, mover y luego soltar el botón)
Programación Domótica Basada en Sistemas Expertos
15
4. Configurar las condiciones de inicio del diagrama. Botón derecho sobre la figura Comienzo y seleccionar “Propiedades”
5. Tildar la opción “A las” para que el diagrama se ejecute a la hora especificada. Seleccionar “22” en el cuadro de horas y “15” en el cuadro de minutos. Aceptar para salir del diálogo
Programación Domótica Basada en Sistemas Expertos
16
6. Insertar una figura Asignación
7. Mover la figura Asignación
8. Configurar la figura Asignación. Botón derecho sobre la figura y seleccionar “Propiedades”
Programación Domótica Basada en Sistemas Expertos
17
9. Elegir la función que se pretender ejecutar. Seleccionar “función” en el desplegable.
10. Seleccionar “Living” en el desplegable “Habitación” y “luz” en el desplegable “Función”
Programación Domótica Basada en Sistemas Expertos
18
11. Seleccionar “intensidad” en el desplegable “Parámetro” y “constante” en el desplegable “Tipo de valor”. Por último ingresar “1” en el cuadro “Valor” y Aceptar dos veces.
12. Dibujar una flecha desde Comienzo a Asignación. Botón derecho sobre la figura Comienzo y seleccionar “Siguiente”
Programación Domótica Basada en Sistemas Expertos
19
13. Elegir como destino de la flecha a la figura Asignación haciendo Click con el botón izquierdo sobre la misma.
14. Insertar una figura Fin
Programación Domótica Basada en Sistemas Expertos
20
15. Mover la figura Fin. Dibujar flecha desde Asignación a Comienzo por similar procedimiento al punto 12.
16. Guardar el diagrama.
17. Elegir un nombre para el diagrama creado, por ejemplo “living” y Aceptar.
Programación Domótica Basada en Sistemas Expertos
21
18. Probar la ejecución del diagrama actual en el simulador. Abrir el simulador.
19. En el editor de diagramas, probar el diagrama actual. (En este modo, se forzará la ejecución sin importar las condiciones de inicio seleccionadas).
20. Verificar el resultado de la ejecución en el simulador.
Programación Domótica Basada en Sistemas Expertos
22
21. Activar el diagrama (esto hará que el diagrama se ejecute cuando se cumplan las condiciones especificadas en la figura comienzo).
22. Seleccionar al diagrama “living” y tildar la casilla “activado”. Aceptar para finalizar.
Programación Domótica Basada en Sistemas Expertos
23
23. A la hora indicada, se verifica que la ejecución del programa fue exitosa.
Programación Domótica Basada en Sistemas Expertos
24
9.2. Encender regadores del patio y abrir el portón del Garage
Este programa es similar al anterior aunque muestra la capacidad de establecer secuencias de acciones y cómo se respeta ese orden al momento de la ejecución.
1. Insertar una figura Comienzo.
2. Insertar dos figuras Asignación.
Programación Domótica Basada en Sistemas Expertos
25
3. Insertar una figura Fin.
4. Unir la figura Comienzo con una figura Asignación.
5. Unir a la primera con la segunda Asignación.
Programación Domótica Basada en Sistemas Expertos
26
6. Unir a la segunda Asignación con la figura Fin.
Programación Domótica Basada en Sistemas Expertos
27
7. Configurar a la primera Asignación.
8. Seleccionar “función”.
9. Fijar los regadores del patio a intensidad 4, Aceptar y Aceptar nuevamente.
Programación Domótica Basada en Sistemas Expertos
28
10. Configurar a la primera Asignación y elegir “función”.
11. Seleccionar “Garage” y “abrirPorton” y luego Aceptar dos veces.
Programación Domótica Basada en Sistemas Expertos
29
12. Guardar diagrama con el nombre “abre porton”, por ejemplo.
13. Probar la ejecución del programa
14. Se verifica la ejecución del programa, con las acciones especificadas
Programación Domótica Basada en Sistemas Expertos
30
9.3. Reducir la temperatura del dormitorio en 2°C si la misma supera los 23°C
Este programa muestra el funcionamiento de una condición lógica y el uso de variables como parámetros de las funciones del sistema.
Para ello,
• Comenzar
• Asignar el valor de la temperatura del dormitorio a la variable temp.
• Comparar si ese valor es mayor a 23
• Si es así: o Decrementar en 2 el valor de temp o Ajustar la temperatura del dormitorio en temp grados.
• Fin
(En negrita aparecen las palabras que corresponden a cada figura)
1. Insertar una figura Comienzo.
2. Insertar tres figuras Asignación
Programación Domótica Basada en Sistemas Expertos
31
3. Insertar una figura Fin
Programación Domótica Basada en Sistemas Expertos
32
4. Insertar una figura Condición
5. Unir las figuras como se muestra en la siguiente imagen
Programación Domótica Basada en Sistemas Expertos
33
6. Dibujar la flecha Verdadera desde Condición a la Asignación. Botón derecho sobre la figura Condición y seleccionar “Verdadera”
7. Elegir como destino de la flecha a la figura Asignación haciendo Click con el botón izquierdo sobre la misma.
8. Dibujar la flecha Falsa desde Condición al Fin. Botón derecho sobre la figura
Condición y seleccionar “Falsa”
Programación Domótica Basada en Sistemas Expertos
34
9. Elegir como destino de la flecha a la figura Fin haciendo Click con el botón izquierdo sobre la misma.
10. El diagrama deberá quedar de la siguiente manera:
Programación Domótica Basada en Sistemas Expertos
35
11. Configurar a la Asignación “A” Escriba en el cuadro de texto el nombre de la variable: “temp” y seleccione en el desplegable “función”
Seleccionar la función “obtTemperatura” (obtener temperatura) de “Dormitorio” y Aceptar dos veces.
Programación Domótica Basada en Sistemas Expertos
36
12. Configurar la Condición. Botón derecho sobre la figura Condición y seleccionar “Propiedades”
En el desplegable superior, elegir “variable”, seleccionar “temp” y Aceptar En el desplegable del medio, seleccionar al operador mayor “>”
En el desplegable inferior, seleccionar “constante”, escribir “23” y dar “Aceptar”
Aceptar nuevamente para establecer las propiedades de la Condición
13. Configurar a la Asignación “B”. Click derecho sobre la figura y elegir “Propiedades”
Programación Domótica Basada en Sistemas Expertos
37
En el cuadro de texto escribir “temp” y en el desplegable seleccionar “función”
Seleccionar como Habitación a “(General)” y como función “resta” Seleccionar como parámetro “minuendo” como tipo de valor “variable” y como nombre “temp”
Seleccionar como parámetro “sustraendo”, como tipo de valor “constante” y como nombre “2” y Aceptar dos veces.
Programación Domótica Basada en Sistemas Expertos
38
14. Configurar a la Asignación “C”. Click derecho sobre la figura y elegir “Propiedades” Seleccionar “función” en el desplegable. Elegir “Dormitorio” como habitación, “fijarTemperatura” como función, “valor” como parámetro, “variable” como tipo de valor y “temp” como nombre.
Aceptar dos veces.
Programación Domótica Basada en Sistemas Expertos
39
15. Guardar el diagrama, por ejemplo con el nombre “condición”
16. Probar el programa
17. Verificar en el Simulador que el programa se ejecutó correctamente
(Se ejecutó la rama verdadera de la condición pues en la simulación, el dormitorio inicialmente tiene una temperatura de 24°C)
Programación Domótica Basada en Sistemas Expertos
40
10. Conclusión
En la presente memoria, se ha hecho una breve introducción a la domótica, los conceptos
asociados a la misma, los problemas que ella resuelve, la arquitectura de las posibles
soluciones. Se describió la situación que el presente Trabajo Profesional resuelve, cuáles son
sus objetivos y la arquitectura de la solución propuesta junto con las justificaciones de las
tecnologías adoptadas.
Finalmente, se incluyeron Casos de Validación, que corresponden a ejemplos típicos de uso del
sistema, pudiéndose notar que la elaboración de los mismos es sencilla y altamente gráfica,
incluso para usuarios poco experimentados.
Como última observación, puede concluirse que el sistema permite una programación flexible
y escalable de distintas tareas quedando como línea de expansión para futuros trabajos la
implementación de la conexión entre el servidor y los sensores físicos.
Programación Domótica Basada en Sistemas Expertos
41
11. Referencias
[1] García Martínez, R. y Britos, P. 2004. Ingeniería de Sistemas Expertos. Editorial Nueva
Librería. ISBN 987‐1104‐15‐4.
[2] Gerhart, J. 1999. Home Automation and wiring. Mc Graw‐Hill Professional.
[3] Karwowski, W. 2006. International Encyclopedia of Ergonomics and Human Factors.
CRC Press.
[4] Sierra, E., García‐Martínez, R., Hossian, A., Britos, P. y Balbuena, E. (2006). Providing
Intelligent User‐Adapted Control Strategies in Building Environments. Research in
Computing Science Journal, 19: 235‐241.
[5] Sierra, E., Hossian, A., Britos, P., Rodríguez , D. & García‐Martínez, R. (2007). Fuzzy
Control for Improving Energy Management Within Iindoor Building Environments.
Proceedings CERMA 2007 Electronics, Robotics & Automative Mechanics
Conference.Pag. 412‐ 416. IEEE Computer Society Press. ISBN 978‐0‐7695‐2974‐5.
[6] Sierra, E., Hossian, A., García‐Martínez, R. y Marino, P. (2005). Sistema Experto para
Control Inteligente de las Variables Ambientales de un Edificio Energéticamente
Eficiente. Proceedings de la XI Reunión de Trabajo en Procesamiento de la
Información y Control. Universidad Nacional de Río Cuarto.Pág. 446‐452.
[7] Sierra, E., Hossian, A., Rodríguez, D., García‐Martínez, M., Britos, P., García‐Martínez,
R. (2008). Optimizing Building’s Environments Performance Using Intelligent Systems.
Lecture Notes on Artificial Intelligence, 5027: 486‐491.
[8] Velastin, S y otros. 2006. Intelligent distributed video surveillance systems. IET.
[9] http://es.wikipedia.org/wiki/Domótica (07/05/09)
[10] http://en.wikipedia.org/wiki/X10_(industry_standard) (07/05/09)
[11] http://www.exdomus.com (07/05/09)
[12] http://www.homeauto.com/Products/Products_main.asp (07/05/09)
[13] http://www.heyu.org (07/05/09)
[14] http://www.smarthome.com/about_x10.html (07/05/09)
[15] http://www.xmlme.com/Validator.aspx (validador de XSD al 11/8/09)
[16] http://www.csae.map.es/csi/metrica3/index.html (Referencia de Métrica Versión 3
al 11/8/09)
Programación Domótica Basada en Sistemas Expertos
42
A. Metodología
En el presente apéndice, se describirá el desarrollo del sistema, siguiendo los lineamientos de la metodología de desarrollo de software Métrica Versión 3.
A.1. Desarrollo de Sistemas de Información
Este proceso de MÉTRICA Versión 3 contiene todas las actividades y tareas que se deben llevar
a cabo para desarrollar un sistema, cubriendo desde el análisis de requisitos hasta la
instalación del software.
A.1.1. Estudio de Viabilidad del Sistema (EVS)
En este proceso, se analizarán el conjunto concreto de necesidades, con la idea de
proponer una solución a corto plazo. Los criterios con los que se hará esta propuesta no
serán estratégicos sino tácticos y relacionados con aspectos económicos, técnicos, legales
y operativos.
A.1.1.1. Establecimiento del alcance del sistema
En esta actividad, se estudiará el alcance de la necesidad planteada, realizando una
descripción general de la misma. Se determinarán los objetivos y requisitos. Se
analizarán también posibles restricciones, tanto generales como específicas, que
podrían condicionar el estudio y la planificación de las alternativas de solución que se
propongan.
Se detallará la composición del equipo de trabajo necesario para este proceso y su
planificación. Se identificarán los perfiles, dejando en claro tareas y responsabilidades.
A.1.1.1.1. Estudio de la solicitud
• Descripción general del sistema
El Sistema a permitirá programar la automatización de equipos de domótica
vía web, representando dicha programación como diagramas de flujo, los
cuales se traducirán a código ejecutable de un sistema experto quien será el
Programación Domótica Basada en Sistemas Expertos
43
encargado de actuar sobre los equipos según las condiciones sensadas en las
variables del ambiente.
• Catálogo de Objetivos EVS
ID Autor Tipo Descripción Estado Prioridad Fecha de
creación OBJ1 FRIAS,
G. ESTRATÉGICO Presentar
un Trabajo Profesional de Calidad en Tiempo y Forma
APROB. ALTA 1/8/08
OBJ2 FRIAS, G.
ESTRATEGICO Desarrollar un Sistema de Control Domótico
APROB. ALTA 1/8/08
OBJ3 Merlino, H.
ESTRATEGICO Seguir una Metodología Conocida y Eficaz
APROB. ALTA 1/8/08
• Catálogo de Requisitos
ID Autor Tipo Descripción Estado Prioridad Fechade
creación REQ1 Merlino,
H. DOCUMENTAC
Usar Métrica 3 como Metodología de Desarrollo
INCORP. ALTA 1/8/08
REQ2 FRIAS, G.
NO FUNCIONAL
Capacidad de programar el Sistema desde una ubicación remota
APROB. ALTA 1/8/08
REQ3 FRIAS, G.
NO FUNCIONAL
Facilidad de uso, programación de modo gráfico
APROB. ALTA 1/8/08
REQ4 FRIAS, G.
FUNCIONAL Generar un registro de eventos
APROB. BAJA 20/8/08
REQ5 FRIAS, G.
FUNCIONAL Temporización de Acciones
APROB. MEDIA 17/8/08
REQ6 FRIAS, G.
FUNCIONAL Activación de programas
APROB. MEDIA 20/8/08
Programación Domótica Basada en Sistemas Expertos
44
por llegada de señales externas
A.1.1.1.2. Identificación del alcance del sistema
Se analizará el alcance de la necesidad planteada y se identificarán las restricciones
relativas a la sincronización con otros proyectos, que puedan interferir en la
planificación y futura puesta a punto del sistema objeto del estudio. Una vez
establecido el alcance, se identifican las unidades organizativas afectadas por el
sistema, así como su estructura y responsables de las mismas.
• Catálogo de Requisitos (Relativos a Restricciones o Dependencias con
Otros Proyectos)
En el caso del Trabajo Profesional a desarrollar, como no existen dependencias
con otros proyectos, los requisitos relacionados a restricciones o dependencias
con los mismos no se aplican a este contexto.
• Catálogo de Usuarios
ID Apellido y Nombre
U1 Merlino, Hernán
U2 García‐Martínez, Ramón
U3 Fernández, Enrique
U4 Frías, Guillermo
• Descripción general del sistema
o Contexto del sistema
Dentro del contexto del sistema, y teniendo en cuenta su naturaleza de
trabajo profesional y extensión, no habrá una conexión real los
sensores y actuadores sino que los mismos se simularán con un
programa con interfaz gráfica.
Programación Domótica Basada en Sistemas Expertos
45
o Estructura Organizativa
ID Apellido y Nombre Rol EO1 Merlino, Hernán Director del Trabajo Profesional EO2 García‐Martínez, Ramón Director del Trabajo Profesional EO3 Fernández, Enrique Consultor en Métrica 3 EO4 Frías, Guillermo Analista / Programador / Tester
A.1.1.2. Estudio de la Situación Actual
La situación actual es el estado en el que se encuentran los sistemas de información
existentes en el momento en el que se inicia su estudio. Teniendo en cuenta el
objetivo del estudio de la situación actual, se realizará una valoración de la
información existente acerca de los sistemas de información afectados. En función de
dicha valoración, se especificará el nivel de detalle con que se debe llevar a cabo el
estudio. Se constituirá un equipo de trabajo específico para su realización y se
identificarán los usuarios participantes en el mismo.
A.1.1.2.1. Valoración del estudio de la situación actual
En función de los objetivos establecidos para el estudio de la situación actual, y
considerando el contexto del sistema especificado en la descripción general del
mismo, se identificarán los sistemas de información existentes que es necesario
analizar con el fin de determinar el alcance del sistema actual. Se determinará el
nivel de detalle con el que se va a llevar a cabo el estudio de cada uno de los
sistemas de información implicados.
• Descripción de la Situación Actual
o Descripción de los Sistemas de Información Actuales
A través de las sesiones de trabajo y a la investigación de las
soluciones existentes en el mercado, se recopiló información de los
productos disponibles en el mismo.
X10: estándar internacional abierto para la comunicación entre
dispositivos, utilizado en domótica. Utiliza fundamentalmente las
líneas eléctricas para señalización y control, aunque define también un
Programación Domótica Basada en Sistemas Expertos
46
protocolo de transporte inalámbrico. Fue desarrollado en 1975 por
Pico Electronics, Escocia para permitir el control remoto de artefactos
en el hogar. Fue la primera tecnología de propósito general para redes
domóticas y aún sigue siendo la más utilizada.
Pueden conectarse hasta 256 dispositivos, aprovechando un espacio
de direcciones de 8 bits. Este estándar puede considerarse un método
de conexión y comunicación de equipos, que aprovecha la red eléctrica
para sus comunicaciones, por lo cual no requiere la instalación de un
cableado original, reduciendo costos pero también al mismo tiempo
podría ser considerado un método de control básico de equipos: por
ejemplo, si se pretende prender y apagar una luz en forma remota,
basta con conectar a la lámpara a un dispositivo X10 y a éste último a
la red eléctrica, otorgándole un código único dentro de la casa y del
otro lado, se conecta otro artefacto compatible con X10, el cual pueda
enviar señales para el código de la lámpara. Desde este punto de vista,
puede considerarse que X10 otorga una forma de programación básica
y de fácil instalación pero al mismo tiempo, bastante limitada.
HEYU: es un programa de consola para Linux y otras Sistemas
Operativos derivados de UNIX (Mac OS X, FreeBSD, Solaris, entre otros)
para el control de luces y dispositivos en la oficina y el hogar. El
sistema es capaz de interactuar con equipos X10, temporizar acciones
y de monitorear/registrar los eventos generados.
El software permite asimismo generar scripts de acciones para su
posterior ejecución.
En resumen, HEYU actúa como controlador a los sensores y actuadores
basados en el protocolo X10, brindando cierto grado de
automatización pero teniendo la limitación de ser un producto para
línea de comandos con lo cual el espectro de posibles usuarios queda
restringido de gran manera. Del mismo modo, cuenta con el
inconveniente que es difícil de operar y monitorear en forma remota,
cuando el usuario se encuentra fuera de su casa.
Home Control System (HCS) de Home Automation, Inc (HAI): este
sistema propietario puede funcionar como sistema centralizado
Programación Domótica Basada en Sistemas Expertos
47
(comprando un equipo de hardware que actúa como módulo central) o
como sistema distribuido (ciertos equipos pueden actuar de forma
localizada y autónoma). HCS permite la temporización de acciones, el
envío de notificaciones y el control de funciones de seguridad, ahorro
de energía y entretenimiento. Puede ser operado mediante una
interfaz gráfica táctil (que se compra por separado) o vía telefónica. En
forma opcional puede ser controlado con control remoto a través de
una PC que corra Windows Media Center o vía internet mediante
software adicional.
En pocas palabras, HCS es un sistema altamente configurable y
escalable, a costa de requerir equipo específico de hardware para
poder funcionar y software adicional para poder realizar muchas de las
tareas que HEYU no permite.
ExDomus: es un software para el Media Center de Windows XP/Vista
que permite controlar luces, cortinas, calentadores, cámaras, sistemas
de seguridad, etc. usando como protocolo de conexión X10 o KNX,
según la versión. Permite la temporización de acciones así como
también la ejecución de acciones disparadas por un evento externo, tal
como la activación de la alarma.
Se trata de un software pago (aunque cuenta con una versión básica
gratuita) que permite automatizar ciertas tareas pero dentro del
ámbito del hogar (no cuenta con herramientas para la programación o
visualización de eventos en forma remota).
Programación Domótica Basada en Sistemas Expertos
48
A.1.1.2.2. Identificación de los Usuarios Participantes en el
Estudio de la Situación Actual
En función del nivel de detalle establecido para el estudio de la situación actual, se
identificarán los usuarios participantes de cada una de las unidades organizativas
afectadas por dicho estudio.
ID Apellido y Nombre
U1 Merlino, Hernán
U2 García‐Martínez, Ramón
U3 Fernández, Enrique
U4 Frías, Guillermo
A.1.1.2.3. Descripción de los Sistemas de Información
Existentes
En esta tarea se describirán los sistemas de información existentes afectados,
según el alcance y nivel de detalle establecido en la tarea Valoración del Estudio de
la Situación Actual. Se describirán los sistemas a nivel lógico, aplicando las técnicas
de modelización y siguiendo un método descendente.
(Realizado en conjunto con 2.1.2.1 Valoración del estudio de la situación actual)
A.1.1.2.4. Realización del Diagnóstico de la Situación Actual
Se analizará la información de los Sistemas de Información existentes, obtenida en
la tarea anterior y se identifican problemas, deficiencias y mejoras.
Teniendo en cuenta las alternativas estudiadas en 2.1.2.1, podemos establecer el
siguiente tabla comparativa:
Programación Domótica Basada en Sistemas Expertos
49
X10 HEYU HCS ExDomus Arquitectura Distribuida
(instalación individual de equipos)
Centralizada Centralizado o Distribuido, si se dispone de pocos dispositivos a automatizar
Centralizada
Facilidad de instalación
Alta (con sólo conectar los equipos a la red eléctrica y asignarles un código único salen funcionando)
Baja. Requiere experiencia en entornos UNIX (manejo de Shell scripting y compilación a partir del código fuente)
Media Medio
Facilidad de uso
Media. A través de múltiples controles remotos
Baja. Alta Media‐Alta
Método de control
Controles remotos X10
No posee interfaz gráfica, es un programa de línea de comandos
Se utiliza un control remoto que se comunica con una PC con Windows Media Center
Se utiliza un control remoto que se comunica con una PC con Windows Media Center
Control remoto (fuera del hogar)
No disponible sin software adicional
No disponible en forma nativa
Vía telefónica, celulares o, con software adicional, vía Internet
No disponible
Facilidad de programación
Alta Media. Requiere generar scripts
Alto Media
Poder de programación
Bajo (muy básico)
Medio‐Alto Alto Media (se pueden generar secuencias de acciones desde la interfaz gráfica)
Temporización de acciones
Sólo utilizando equipos adicionales
Sí Si Si (en las versiones pagas del software)
Registro de eventos
No disponible sin software adicional
Sí Si No disponible
Programación Domótica Basada en Sistemas Expertos
50
Dentro de los problemas y deficiencias, podemos ver que X10 por sí solo no es
demasiado poderoso en términos de programación de equipos y que HEYU es
difícil de usar pues no posee de una interfaz gráfica. Para las cuatro alternativas, el
control fuera del hogar es dificultoso porque no poseen de una forma de acceso
adecuada como en el caso de HCS que es vía telefónica o directamente no
disponen de un método de acceso remoto. Como mejora, se propone poder
acceder vía internet, a una herramienta para la programación de los equipos. Otra
posible mejora, es la generación de un instalador que simplifique en gran medida
la instalación del sistema. La temporización de acciones y el registro de eventos
son características deseables debido a que pocas alternativas las poseen.
A.1.1.3. Definición de los requisitos del sistema
En esta actividad, se determinarán los requisitos generales, mediante una serie de
sesiones de trabajo planificadas y realizadas con los usuarios participantes. Se analizará
la información obtenida definiendo los requisitos y sus prioridades, que se añadirán al
catálogo de requisitos que servirá para el estudio y valoración de las distintas
alternativas de solución que se propongan.
A.1.1.3.1. Identificación de las Directrices Técnicas y de
Gestión
La realización de esta tarea permitirá considerar los términos de referencia para el
sistema en estudio desde el punto de vista de directrices tanto técnicas como de
gestión.
ID Autor Tipo Descripción Prioridad Estado Fecha de creación
DTG1 Merlino, H.
Gestión Uso de Métrica 3 como Metodología a seguir
ALTA APROBADA 1/8/08
DTG2 García‐Martínez, R.
Gestión Desarrollo de una Memoria del Trabajo
ALTA APROBADA 1/8/08
DTG3 Frías, G. Técnica Utilización ALTA APROBADA 1/8/08
Programación Domótica Basada en Sistemas Expertos
51
de herramientas de desarrollo reconocidas y probadas
A.1.1.3.2. Identificación de los Requisitos
Teniendo en cuenta la información recopilada en 2.1.2 (Estudio de la Situación
Actual) sobre las soluciones disponibles y a partir de las Sesiones de Trabajo se
identificaron los siguientes requisitos:
a. Sistema de control domótico centralizado
b. Facilidad de instalación
c. Facilidad de uso, a través de una interfase gráfica sencilla pero poderosa
d. Interfaz gráfica como modo de control
e. Visualización y control tanto local como remoto (vía Internet)
f. Simplicidad de programación
g. Capacidad de temporizar acciones
h. Registro de eventos
i. Posibilidad de activar programas por la llegada de señales externas (alarma por
ejemplo)
A.1.1.3.3. Catalogación de los Requisitos
ID Autor Tipo Descripción Prioridad Estado Fecha de creación
REQ1 FRIAS, G.
Arquitectura Sistema de control domótico centralizado
ALTA APROBADO 1/8/08
REQ2 FRIAS, G.
No Funcional
Facilidad de instalación
MEDIA APROBADO 21/8/08
REQ3 FRIAS, G.
No Funcional
Facilidad de uso
ALTA APROBADO 10/8/08
REQ4 FRIAS, G.
Funcional Interfaz gráfica como modo de control
MEDIA APROBADO 1/8/08
REQ5 FRIAS, G.
Funcional Visualización y control tanto local como remoto
ALTA APROBADO 1/8/08
Programación Domótica Basada en Sistemas Expertos
52
(vía Internet) REQ6 FRIAS,
G. Funcional Simplicidad
de programación
ALTA APROBADO 1/8/08
REQ7 FRIAS, G.
Funcional Capacidad de temporizar acciones
MEDIA APROBADO 17/8/08
REQ8 FRIAS, G.
Funcional Registro de eventos
BAJA APROBADO 20/8/08
REQ9 FRIAS, G.
Funcional Activación de programas por la llegada de señales externas
MEDIA APROBADO 20/8/08
A.1.1.4. Estudio de Alternativas de Solución
En este estudio, se propondrán diversas alternativas que respondan satisfactoriamente
a los requisitos planteados, considerando también los resultados obtenidos en 2.1.2
(Estudio de la Situación Actual). Se realizará una descomposición del sistema en
subsistemas, teniendo en cuenta el ámbito y funcionalidad, para facilitar su estudio.
A.1.1.4.1. Preselección de Alternativas de Solución
En esta tarea, se estudiarán diferentes opciones para configurar una solución,
teniendo en cuenta los requisitos a cubrir por el sistema ya obtenidos. Las
soluciones podrán ser desarrollos a medida, o parte desarrollo y parte de
productos comerciales. Se descarta la opción de adquirir una solución
enteramente comercial pues este no es el objetivo del desarrollo de un trabajo
profesional.
Para llevar a cabo esta preselección, en primer lugar se dividirá al sistema a
desarrollar en los siguientes subsistemas:
• Herramienta de programación del hogar
• Generador de código ejecutable
• Unidad de ejecución del código
Programación Domótica Basada en Sistemas Expertos
53
• Simulador de los equipos físicos
• Emulador de las variables del hogar (sensores)
Se procederá entonces a explicar las posibles alternativas de solución.
Alternativa A (Desarrollo de un programa único o standalone,
programación mediante comandos de texto)
La alternativa de solución más sencilla es construir un único programa que
contenga los subsistemas descritos más arriba. Desde este sistema se podrán
construir los programas para automatización del hogar, se generará el código
ejecutable, se ejecutará el código resultante, se visualizarán resultados y se
simularán equipos físicos y sensores. La programación se haría desde una PC
Local en donde el usuario ingresa comandos en un editor de texto.
Diagrama de Representación
Programación Domótica Basada en Sistemas Expertos
54
Alternativa B (Desarrollo de un programa único o standalone,
programación gráfica)
Idem Alternativa A, sólo que la programación se hace mediante la unión de
elementos gráficos en lugar de ingresar comandos en un editor de texto.
Alternativa C (Separar la generación y ejecución de código de la
programación gráfica y visualización de los resultados en dos programas
separados standalone)
Según esta alternativa, se separan los subsistemas dedicados a la generación y
ejecución del código de la programación en sí y se agrega la posibilidad de
visualizar los resultados de esa programación.
Programación Domótica Basada en Sistemas Expertos
55
Alternativa D (Separar la generación y ejecución de código en un server
de la programación gráfica y visualización de resultados, accesibles
desde un navegador)
Programación Domótica Basada en Sistemas Expertos
56
A.1.1.4.2. Descripción de las Alternativas de Solución
Para cada alternativa propuesta, se identifican los subsistemas que cubre y los
requisitos a los que se da respuesta. En 2.1.4.1 se referencia a los subsistemas
involucrados, es por ello, que en este ítem se atacará los requisitos que cada
solución cubre y cuáles no.
Alternativa A (Desarrollo de un programa único o standalone,
programación mediante comandos de texto)
Según esta alternativa, los requisitos que quedan cubiertos de acuerdo a la
tabla del punto 2.1.3.3, son REQ1 (Sistema centralizado) debido a que el
programa se instala en una sola computadora y controla a los equipos del
hogar, REQ2 (Facilidad de instalación) por igual razón. REQ7 (Capacidad de
temporizar acciones), REQ8 (Registro de eventos) y REQ9 (Activación por
señales externas) son requerimientos que pueden satisfacerse por medio de
esta solución, ya que la misma no impide la implementación de estos
requerimientos. Los requerimientos REQ4 (interfaz gráfica como modo de
control) y REQ6 (Simplicidad de programación) no quedan cubiertos, pues la
programación mediante comandos de texto es demasiado compleja para el
usuario medio, al igual que REQ3 (Facilidad de uso). El requerimiento REQ5
(Visualización remota) es de difícil implementación debido a que el programa
se encuentra residente en una máquina y no es accesible por Internet.
Alternativa B (Desarrollo de un programa único o standalone,
programación gráfica)
En esta alternativa, REQ1, REQ2, REQ7, REQ8 y REQ9 quedan satisfechos por
iguales razones a las de la Alternativa A. Los requerimientos REQ4 y REQ6
quedan satisfechos a partir de la implementación de una herramienta de
programación gráfica, al igual que REQ3. El requerimiento REQ5, por su parte
sigue siendo de difícil implementación debido a que el programa se encuentra
residente en una PC y no se encuentra separada la programación de la
generación de código.
Programación Domótica Basada en Sistemas Expertos
57
Alternativa C (Separar la generación y ejecución de código de la
programación gráfica y visualización de los resultados en dos programas
separados standalone)
En ella, REQ1, REQ7, REQ8 y REQ9 pueden satisfacerse, así como también
REQ4 y REQ6 gracias a las herramientas gráficas, del mismo modo que REQ3. El
requerimiento REQ5 de la capacidad de visualización y programación remota
puede ser satisfecho de una manera más simple y eficiente que en A y B
debido a que ahora existen dos programas separados (uno de
programación/visualización y otro de generación de código/visualización). De
cualquier modo, la comunicación entre dos programas puede verse dificultada
en algunas situaciones por la existencia de firewalls o restricciones en los
puertos a usar. El requerimiento REQ2 de Facilidad de instalación se ve en
parte comprometido porque para acceder en forma remota se requiere de la
instalación de un programa específico.
Alternativa D (Separar la generación y ejecución de código en un server
de la programación gráfica y visualización de resultados, accesibles
desde un navegador)
Al igual que la Alternativa C, se satisfacen los requerimientos REQ1, REQ3,
REQ4, REQ6, REQ7, REQ8 y REQ9 por razones similares. Las diferencias radican
en que el REQ2 de Facilidad de instalación se ve mejorado ya que la
herramientas de programación y visualización son accesibles por medio de un
navegador web desde cualquier lugar con lo cual no es necesario instalar nada
en la eventual máquina que se use para acceder a las mismas. El REQ5, por su
parte, puede cumplirse de una manera más completa y eficiente pues las
herramientas, como ya se dijo, de programación y visualización son accesibles
por la web, lo cual representa una mejora respecto a la Alternativa C, que
requería de la instalación de un programa a parte en cada máquina desde
donde se pretendiese realizar el control.
Programación Domótica Basada en Sistemas Expertos
58
A.1.1.5. Valoración de las Alternativas
Ya descritas las alternativas, se valorarán las mismas, considerando el impacto en la
organización, desde el punto de vista tecnológico, operativo, organizativo, posibles
beneficios, costos y riesgos.
A.1.1.5.1. Estudio de la Inversión
En este punto, debería evaluarse, para cada alternativa de solución propuesta, la
viabilidad económica, realizando un análisis de coste/beneficio, que pondere los
beneficios tangibles e intangibles.
Debido a la naturaleza del presente proyecto, en el cual se lleva adelante un
trabajo profesional, el estudio de inversión no es aplicable pues no existen costos
o inversiones asociadas. Se pasará al estudio de la siguiente tarea.
A.1.1.5.2. Estudio de los Riesgos
Se seleccionarán factores de situación que deberán considerarse, relativos tanto a
la incertidumbre como a la complejidad del sistema.
Alternativa A (Desarrollo de un programa único o standalone,
programación mediante comandos de texto)
ID Autor Descripción Gravedad Justificación RIE.A.1 FRIAS,
G. Incertidumbre acerca de la facilidad de uso
Media Los programas de línea de comandos requieren mayor tiempo de entrenamiento
RIE.A.2 FRIAS, G.
Dificultad en la implantación de control desde ubicación remota
Alta Las comunicaciones entre el lado remoto y el hogar deben efectuarse abriendo puertos específicos o con comunicación entre procesos remotos. Los firewalls que cada lugar posee se convierten en una dificultad adicional. La
Programación Domótica Basada en Sistemas Expertos
59
existencia de un solo programa implica que este debe comunicarse con los dispositivos de la casa de forma directa, complicando el desarrollo.
RIE.A.3 FRIAS, G.
Complejidad de comunicación entre distintos subsistemas dentro de un mismo programa
Alta Los distintos subsistemas que realizan tareas muy diferentes tienen un grado de acoplamiento muy alto ya que todos forman parte de un único programa
RIE.A.4 FRIAS, G.
Complejidad de instalación remota
Media Para controlar en forma remota a la aplicación, es necesario instalar componentes específicos en la máquina desde donde se pretende acceder
Alternativa B (Desarrollo de un programa único o standalone,
programación gráfica)
ID Autor Descripción Gravedad Justificación RIE.B.1 FRIAS,
G. Dificultad en la implantación de control desde ubicación remota
Alta Las comunicaciones entre el lado remoto y el hogar deben efectuarse abriendo puertos específicos o con comunicación entre procesos remotos. Los firewalls que cada lugar posee se convierten en una dificultad adicional. La existencia de un solo programa implica que este debe comunicarse con los dispositivos de la casa de forma directa, complicando el desarrollo.
RIE.B.2 FRIAS, G.
Complejidad de comunicación entre distintos subsistemas dentro de un mismo
Alta Los distintos subsistemas que realizan tareas muy diferentes tienen un grado de acoplamiento muy alto ya que todos forman parte de un único programa
Programación Domótica Basada en Sistemas Expertos
60
programa RIE.B.3 FRIAS,
G. Complejidad de instalación remota
Media Para controlar en forma remota a la aplicación, es necesario instalar componentes específicos en la máquina desde donde se pretende acceder
Alternativa C (Separar la generación y ejecución de código de la
programación gráfica y visualización de los resultados en dos programas
separados standalone)
ID Autor Descripción Gravedad Justificación RIE.C.1 FRIAS,
G. Dificultad en la implantación de control desde ubicación remota
Media Las comunicaciones entre el lado remoto y el hogar deben efectuarse abriendo puertos específicos o con comunicación entre procesos remotos. Los firewalls que cada lugar posee se convierten en una dificultad adicional.
RIE.C.2 FRIAS, G.
Complejidad de instalación remota
Media Para controlar en forma remota a la aplicación, es necesario instalar componentes específicos en la máquina desde donde se pretende acceder
Alternativa D (Separar la generación y ejecución de código en un server de
la programación gráfica y visualización de resultados, accesibles desde un
navegador)
ID Autor Descripción Gravedad Justificación RIE.D.1 FRIAS,
G. Dificultad en la implantación de control desde ubicación remota
Baja La accesibilidad a través de un navegador web permite una comunicación simple entre el lado cliente y el servidor, no son necesarias la apertura de puertos específicos ni la configuración de firewalls que permitan acceso a la red.
Programación Domótica Basada en Sistemas Expertos
61
A.1.1.6. Selección de la Solución
Se seleccionará entre las alternativas a la solución a adoptar.
A.1.1.6.1. Convocatoria de la presentación
En esta tarea, se efectuaría la convocatoria de la presentación de las distintas
alternativas propuestas, adjuntando los productos de la actividad anterior con el
fin de que el Comité de Dirección pueda estudiar previamente su contenido. Se
esperaría confirmación por parte del Comité de Dirección de las alternativas a
presentar.
Dada la naturaleza del presente proyecto como un Trabajo Profesional, este punto
no se aplica.
A.1.1.6.2. Evaluación de las Alternativas y Selección
y
A.1.1.6.3. Aprobación de la Solución
Se evaluarán las alternativas mencionadas en 2.1.5, debatiendo ventajas en
inconvenientes de cada una de ellas y se seleccionará la más adecuada.
De las cuatro alternativas presentadas en 2.1.5 (A,B,C y D), se saca como
conclusión que las alternativas A y B parecen ser la de más simple implementación
a primera vista pero tienen como riesgos la difícil instalación y utilización en forma
remota (RIE.A.2, RIE.A.4, RIE.B.1 y RIE.B.3). Teniendo en cuenta los requerimientos
REQ5 y REQ2 de prioridad alta y media, respectivamente, podemos concluir que
estos son inconvenientes de gran peso.
Tanto las alternativas C como la D tienen una implementación que puede parecer
más compleja que la A y B pues separan la programación/visualización de la
generación de código y ejecución pero traen como ventajas la separación y
encapsulación de tareas muy diferentes, haciendo más eficiente el desarrollo y
Programación Domótica Basada en Sistemas Expertos
62
prueba. La alternativa C tiene como desventaja el hecho de que el programa para
realizar la programación y visualización debe instalarse en toda máquina de la cual
se pretenda controlar el hogar (RIE.C.2) y que la implementación de la
comunicación entre dos programas a través de la red puede verse interrumpido
por la existencia de firewalls o puertos bloqueados como en algunas empresas
(RIE.C.1). Teniendo en cuenta el peso de los requerimientos REQ5 y REQ2, alto y
medio, respectivamente, se puede concluir que la alternativa D tiene puntos
importantes a favor: no requiere instalación en las máquinas remotas (se usa a
partir del navegador web) y la comunicación entre este cliente y la máquina en el
hogar es posible en todas aquellas máquinas que tengan acceso a internet (no
requiere de puertos adicionales).
Como conclusión, la alternativa D ofrece la solución más completa a los
requerimientos analizados en 2.1.3.3. Si bien es una alternativa más compleja que
A o B, compensa esa complejidad con menores riesgos una vez finalizado el
proyecto (cuando el sistema esté en uso), según lo analizado en 2.1.5.2. Las
diferencias entre C y D son menores, pero la conveniencia de prescindir de
instalación en las máquinas remotas (presente en la alternativa D), termina por
definir como solución a adoptar a esta última.
Programación Domótica Basada en Sistemas Expertos
63
A.1.2. Análisis del Sistema de Información
En este proceso se obtendrá una especificación detallada del sistema de información que
satisfaga las necesidades de información de los usuarios y sirva de base para el posterior
diseño del sistema.
Métrica Versión 3 es una metodología que cubre diseños tanto estructurados como
orientados a objetos y las actividades de ambas actividades están integradas en una
estructura común.
A.1.2.1. Definición del Sistema
En esta actividad, se llevará a cabo la descripción inicial del sistema de información, a
partir de los productos generados en el Estudio de Viabilidad del Sistema. Se delimitará
el alcance del sistema, se generará un catálogo de requisitos generales y se describirá
el sistema mediante unos modelos iniciales de alto nivel. También se identificarán los
usuarios que participarán en el proceso de análisis, determinando sus perfiles,
responsabilidades y dedicaciones necesarias. Se elaborará, al mismo tiempo, el plan
de trabajo a seguir.
A.1.2.1.1. Determinación del Alcance del Sistema
En esta tarea se delimitará el Alcance del Sistema de Información, utilizando como
punto de partida el Estudio de Viabilidad del Sistema.
Gracias a las sesiones de trabajo con los usuarios involucrados (ver 2.1.1.2,
Catálogo de usuarios), se obtuvieron los siguientes resultados, aplicando las
técnicas descritas a continuación:
Programación Domótica Basada en Sistemas Expertos
64
• Glosario de términos
ID Término Descripción T1 Controlador Dispositivo informático (generalmente una
PC) y el conjunto de software que se encarga de recibir las señales provenientes del actuador, procesarlas y generar y transmitir las órdenes apropiadas a los actuadores adecuados
T2 Sensor Dispositivo que mide una cantidad física y la convierte en una señal eléctrica que puede ser leída por el controlador
T3 Actuador Componente que se encarga de transformar una señal eléctrica en una acción, generalmente mecánica sobre otro elemento físico
T4 Diagrama Representación mediante elementos gráficos de una tarea de programación en la cual se podrá solicitar información a uno más sensores y se podrá pedir una acción a uno o más actuadores
T5 Programa Conjunto de instrucciones listas para ser ejecutadas
T6 Traductor Convierte un diagrama en un programa T7 Simulador o Emulador de
variables del hogar Permite visualizar las acciones tomadas por actuadores que se activaron y forzar la activación de algún sensor para emular su habilitación
T8 Bloque Elemento gráfico que constituye un Diagrama y que representa una acción a tomar, un condición, etc.
Programación Domótica Basada en Sistemas Expertos
65
• Diagrama de Casos de Uso
Actores involucrados
• Usuario: es quien puede realizar altas, bajas y modificaciones de los diagramas y quien puede habilitar/deshabilitar los mismos para su ejecución.
• Tiempo: actor temporal que dispara el caso de uso “Ejecutar Programa” cuando llega cierto instante previamente definido en un diagrama.
• Cambio en Sensor Externo: actor que representa el cambio de valor en una variable global (por ej.: temperatura exterior, intrusión en la residencia, etc.) que dispara el caso de uso “Ejecutar Programa”.
• Casa: actor que modela a los dispositivos dentro de la misma que se activarán o modificarán su estado como consecuencia de que se dispare el caso de uso “Ejecutar Programa”.
Programación Domótica Basada en Sistemas Expertos
66
Descripción de los Casos de Uso
1. Crear Diagrama: creación de un nuevo diagrama de flujo.
2. Editar Diagrama: en este caso de uso se realiza la modificación de
un diagrama de flujo, tanto en su estructura (figuras involucradas y
su interconexión) como en su función.
3. Administrar Diagramas: se realizan tareas de mantenimiento al
conjunto de diagramas (eliminar, habilitar).
4. Eliminar Diagrama: elimina un diagrama de flujo de los diagramas
disponibles.
5. Habilitar Diagrama: en este caso, se indica si un diagrama debe o
no figurar como disponible para ejecución.
6. Generar Programa: en este caso de uso, se convierte un diagrama
de flujo en un programa para su posterior ejecución.
7. Guardar Diagrama: se almacena el diagrama para su posterior
modificación.
8. Probar diagrama: ejecuta inmediatamente un diagrama por única
vez.
9. Ejecutar Programa: ejecuta un programa previamente generado.
10. Administrar Programas: determina qué programas deben
ejecutarse en el instante actual.
11. Visualizar Estado: se muestra que eventos se originaron en el
hogar y que equipos se activaron.
12. Simular Cambio en Sensor: se simula la activación de un sensor
para estudiar la ejecución de los programas.
Programación Domótica Basada en Sistemas Expertos
67
• Modelo de Dominio
Programación Domótica Basada en Sistemas Expertos
68
A.1.2.1.2. Identificación del Entorno Tecnológico
En esta tarea se definirá, en alto nivel, el entorno tecnológico que se requiere para
dar respuesta a las necesidades de información, especificando sus condicionantes
y restricciones. Para ello se tendrá en cuenta el entorno tecnológico propuesto en
la descripción de la solución, que se obtuvo en el Estudio de Viabilidad del Sistema.
Dentro del Entorno Tecnológico a utilizar, y de acuerdo a las soluciones propuestas
en el Estudio de Viabilidad del Sistema, mediante sesiones de trabajo se determinó
el entorno de hardware: para el lado servidor de la aplicación deberá poder
ejecutarse en una computadora hogareña de rango medio‐bajo, con un
procesador de al menos 800 MHz, 512 MB de RAM y 80 GB de disco duro. El
sistema operativo a utilizar será Microsoft Windows XP/Vista. Del lado cliente,
deberá poder ejecutarse en un navegador moderno tal como Internet Explorer 7,
Mozilla Firefox 2.x o Google Chrome 1.x en adelante, con los requerimientos de
hardware y software que su utilización derive.
En cuanto al Entorno Tecnológico de Software, se decidió por la utilización de
herramientas probadas y de amplia utilización en el mercado: Servidor Web
Apache 1.3.x, Base de Datos MySQL 4.1.x, PHP 4.3.x para responder a las consultas
realizadas por el lado cliente. Para el resto de los componentes del servidor se
utilizará Java 1.6 como plataforma de desarrollo por su poder, flexibilidad y
soporte en el mercado.
Para construir el lado cliente, se utilizará Adobe Flex (con Adobe Flash Player
versión 9) por su amplio uso en el mercado, la flexibilidad y poder del lenguaje y la
calidad final de las interfases gráficas realizadas en el mismo.
Respecto a la generación del código ejecutable, las opciones disponibles en el
mercado van desde la generación de un programa a partir de un lenguaje
estructurado tal como C, pasando por lenguajes orientados a objetos como Java o
C++ y lenguajes de sistemas expertos. Los lenguajes orientados a objetos fueron
rápidamente descartados, debido a que los diagramas de flujo modelan algoritmos
que son rápidamente encapsulados dentro de una única clase (con lo cual las
ventajas de abstracción/encapsulamiento al utilizar múltiples clases queda
Programación Domótica Basada en Sistemas Expertos
69
perdida). Los lenguajes de sistemas expertos tienen la ventaja de que pueden
generar reglas del estilo SI PRECONDICION ENTONCES POSTCONDICION, que son
justamente el tipo de estructuras que aparecen en forma predominante en los
diagramas que se generarán. Si bien esto también puede hacerse con un lenguaje
estructurado, la generación de reglas SI ENTONCES es una representación más
natural. Los lenguajes de sistemas expertos tienen, respecto a los estructurados,
una ventaja adicional: al generar un programa, el motor del sistema experto tiene
herramientas para realizar una ejecución regla por regla lo cual no sólo facilita la
depuración al momento del desarrollo sino que también provee facilidades para
detectar cuando un programa entra en un bucle infinito (las condiciones de corte
no ocurren nunca), esto último es un requisito fundamental para que la unidad
descrita en 3 cumpla eficientemente con su función. Dentro de los lenguajes de
sistema experto, existen distintas opciones, pero se decidió finalmente por CLIPS
por su extensa documentación online, robustez y madurez de la plataforma,
facilidad de integración en múltiples lenguajes, además de la existencia de
múltiples ejemplos de aplicación.
A.1.2.1.3. Especificación de Estándares y Normas
En esta tarea se considerarían referencias de estándares, normativas, leyes o
recomendaciones, para el proceso de desarrollo del sistema de información en
estudio.
En el caso del presente proyecto, y dada la naturaleza de Trabajo Profesional del
mismo, los estándares, normativas y leyes no se aplican, salvo la directiva, antes
mencionada en este documento, que el Trabajo Profesional debe ser desarrollado
siguiendo Métrica 3.
A.1.2.1.4. Identificación de los Usuarios Participantes y
Finales
En esta tarea se identificarán usuarios participantes y finales, interlocutores tanto
en la obtención de requisitos como en la validación de los distintos productos y la
aceptación final del sistema.
Programación Domótica Basada en Sistemas Expertos
70
• Catálogo de usuarios
Se definirán las responsabilidades de los usuarios ya detectados en el EVS
ID Apellido y Nombre Rol Responsabilidades U1 Merlino, Hernán Director del Trabajo
Profesional • Dirección teórica y
práctica U2 García‐Martínez, Ramón Director del Trabajo
Profesional • Dirección teórica y
práctica U3 Fernández, Enrique Consultor en Métrica 3 • Consultoría
referente al seguimiento de la metodología de desarrollo
U4 Frías, Guillermo Analista / Programador / Tester
• Desarrollo • Documentación • Pruebas
A.1.2.2. Establecimiento de Requisitos
En esta actividad, se llevará a cabo la definición, análisis y validación de los requisitos a
partir de la información facilitada por el usuario, completándose el catálogo de
requisitos obtenido en la actividad Definición del Sistema. El objetivo de esta actividad
es obtener un catálogo detallado de requisitos, a partir del cual comprobar que los
productos generados de las actividades de modelización se ajusten a los requisitos de
usuario.
A.1.2.2.1. Obtención de Requisitos
En esta tarea, comenzará la obtención detallada de información mediante sesiones
de trabajo con los usuarios, identificados previamente en la Definición del Sistema.
Gran parte de los requisitos ya se obtuvieron en parte durante el Estudio de
Viabilidad del Sistema, se repetirán en este punto y se agregarán los nuevos
requisitos detectados durante el Análisis del Sistema de Información.
Programación Domótica Basada en Sistemas Expertos
71
ID Autor Tipo Descripción Prioridad Estado Fecha de creación
REQ1 FRIAS, G.
Arquitectura Sistema de control domótico centralizado
ALTA APROBADO 1/8/08
REQ2 FRIAS, G.
No Funcional
Facilidad de instalación
MEDIA APROBADO 21/8/08
REQ3 FRIAS, G.
Funcional Facilidad de uso
ALTA APROBADO 10/8/08
REQ4 FRIAS, G.
Funcional Interfaz gráfica como modo de control
MEDIA APROBADO 1/8/08
REQ5 FRIAS, G.
Funcional Visualización y control tanto local como remoto (vía Internet)
ALTA APROBADO 1/8/08
REQ6 FRIAS, G.
Funcional Simplicidad de programación
ALTA APROBADO 1/8/08
REQ7 FRIAS, G.
Funcional Capacidad de temporizar acciones
MEDIA APROBADO 17/8/08
REQ8 FRIAS, G.
Funcional Registro de eventos
BAJA APROBADO 20/8/08
REQ9 FRIAS, G.
Funcional Activación de programas por la llegada de señales externas
MEDIA APROBADO 20/8/08
REQ10 FRIAS, G.
Rendimiento El lado servidor debe poder ejecutarse en una PC hogareña de acuerdo a las características de ASI 1.2
ALTA APROBADO 29/8/08
REQ11 FRIAS, G
Rendimiento El lado cliente debe poder ejecutarse en un navegador web de acuerdo a las características de ASI 1.2
MEDIA APROBADO 29/8/08
Programación Domótica Basada en Sistemas Expertos
72
El Diagrama de Casos de Uso (y la breve descripción de cada caso) fue ya
presentado en 2.2.2.1
A.1.2.2.2. Especificación de Casos de Uso
En esta tarea, la cual es obligatoria para desarrollos orientados a objetos, como es
este el caso, se especificarán los casos de usos identificados, en términos de
escenario, precondiciones, poscondiciones y excepciones.
1. Crear Diagrama
Escenarios: el usuario desea iniciar la construcción de un nuevo diagrama
Precondiciones: si se estuvo modificando otro diagrama, deben
preguntarse al usuario si desea o no guardar los cambios y de ser
afirmativa la respuesta, actualizar dicho diagrama.
Poscondiciones: se creó un diagrama en blanco
Excepciones: si existía un diagrama abierto que se modificó y no se deseó
guardar esos cambios.
2. Editar Diagrama
Escenarios: el usuario agrega, elimina o mueve figuras, une o desune
figuras del diagrama, cambia las propiedades de las mismas.
Precondiciones: existe un diagrama abierto.
Poscondiciones: el diagrama abierto ha sido modificado.
Excepciones: ‐
3. Administrar Diagramas
Escenarios: el usuario elimina y habilita/deshabilita diagramas
almacenados ya existentes.
Precondiciones: existe al menos un diagrama almacenado.
Postcondiciones: los diagramas indicados por el usuario fueron
eliminados, habilitados o deshabilitados.
Excepciones: el diagrama abierto no puede ser eliminado.
Programación Domótica Basada en Sistemas Expertos
73
4. Eliminar Diagrama
Escenarios: el usuario elimina un diagrama almacenado.
Precondiciones: el diagrama a eliminar existe y no está abierto.
Poscondiciones: se eliminó el diagrama indicado.
Excepciones: ‐
5. Habilitar Diagrama
Escenarios: el usuario habilita o deshabilita un diagrama
Precondiciones: el diagrama a habilitar/deshabilitar se encuentra
almacenado.
Poscondiciones: se habilitó/deshabilitó el diagrama almacenado.
Excepciones: ‐
6. Generar Programa
Escenarios: el usuario guarda un diagrama y como consecuencia de ello se
generará el programa correspondiente.
Precondiciones: el diagrama cuyo programa se intenta generar es
guardado.
Poscondiciones: se generó el programa asociado al diagrama guardado.
Excepciones: ‐
7. Guardar Diagrama
Escenarios: el usuario intenta guardar un diagrama actual, crear uno
nuevo pero antes guardar los cambios del anterior, abrir otro diagrama
pero guardar los cambios del actual.
Precondiciones: Existe un diagrama actual.
Poscondiciones: Se guardó al diagrama actual.
Excepciones: ‐
Programación Domótica Basada en Sistemas Expertos
74
8. Probar Diagrama
Escenarios: el usuario desea forzar la ejecución del diagrama actual a
modo de prueba, sin tener que habilitarlo.
Precondiciones: el diagrama ha sido guardado y no presenta
modificaciones desde ese momento
Poscondiciones: el programa generado a partir del diagrama fue ejecutado
por única vez con éxito.
Excepciones: ‐
9. Ejecutar Programa
Escenarios: el usuario desea forzar la ejecución de un programa, se
cumplieron las condiciones de comienzo de un cierto programa.
Precondiciones: el programa a ejecutar existe y ya fue generado a partir
del diagrama correspondiente.
Poscondiciones: el programa fue ejecutado con éxito.
Excepciones: ‐
10. Administrar Programas
Escenarios: una condición externa (cambio en un sensor, paso del tiempo)
dispara la ejecución de los programas que dependen de dicha condición.
Precondiciones: existe al menos un programa almacenado que depende
de la condición que cambió.
Poscondiciones: los programas que dependen de esa condición fueron
disparados y marcados como ejecutados.
Excepciones: ‐
11. Visualizar Estado
Escenarios: el usuario intenta ver el estado de la casa, que eventos se
generaron, que equipos se activaron y cuáles programas se ejecutaron
Precondiciones: ‐
Programación Domótica Basada en Sistemas Expertos
75
Poscondiciones: se muestra en pantalla el estado de la casa y los eventos
generados.
Excepciones: ‐
12. Simular Cambio en Sensor
Escenarios: el usuario simula el cambio en el valor de un sensor para
analizar qué cambios se producen en el estado de la casa
Precondiciones: ‐
Poscondiciones: el sensor cuyo cambio se simuló cambió de valor.
Excepciones: ‐
A.1.2.2.3. Análisis de los Requisitos
En esta tarea se estudiará la información capturada previamente en esta actividad
para detectar inconsistencias, ambigüedades, duplicidad o escasez de información.
Se analizó la información de las Tareas 2.2.2.1 y 2.2.2.2 en búsqueda de
inconsistencias, ambigüedades, etc. y se determinó que este no era el caso. Se
continúa el análisis en el siguiente punto.
A.1.2.2.4. Validación de Requisitos
En esta tarea, el grupo de usuarios definido en 2.2.1.4, determinó que el catálogo
de requisitos de 2.2.2.1 así como los casos de usos especificados en 2.2.2.2 son
válidos, consistentes y completos.
A.1.2.3. Identificación de Subsistemas de Análisis
En esta actividad, se descompondrá al sistema de información en subsistemas, con el
objeto de facilitar su análisis.
Programación Domótica Basada en Sistemas Expertos
76
A.1.2.3.1. Determinación de Subsistemas de Análisis
En esta tarea, se descompondrá al sistema en subsistemas y se definirán las
dependencias entre subsistemas analizando los elementos compartidos entre ellos
y las interfases entre ellos.
Teniendo en cuenta la información vertida en el modelo de negocio, en el modelo
de dominio, los casos de uso con sus respectivas especificaciones y el catálogo de
requerimientos, se llegó a la conclusión de que debía hacerse una división en
subsistemas para mejorar la comprensión del sistema, mejorar la confiabilidad y
simplificar el desarrollo del mismo.
1. Editor de Diagramas
Descripción: Subsistema encargado de crear, modificar y eliminar
diagramas que posteriormente se convertirán en Programas por CodeGen.
Casos de Uso Asociados: Crear diagrama, Editar diagrama, Administrar
Diagramas, Eliminar Diagrama, Habilitar Diagrama, Guardar diagrama,
Probar Diagrama.
Requisitos Asociados: Facilidad de Uso, interfaz gráfica como modo de
control, visualización y control tanto local como remoto, simplicidad de
programación, lado cliente debe poder ejecutarse en un navegador web
de acuerdo a las características de ASI 1.2.
Programación Domótica Basada en Sistemas Expertos
77
2. Generador de Código
Descripción: Subsistema encargado de generar, a partir de los diagramas,
los programas correspondientes que posteriormente se ejecutarán.
Casos de Uso Asociados: Generar programa, Guardar diagrama, Probar
diagrama.
Requisitos Asociados: Sistema de control domótico centralizado, lado
servidor debe poder ejecutarse en una PC hogareña de acuerdo a las
características de ASI 1.2.
3. Simulador y visualizador de eventos
Descripción: Subsistema responsable de desplegar en pantalla los eventos
que se generaron, equipos que se activaron y de proveer una interfaz para
simular la activación de los sensores.
Casos de Uso Asociados: Ejecutar programa, Visualizar Estado, Simular
Cambio en Sensor.
Requisitos Asociados: Facilidad de uso, interfaz gráfica como modo de
control, visualización y control tanto local como remoto, registro de
eventos, activación de programas por la llegada de señales externas, lado
cliente debe poder ejecutarse en un navegador web de acuerdo a las
características de ASI 1.2.
4. Emulador de las variables del hogar, estado de la casa
Descripción: Subsistema responsable de emular la comunicación con los
dispositivos físicos que estarían conectados en la implementación real
(lámparas, termostatos, comandos para apertura de puertas, sensores por
ejemplo alarma, etc.) y de mantener el estado de la casa y sus dispositivos.
Casos de Uso Asociados: Ejecutar programa, Visualizar Estado, Simular
Cambio en Sensor.
Requisitos Asociados: Sistema de control domótico centralizado,
visualización y control tanto local como remoto, registro de eventos,
activación de programas por la llegada de señales externas, lado servidor
Programación Domótica Basada en Sistemas Expertos
78
debe poder ejecutarse en una PC hogareña de acuerdo a las características
de ASI 1.2.
5. Ejecutor de Código
Descripción: Subsistema encargado de ejecutar los programas generados
cuando se cumplan sus condiciones de inicio (tiempo y/o cambio en
sensores).
Casos de Uso Asociados: Ejecutar Programa, Administrar Programas,
Simular Cambio en sensor.
Requisitos Asociados: Sistema de control domótico centralizado,
capacidad de temporizar acciones, activación de programas por la llegada
de señales externas, lado servidor debe poder ejecutarse en una PC
hogareña de acuerdo a las características de ASI 1.2.
A.1.2.3.2. Integración de Subsistemas de Análisis
Dado que en la tarea anterior se obtuvieron las descripciones de los subsistemas
de análisis, en esta tarea se describirán las interfases entre subsistemas.
Programación Domótica Basada en Sistemas Expertos
79
Solicitar Diagramas Disponibles
Esta interfaz es la encargada de obtener la información relacionada con los
diagramas existentes, cuáles se han modificado o eliminado y cuáles están
activados o desactivados.
Solicitar Archivos de Código Disponibles
Esta interfaz obtiene la información relacionada con los archivos de código
(programas) existentes, generados a partir de los diagramas; cuáles programas se
han modificado o eliminado y cuáles están activados para su ejecución.
Actualizar Estado Dispositivos
Se ocupada de transmitir las órdenes de activación de los dispositivos del hogar,
indicados en cada programa y de mantener informado sobre el estado de los
sensores, ya que estos pueden ser condiciones de disparo de la ejecución de uno o
más programas.
Obtener Eventos y Señales Sensores
Esta interfaz es la encargada de solicitar los últimos eventos generados (activación
de dispositivos, sensores, que programas se ejecutaron, etc.) y de comunicar la
simulación de la activación de un sensor.
Programación Domótica Basada en Sistemas Expertos
80
A.1.2.4. Análisis de los Casos de Uso
Dado que en el presente Trabajo Profesional, se realiza un Análisis Orientado a
Objetos, en esta actividad se identificarán las clases cuyos objetos son necesarios para
realizar un caso de uso y se describirá sus comportamientos mediante la interacción de
dichos objetos.
Esta actividad se llevará a cabo para cada uno de los casos de uso contenidos en un
subsistema de los definidos en la actividad 2.2.3.
A.1.2.4.1. Identificación de Clases Asociadas a un Caso de Uso
En esta tarea, se comenzarán a identificarán las clases de los objetos necesarios
para realizar el caso de uso, basándose en la especificación que ya existe del
mismo.
Nombre de la Clase Caso(s) de Uso Asociado(s) Subsistema(s) asociado(s) Diagrama Crear Diagrama, Editar
Diagrama, Guardar Diagrama, Administrar Diagramas, Eliminar Diagrama, Habilitar Diagrama
Editor de Diagramas
Figura Crear Diagrama, Editar Diagrama, Guardar Diagrama, Eliminar Diagrama
Editor de Diagramas
Programa Crear Diagrama, Editar Diagrama, Guardar Diagrama, Generar Programa, Administrar Diagramas, Eliminar Diagrama, Habilitar Diagrama
Editor de Diagramas, Generador de Código
Bloque Crear Diagrama, Editar Diagrama, Guardar Diagrama, Generar Programa, Eliminar Diagrama
Editor de Diagramas, Generador de Código
HomeState Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor
Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código
Home Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor
Emulador de las variables del hogar, estado de la casa; Simulador y
Programación Domótica Basada en Sistemas Expertos
81
visualizador de eventos; Ejecutor de Código
Room Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor
Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código
Function Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor
Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código
Log Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor
Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código
LogEntry Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor
Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código
Sensor Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor
Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código
Expression Generar Programa Generador de Código Param Generar Programa Generador de Código CodeGen Generar Programa Generador de Código Executer Probar diagrama, Ejecutar
Programa, Administrar Programas, Simular Cambios en Sensor
Emulador de las variables del hogar, estado de la casa; Ejecutor de Código
Dispatcher Ejecutar Programa, Administrar Programas, Simular Cambios en Sensor
Emulador de las variables del hogar, estado de la casa; Ejecutor de Código
CodeSupervisor Probar diagrama, Ejecutar Programa
Emulador de las variables del hogar, estado de la casa; Ejecutor de Código
SensorSystem Simular Cambios en Sensor Emulador de las variables del hogar, estado de la casa; Ejecutor de Código
WatchDog Probar diagrama, Ejecutar Programa
Ejecutor de Código
RemoteFunction Probar diagrama, Ejecutar Programa
Emulador de las variables del hogar, estado de la casa; Ejecutor de Código
MotorInferencias Probar diagrama, Ejecutar Programa
Ejecutor de Código
FileConditions Probar Diagrama, Ejecutar Ejecutor de Código
Programación Domótica Basada en Sistemas Expertos
82
Programa, Administrar Programas, Simular Cambios en Sensor
A.1.2.5. Análisis de las Clases
Esta actividad, que se realiza en todo Análisis Orientado a Objetos, como en el caso del
presente Trabajo, se describirá cada una de las clases surgidas, identificando sus
responsabilidades asociadas, atributos y relaciones entre ellas.
NOTA: dado que cada una de las siguientes tres tareas (2.2.5.1, 2.2.5.2 y 2.2.5.3)
requieren un diagrama de clases para cada subsistema y con el fin de simplificar la
lectura de toda la actividad, luego de la descripción de la tarea 2.2.5.3 se colocará el
diagrama de clases final para cada subsistema.
A.1.2.5.1. Identificación de Responsabilidades y Atributos
En esta tarea, se identificarán atributos relevantes y responsabilidades de las
clases.
Las responsabilidades de una clase son las que definen su funcionalidad, y están
basadas en el papel que desempeñan sus objetos dentro de los distintos casos de
uso. A partir de las mismas, se podrán encontrar las operaciones que van a
pertenecer a esas clases.
Los atributos de una clase especifican propiedades de la clase, y se identifican por
estar implicados en sus responsabilidades.
Se identificarán responsabilidades y atributos para las clases de cada subsistema,
teniendo en cuenta requerimientos, casos de uso e interfaz de usuario (ver 2.2.8)
A.1.2.5.2. Identificación de Asociaciones y Agregaciones
En esta tarea se estudiarán los mensajes establecidos entre los objetos del
diagrama de interacción para determinar que asociaciones existen entre las clases
Programación Domótica Basada en Sistemas Expertos
83
correspondientes. Dichas asociaciones estarán caracterizadas por su papel,
direccionalidad y cardinalidad.
A.1.2.5.3. Identificación de Generalizaciones
En esta tarea se representarán las clases con una organización que permita una
implementación sencilla de la herencia y una agrupación semántica de las distintas
clases.
A continuación, se presentan los diagramas de clases resultantes para cada
subsistema:
Programación Domótica Basada en Sistemas Expertos
84
Editor de Diagramas
El editor de diagrama constituye la interfaz principal de uso del sistema. Su arquitectura es
la de un MVC. El usuario diseña diagramas, constituidos por Figuras, unidas por medio de
Flechas y ajusta la configuración (clase Config) de cada Bloque del Modelo, que es
representado de modo indirecto por una Figura de la Vista. La clase Control coordina que
los cambios en la Vista se vean reflejados en el Modelo y viceversa. La Vista desconoce la
existencia del Modelo y vicerversa, la Clase Mapper, controlada por Control es quien se
encarga de mantener y utilizar las asociaciones entre los elementos de una y la otra.
Programación Domótica Basada en Sistemas Expertos
85
Generador de Código
Programación Domótica Basada en Sistemas Expertos
86
El generador de código convierte la información almacenada por el editor de
diagramas en un programa listo para ser ejecutado. Para ello, CodeGenerator
interpreta esa información y construye un objeto compuesto de la clase Program.
Este a su vez está compuesto por una colección de objetos de la Clase Block y sus
derivadas, el método toCode() es redefinido para cada subclase y convierte a dicho
bloque en código ejecutable. Cada objeto Block puede estar o no compuesto por
una o más expresiones (Expression) y sus derivadas. Por ejemplo un BlockStart
contiene a un objeto ExpressionStart; un BlockAlloc (bloque que representa una
asignación) está conformado por un ExpressionVariable (representando el lado
izquierdo de la asignación) y un Expression (representa el lado derecho de la
asignación, puede ser constante, función, etc.). La clase Param modela a cada
parámetro de una función y puede estar formada por cualquier expresión. Una vez
construido el objeto Program, la conversión a código es trivial, invocando
sucesivamente al método toCode() de cada objeto contenido en él.
Programación Domótica Basada en Sistemas Expertos
87
Ejecutor de Código
Programación Domótica Basada en Sistemas Expertos
88
Executer es la clase responsable de esperar que se cumplan las condiciones de
ejecución de cada archivo y, una vez satisfechas, ordenar su ejecución. Dispatcher
es responsable de determinar, en cada momento, que archivos están en condición
de ser ejecutados, haciendo uso de las condiciones de inicio de cada archivo,
presentes en FileConditions. CodeSupervisor es, como su nombre lo indica,
responsable de supervisar ejecución del código, la cual está a cargo de
MotorInferencias. CodeSupervisor interviene en la ejecución al momento de
ejecutar funciones del hogar por ejemplo, abrir portón y delega la responsabilidad
de comunicarse con el subsistema Emulador de las variables del hogar, estado de
la casa a la clase RemoteFunction. La clase WatchDog es la encargada de
determinar si se cumplió el tiempo máximo estipulado para la ejecución (debido a
un programa que entra en bucle infinito por ejemplo) y notificar de esa condición
anómala. SensorSystem es la encargada de mantener el estado de los sensores.
StateHandler y UpdateHandler son responsables de recibir notificaciones
externas sobre cambios en los sensores ó adicionar de nuevos archivos y eliminar
ya existentes, respectivamente.
Programación Domótica Basada en Sistemas Expertos
89
Emulador de las variables del hogar, estado de la casa
Programación Domótica Basada en Sistemas Expertos
90
HomeState es la clase encargada de responder a los pedidos de ejecución de
funciones y de activación de sensores. Home (Hogar) es la clase ocupada de
modelar los sistemas que componen el hogar y está compuesta por habitaciones
(objetos de la clase Room y sus derivadas). Cada habitación puede ejecutar un
número de funciones (que son registradas al momento de instanciar la habitación)
representadas por objetos de la clase Function y sus subclases (se muestran sólo
un par a modo ilustrativo). Home contiene también a un conjunto de objetos de la
clase Sensor, que a su vez está especializada en la clase SensorSimulated que
modela a los sensores simulados ya que en este trabajo profesional no hay
implementación física hacia los sensores físicos.
Log es responsable del registro de eventos, cada uno de ellos, representado en la
clase LogEntry y sus clases hijas, especializadas según la función que genere dicho
evento.
StateQueryHandler y ExecuterCmdHandler se encargan de responder a los
pedidos de registro de eventos y de ejecución de funciones, respectivamente.
SensorStatusUpdater es responsable de notificar al subsistema de ejecución de
código cambios en el estado de los sensores para que éste decida que archivos
ejecutar.
Programación Domótica Basada en Sistemas Expertos
91
Simulador y visualizador de eventos
Programación Domótica Basada en Sistemas Expertos
92
El diagrama de clases de este subsistema es bastante simple y constituye
simplemente de una capa de visualización con lo cual no existen clases de
entidad. La clase Simulador controla el funcionamiento de la aplicación y se
encarga de pedir nuevos eventos para mostrar. StateResponder es responsable
de atender las respuestas remotas, fallidas o exitosas. La clase Home se ocupa de
modelar la casa y actualizar sus indicadores visuales en el simulador. La clase
Front muestra indicadores gráficos y/o acústicos de los sensores que se van
activando. Alarm modela la animación de la activación de la Alarma de la
vivienda. Home contiene una colección de habitaciones (objetos de la clase Room
y sus derivadas), cada uno de los cuales contiene un termómetro (Thermometer)
que muestra la temperatura interna gráficamente (ver 2.2.8). La clase Patio se
encarga de la representación visual de los eventos en el mismo, más
específicamente de la activación del Regador.
A.1.2.6. Elaboración del Modelo de Datos
Según Métrica versión 3, se desarrolla sólo para Análisis Estructurado, y como en el
caso del presente trabajo se está haciendo un Análisis Orientado a Objetos, se omitirá
esta actividad.
A.1.2.7. Elaboración del Modelo de Procesos
Según Métrica versión 3, se desarrolla sólo para Análisis Estructurado, y como en el
caso del presente trabajo se está haciendo un Análisis Orientado a Objetos, se omitirá
esta actividad.
A.1.2.8. Definición de Interfases de Usuario
En esta actividad, se especificarán las interfases entre el sistema y el usuario: formatos
de pantallas, diálogos. El objetivo es realizar un análisis de los procesos de los sistemas
de información en los que se requiere una interacción del usuario, con el fin de crear
una interfaz que satisfaga los requisitos establecidos.
Programación Domótica Basada en Sistemas Expertos
93
A.1.2.8.1. Especificación de los Principios Generales de la
Interfaz
El objetivo de esta tarea, es especificar los estándares, directrices y elementos
generales a tener en cuenta en la definición de interfaz de usuario.
Principios Generales de la Interfaz
1. El entorno de la interfaz interactiva con el usuario será en todos los casos que
se aplique una interfaz gráfica.
2. La interfaz gráfica de las herramientas de visualización del estado de la casa y
la de edición de diagramas deberá ser semejante a la de los programas típicos
de Windows, con barras de menúes, barras de herramientas, botones y
menúes contextuales.
3. Al necesitar una selección por parte del usuario (abrir un archivo, modificar
propiedades de una figura, etc.), se deberá abrir un diálogo el cual no
modificará nada en el Sistema hasta que el usuario pulse Aceptar en el
mismo.
4. El lado Servidor del Sistema, por ser justamente procesos que responden a
pedidos, no necesitará tener una interfaz gráfica pero es deseable que posea
uno o varios íconos distintivos en el área de notificación de la barra de tareas
de Windows y que desde los mismos puedan detenerse dichos procesos.
5. La herramienta de visualización del estado de la casa deberá tener un panel
desde donde poder observar los últimos eventos generados en la vivienda así
como también un plano de la misma en donde poder observar en forma gráfica
la activación de los dispositivos gráficos más representativos.
6. La herramienta de edición de los diagramas, debe permitir el trazado de los
mismos arrastrando y soltando figuras y dibujando de modo sencillo las
uniones entre las mismas.
Programación Domótica Basada en Sistemas Expertos
94
7. El instalador del Sistema en el lado Servidor deberá tener la interfaz de un
instalador típico de Windows, desarrollado preferentemente con alguna
herramienta específica para tal fin.
A.1.2.8.2. Identificación de Perfiles y Diálogos
El objetivo de esta tarea es identificar los perfiles de usuario, de acuerdo a su nivel
de responsabilidad y al alcance o naturaleza de las funciones que realizan, así
como analizar las características más relevantes de los usuarios que van a asumir
estos perfiles, etc. Para tal fin se genera un catálogo de perfiles de usuario.
En el caso del presente Trabajo Profesional, existe un único perfil de usuario, que
es el usuario final del sistema quien instala en su casa el software correspondiente
al lado Servidor y es a su vez quien ejecuta el sistema (edición de diagramas,
visualización del estado) desde su casa o fuera de ella.
Para ver el catálogo de usuarios, referirse a 2.2.1.4 Identificación de los Usuarios
Participantes y Finales.
A.1.2.8.3. Especificación de Formatos Individuales de la
Interfaz de Pantalla
En esta tarea se presentarán los formatos para las interfases del Sistema del
presente Trabajo Profesional más representativas. Se desarrollaron bosquejos de
la Interfaz final en Microsoft Visio.
Editor de Diagrama
De acuerdo a los Principios de Interfaz y Requisitos previamente descritos, el
editor de Diagrama deberá ser un programa web con apariencia de un programa
típico (standalone) de Windows, con menúes, barras de herramientas y un editor
con arrastrar y soltar. El objetivo es crear una aplicación accesible desde cualquier
lugar, y fácil de usar como un editor WYSIWYG (What You See Is What You Get).
Programación Domótica Basada en Sistemas Expertos
95
Visualizador de eventos y simulador de señales
Esta aplicación también es una aplicación web con apariencia de programa standalone
de Windows. Desde el recuadro Control se puede simular la llegada de nuevas señales.
Abajo del mismo, aparece el registro de los últimos eventos y a su izquierda, el mapa
de la vivienda.
Programación Domótica Basada en Sistemas Expertos
96
Lado Servidor
El lado Servidor se encarga de responder los pedidos del lado cliente por lo tanto sus
requerimientos de interfaz son mínimos. Debe existir, sin embargo, una forma sencilla
de detener los procesos del lado servidor.
A.1.2.8.4. Especificación del Comportamiento Dinámico de la
Interfaz
El objetivo de esta tarea es definir los flujos entre los distintos formatos de interfaz
de pantalla, y también dentro del propio formato. Este comportamiento se
describe mediante un modelo de navegación de pantalla.
Programación Domótica Basada en Sistemas Expertos
97
En este punto se describirá el comportamiento dinámico del subsistema más
cercano al usuario, el Editor de Diagramas, dado que el otro componente que
necesita de la interacción del usuario (Visualizador de Eventos y Simulador de
Señales) tiene una interfaz muy sencilla, la cual no requiere de la navegación por
múltiples pantallas (ver 2.2.5.3).
Editor de Diagramas
Los bloques correspondientes a Abrir Diagrama, Guardar Diagrama y Administrar
Diagrama corresponden a cuadros de diálogo desde donde abrir, guardar y activar y
eliminar diagramas, respectivamente. El bloque Nuevo Diagrama representa la
creación de una nueva instancia de diagrama para ser posteriormente editado. Editar
diagrama comprende la manipulación gráfica del mismo (mover y agregar figuras,
dibujar flechas) mientras que los bloques propiedades (que deberán invocarse a través
de un menú con botón derecho sobre la figura a modificar) corresponden a las
opciones disponibles según el tipo de Figura. Los bloques Constante, Variable y
Función corresponden a cuadros de diálogo accesorios que ayudan a construir las
propiedades de una figura Asignación o Condición.
Programación Domótica Basada en Sistemas Expertos
98
Cuadro Abrir Diagrama
Seleccionar en la lista el Diagrama a abrir y pulsar Aceptar. El botón Cancelar evita
abrir otro diagrama.
.
Cuadro Guardar Diagrama
Ingresar el nombre del nuevo archivo y pulsar Aceptar. El botón Cancelar evita guardar
el diagrama. Si el nombre está siendo usado, preguntar si se desea sobreescribir.
Cuadro Administrar Diagramas
Seleccionar en la lista el Diagrama a activar (o desactivar) y tildar (o destildar) la casilla
activado.
Programación Domótica Basada en Sistemas Expertos
99
Seleccionar en la lista el Diagrama a eliminar, pulsar eliminar y confirmar la decisión.
Pulsando Aceptar se realizan las modificaciones, Cancelar omite cada una de ellas.
Propiedades Comienzo
Presenta las opciones de configuración de una figura Comienzo en el Diagrama.
La configuración de la figura de Comienzo incluye: días de la semana en que el
diagrama se ejecutará, hora del día y que señales externas podrán activar la ejecución
de ese diagrama.
Programación Domótica Basada en Sistemas Expertos
100
Propiedades Asignación
Una asignación representa un bloque donde se puede hacer opcionalmente la
asignación a una variable del lado izquierdo de una expresión a un valor proveniente
de una constante, variable o función. En el caso de ser una función, esta previamente
es ejecutada y evaluada.
En el cuadro de texto se ingresa el nombre de la variable del lado izquierdo. La
expresión del lado derecho se completa eligiendo una opción del combo, la cual abrirá
un nuevo cuadro de selección, según sea su tipo. En Vista previa, se muestra la
expresión resultante en la asignación.
Propiedades Condición
Una condición evalúa una expresión lógica compuesta por una expresión a la izquierda
(representada por el combo superior), una expresión a la derecha y un operador de
comparación ( <, <= , =, != , >= , >, AND, OR). Tanto el combo de la expresión izquierda
como el de la derecha, abren distintos cuadros si se selecciona constante, variable o
función.
Programación Domótica Basada en Sistemas Expertos
101
El recuadro Vista previa muestra la expresión de condición resultante de las
selecciones en los combos.
Cuadro Constante
Este cuadro permite el ingreso de cualquier cadena de caracteres (A‐Z, a‐z, _, 0‐9) o
número entero mayor o igual a cero.
Cuadro Variable
Una variable es cualquier cadena de caracteres que empieza con (A‐Z, a‐z, _ ) y sigue
con cero, uno o más de los siguientes caracteres: (A‐Z, a‐z, _, 0‐9).
Programación Domótica Basada en Sistemas Expertos
102
Cada variable disponible en el desplegable fue definida previamente por el lado
izquierdo de una asignación.
Cuadro Función
Las funciones están categorizadas por la habitación en la que se ejecuta. Cada función
puede tener cero, uno o más parámetros. Cada parámetro puede recibir un valor de
una variable o una constante.
La metodología de uso del cuadro de función es ir completando los desplegables uno a
uno desde arriba hacia abajo. Hay que definir un tipo de valor y nombre para cada uno
de los parámetros que aparecen en el desplegable respectivo.
Programación Domótica Basada en Sistemas Expertos
103
Vista previa muestra cómo va quedando la expresión correspondiente a la función que
se está construyendo. Si existen ? significa que hay parámetros que aún no se
definieron. Pulsando en ? al lado del desplegable de función, se puede obtener una
ayuda rápida para la función seleccionada.
Visualizador de Eventos y Simulador de Señales
Si bien la interfaz de usuario de este subsistema es sencilla, vale la pena remarcar
ciertas transiciones dinámicas de algunos eventos.
Encender la luz de la habitación
Como el plano de la casa que lo compone será un plano de arquitectura en fondo
negro, se tomará la convención que al encender la luz, el fondo de la habitación pasará
de negro a amarillo.
Por ejemplo, en el caso del living:
Luz apagada Luz encendida
Ajustar temperatura de una habitación
El ajuste de temperatura en una habitación será representado por un círculo dentro de
la misma en parte azul y en parte rojo, el cual será tanto más rojo en cuanto se esté
más cerca de la temperatura máxima y tanto más azul en cuanto se esté más cerca de
la temperatura mínima del termostato.
Programación Domótica Basada en Sistemas Expertos
104
Temperatura máxima Temperatura media Temperatura mínima
Regadores del patio
La activación de los regadores del patio estará representada por una animación
consistente en círculos concéntricos azules que crecen de radio y alcanzan un radio
máximo proporcional a la intensidad fijada para el riego.
Apertura y cierre del portón
La apertura y cierre del portón deberá representarse con la existencia o no del portón
en el garaje y estará acompañada por una animación.
Programación Domótica Basada en Sistemas Expertos
105
A.1.2.8.5. Especificación de los formatos de Impresión
En esta tarea, se deberían especificar los formatos y características de las entradas
y salidas impresas.
En el presente Trabajo Profesional, ni las entradas ni las salidas están presentes en
formato impreso por lo tanto este punto de la metodología no es aplicable.
A.1.2.9. Análisis de Consistencia y Especificación de Requisitos
El objetivo de esta actividad es garantizar la calidad de los distintos modelos generados
en el proceso de Análisis del Sistema de Información, y asegurar que los usuarios y los
Analistas tienen el mismo concepto del sistema. Para cumplir dicho objetivo, se llevan
a cabo las siguientes acciones:
• Verificación de la calidad técnica de cada modelo.
• Aseguramiento de la coherencia entre los distintos modelos.
• Validación del cumplimiento de los requisitos.
A.1.2.9.1. Verificación de los Modelos
y
A.1.2.9.2. Análisis de Consistencia entre los Modelos
En estas tareas, se deberán asegurar la calidad de los distintos modelos. Para ello,
se analizó la consistencia entre los mismos y su completitud. Se tuvo en cuenta el
Catálogo de Requisitos, el Diagrama de Casos de Uso con sus respectivas
especificaciones, diagrama de subsistemas (y sus especificaciones), los diagramas
de clases y la especificación de la interfaz de usuario.
Cada uno de estos modelos ya incluidos cuenta con las modificaciones para
garantizar dicha consistencia.
Programación Domótica Basada en Sistemas Expertos
106
A.1.2.9.3. Validación de los Modelos
Se validaron los modelos contra el Catálogo de Requisitos así como también en
reuniones con los usuarios especificados en el Catálogo de Usuarios.
A.1.2.10. Especificación del Plan de Pruebas
En esta actividad, se iniciará la definición del Plan de Pruebas, el cual servirá como guía
para la realización de las pruebas y verificará que el sistema de información cumple
con las necesidades establecidas por el usuario, con las debidas garantías de calidad.
A.1.2.10.1. Definición del Alcance de las Pruebas
De acuerdo al sistema a desarrollar, se decidió que se utilizarán los siguientes
niveles de pruebas:
• Pruebas Unitarias de Clases: según el caso, se evaluará si se deciden
realizar pruebas automatizadas de las clases críticas (unit testing) y al resto
de las clases se les realizarán pruebas individuales en forma manual. Estas
pruebas se harán paralelamente a la codificación del sistema y sólo
cuando estas sean superadas podrá pasarse a la siguiente actividad. Estas
pruebas serán realizadas por el alumno.
• Pruebas de Integración: se ejecutarán en forma manual y tendrán como
objetivo verificar que el flujo de datos entre dos subsistemas cualesquiera
generen el producto deseado. Estas pruebas de integración se realizarán al
finalizar los subsistemas involucrados y deberán ser pasadas antes de las
pruebas de sistema. Estas pruebas serán realizadas por el alumno.
• Pruebas de Sistema: serán realizadas por el alumno y estarán orientadas
según la técnica de “caja negra”, en la cual se examinan algunos aspectos
externos del modelo del sistema sin tener en cuenta la estructura interna
del software. Una vez que la aplicación supere estas pruebas, estará lista
para las pruebas de aceptación del sistema.
Programación Domótica Basada en Sistemas Expertos
107
• Pruebas de aceptación del sistema: serán similares a las pruebas de
sistema, pero realizadas en presencia de los directores del Trabajo
Profesional, una vez concluido el desarrollo, en la que se verificará el
cumplimiento de los requisitos funcionales previamente mencionados en
este documento.
A.1.2.10.2. Definición de Requisitos del Entorno de Pruebas
En esta tarea, se definirán y recopilarán los requisitos relativos al entorno de
pruebas, completando el plan de pruebas.
Siguiendo las recomendaciones de Métrica Versión 3, de separar el entorno de
pruebas del de desarrollo y operación, se determinó que para las pruebas
unitarias, de integración y de sistema a cargo del alumno se utilizará el entorno de
desarrollo, y para las actividades de prueba que resulten convenientes (por
ejemplo, prueba del instalador) se utilizará una máquina limpia donde se instalará
el sistema paso a paso. De no contar con dicha máquina limpia, podrá utilizarse
una máquina virtual a través de Microsoft Virtual PC o similar. Para las pruebas de
aceptación, podrá, asimismo, utilizarse una máquina virtual o una PC limpia y
ejecutar el instalador provisto, siguiendo las instrucciones que generadas por el
alumno que él crea conveniente.
A continuación, se enumeran los requisitos para los entornos de pruebas
Requisitos de Hardware:
• Procesador Intel o compatible de 800 MHz o superior
• 512 MB RAM
• 30 MB libres en el disco rígido
• Conexión a red
Requisitos de Software:
• Máquina Virtual de Java (JRE o JDK) 1.6 o superior
• Web Server (Apache 1.3.33 o superior recomendado)
• PHP 4.3.10 o superior
• MySQL 4.1.9 o superior
Programación Domótica Basada en Sistemas Expertos
108
• Navegador web (Firefox 2.0 o superior recomendado)
• Adobe Flash Player 10
A.1.2.10.3. Definición de las Pruebas de Aceptación del
Sistema
En esta tarea se realizará la especificación de las pruebas de aceptación del
sistema, labor fundamental para que el usuario valide el sistema, como último
paso, previo a la puesta en explotación.
Se insistirán en los criterios de aceptación del sistema que sirven de base para
asegurar que satisface los requisitos exigidos.
Reporte de fallas de las pruebas
Las fallas serán identificadas durante el análisis y evaluación de los resultados de la
ejecución de las pruebas. Se utilizará el siguiente formato para las tarjetas de
reporte de pruebas.
Reporte de Prueba Nro: ………………….. Fecha: __/__/__
Objetivo: ……………………………………………………………………………………………………….
……………………………………………………………………………………………………………………………
…………………………….………………………………………………………………………………………..
Errores encontrados:
ID Caso de Prueba Nivel Severidad Descripción
Programación Domótica Basada en Sistemas Expertos
109
Criterio de Paso/Falla
Los criterios a aplicar en la evaluación de las distintas instancias de prueba son:
• Paso: Todas las pruebas realizadas sobre el ítem fueron exitosas.
• Fallo: Al menos una de las pruebas realizadas no fue exitosa.
El criterio a emplear sobre las pruebas de la aplicación es el siguiente:
• Exitosa: Todas las pruebas fueron realizadas y no se encontraron defectos
de severidad 1, 2 o 3.
• Fallida: Al menos un defecto de severidad 1, 2 o 3 fue encontrado.
Severidad Descripción 1 Sistema detenido
2 Fallas de funcionalidad
3 Una solución alternativa puede aplicarse
4 Error de documentación/ayuda
5 Cambios y mejoras
Criterio de suspensión y reiniciación de pruebas
Las actividades de prueba deberían ser suspendidas si se encuentra algún
problema que impida la realización de la prueba ó un problema que impida la
realización de más pruebas. Esto implica que cuando se encuentre un problema y
se puedan seguir haciendo pruebas, las mismas deben continuar. Las pruebas
deben reiniciarse cuando los inconvenientes hayan sido solucionados,
comenzando con el primer caso de prueba para así verificar que la solución
propuesta no genere nuevos problemas.
Actividades de prueba
Las actividades de prueba contemplan: actualizar el plan de pruebas y
documentación de diseño, crear o actualizar casos de prueba, efectuar pruebas y
realizar su análisis (documentando las fallas en la tarjeta previamente
mencionada) y por último, llevar a cabo la prueba de aceptación del sistema para
Programación Domótica Basada en Sistemas Expertos
110
comprobar si el mismo responde fielmente a los requisitos del sistema
previamente definidos en este documento.
A.1.2.11. Aprobación del Análisis del Sistema de Información
A.1.2.11.1. Presentación y Aprobación del Análisis del Sistema
de Información
El análisis del sistema fue presentado y aprobado por los Directores del Trabajo
Profesional.
Programación Domótica Basada en Sistemas Expertos
111
A.1.3. Diseño del Sistema de Información
En esta actividad se definirá la arquitectura general del sistema de información,
especificando las distintas particiones físicas del mismo, la descomposición lógica en
subsistemas de diseño y la ubicación de cada subsistema en cada partición, así como la
especificación detallada de la infraestructura tecnológica necesaria para dar soporte al
sistema de información.
A.1.3.1. Definición de la Arquitectura del Sistema
A.1.3.1.1. Definición de los Niveles de Arquitectura
En esta tarea se describirán los niveles de la arquitectura software, mediante la
definición de las principales particiones físicas del sistema de información,
representadas como nodos y comunicaciones entre nodos.
Se entiende por nodo cada partición física o parte significativa del sistema de
información, con características propias de ejecución o función, e incluso de
diseño y construcción.
Para facilitar la comprensión del sistema, se identificarán como nodos los
elementos de infraestructura más significativos de la arquitectura en la que se va a
implementar el sistema de información.
La comunicación se expresa por una conexión entre nodos, indicando su carácter
bidireccional o unidireccional, con las principales características de los protocolos
o tipo de mensajes utilizados.
Programación Domótica Basada en Sistemas Expertos
112
Programación Domótica Basada en Sistemas Expertos
113
Descripción
• El Sistema se encuentra dividido en un lado Cliente (parte baja de la
imagen) y un lado Servidor (parte de arriba de la imagen).
• La comunicación entre el lado Cliente y el Servidor se realiza vía Internet,
mientras que la conexión física con la red puede ser vía ADSL,
Cablemódem ó Telefónica Dial Up. Sin embargo, una conexión de banda
ancha es deseable tanto para el Cliente como para el Servidor para
acelerar la descarga de los datos.
• El lado Cliente, representado por las dos PCs, es accesible vía un navegador
web con soporte Flash. Desde allí se controlan el Editor de Diagramas y el
Simulador, pudiéndose correr simultáneamente en la misma PC en dos
ventanas diferentes.
• El lado Servidor está compuesto por varios subsistemas que se comunican
entre sí vía TCP/IP, dentro de la máquina servidor, así como también una
Base de Datos donde persisten los diagramas creados en el editor. En el
servidor existe una capa que media entre los pedidos del cliente y el
servidor en sí, escrita en PHP.
• En el lado Servidor, el subsistema CodeGen genera el código de los
programas a partir de los diagramas en la Base de Datos y provee dichos
programas a Executer, que se encarga de ejecutarlos. Executer se encarga
a su vez de solicitar a HomeState la ejecución de las funciones remotas
quien a su vez deriva los pedidos a los sensores y actuadores que, en el
caso del presente trabajo, son ficticios y no tienen implementación física,
como ya se explicó a lo largo del presente informe.
A.1.3.1.2. Identificación de Requisitos de Diseño y
Construcción
En esta tarea se realizará la especificación de los requisitos que están
directamente relacionados con la adopción o diseño de una arquitectura o
Programación Domótica Basada en Sistemas Expertos
114
infraestructura concreta, y que pueden condicionar el diseño o la construcción del
sistema de información.
Entre estos requisitos pueden estar los relacionados con lenguajes, rendimiento de
los distintos elementos de la arquitectura, así como criterios de ubicación de
módulos y datos en los distintos nodos.
En esta actividad, la metodología sugiere incorporar los Requisitos de Hardware y
Software necesarios para el diseño y construcción del sistema. Los requisitos de
hardware para prueba fueron especificados en 2.2.10.2. Definición de Requisitos
del Entorno de Pruebas y ellos se aplican al diseño y construcción del sistema. En
cuanto a los requisitos de software, a los que figuran en 2.2.10.2, debe agregarse
un IDE de desarrollo, optando por Eclipse debido a la cantidad de herramientas
disponibles para el mismo, la posibilidad de agregar plug‐ins específicos para los
distintos lenguajes, etc. En 2.2.1.2. Identificación del Entorno Tecnológico se
mencionan las herramientas de desarrollo a utilizar y a eso hay que adicionar un
editor de texto con soporte para búsquedas con expresiones regulares e indicación
de número de línea, útiles a la hora de depurar los archivos PHP.
A.1.3.1.3. Especificación de Excepciones
El objetivo de esta tarea es la definición de los comportamientos no habituales en
el sistema, que reflejan situaciones anómalas o secundarias en el funcionamiento y
ejecución del sistema de información. Para ello, se establece previamente el nivel
de especificación de las mismas, así como los criterios de catalogación y
clasificación.
A continuación, se especificarán los lineamientos para el manejo de excepciones
para los distintos subsistemas, identificados en 2.2.3.1. Determinación de
Subsistemas de Análisis.
• Lado Cliente (GraFlow y Simulador): Las excepciones generadas estarán
relacionadas principalmente con la pérdida de conexión con el Lado
Servidor. Cuando esto suceda, en el texto de la respuesta, que deberá
estar armada en formato XML, deberá existir un tag llamado success cuyo
Programación Domótica Basada en Sistemas Expertos
115
valor sea 1 si no ocurrió ningún error y 0 en caso contrario, en este último
caso indicando además código de error y descripción en modo texto. A
partir de esta información se decidirá, durante la construcción del sistema
mostrar un cuadro de aviso del error con el texto recibido u otro que se
considere conveniente. Se recomienda no desestimar el error.
• Lado Servidor (CodeGen, HomeState y Executer): dado que estos
programas corren en el lado servidor y se dedican a atender los pedidos
del lado cliente y también teniendo en cuenta que no tendrán una interfaz
gráfica, se decidió que el reporte de errores será de la siguiente manera:
cada subsistema generará un reporte en un archivo de registro o log, en
donde se detallará la naturaleza de la excepción, fecha y hora de la misma.
Estos archivos se abrirán para concatenar datos, siendo responsabilidad
del usuario interpretarlos y eliminarlos.
A.1.3.1.4. Especificación de Estándares y Normas de Diseño y
Construcción
En esta tarea se definirán los estándares técnicos y de nomenclatura, normas y
recomendaciones, que generalmente están relacionados con la adopción o diseño
de una arquitectura o infraestructura tecnológica concreta, y que pueden
condicionar el diseño o la construcción del sistema de información.
A partir del diálogo entre los directores del Trabajo Profesional y el alumno, se
determinó que en lo referente a estándares y normas de diseño y construcción, el
presente trabajo deberá basarse en la Metodología de Desarrollo Métrica versión
3 y sus recomendaciones. Asimismo, dada la naturaleza del desarrollo orientado a
objetos, deberán seguirse sus principios de extensibilidad y encapsulamiento,
indicando los patrones de diseño y/o arquitectura utilizados.
A.1.3.1.5. Identificación de los Subsistemas de Diseño
En esta tarea, se consideraron como Subsistemas de Diseño a los Subsistemas de
Análisis, identificados y descritos en 2.2.3. Identificación de Subsistemas de
Análisis.
Programación Domótica Basada en Sistemas Expertos
116
A.1.3.1.6. Especificación del Entorno Tecnológico
El entorno tecnológico ya se definió en etapa de Análisis, más específicamente en
2.2.1.2. Identificación del Entorno Tecnológico.
A.1.3.2. Diseño de la Arquitectura de Soporte
En esta actividad se llevaría a cabo la especificación de la arquitectura de soporte y
comprende el diseño de los subsistemas de soporte identificados en la actividad de
Definición de la Arquitectura del Sistema (DSI 1) y la determinación de los mecanismos
genéricos de diseño. Estos últimos sirven de guía en la utilización de diferentes estilos
de diseño, tanto en el ámbito global del sistema de información, como en el diseño de
detalle.
El diseño de los subsistemas de soporte, conceptualmente, es similar al diseño de los
subsistemas específicos, aunque debe cumplir con unos objetivos claros de
reutilización. De esta manera, se consigue simplificar y abstraer el diseño de los
subsistemas específicos de la complejidad del entorno tecnológico, dotando al sistema
de información de una mayor independencia de la infraestructura que le da soporte.
En el caso del presente Trabajo Profesional, el cual a diferencia de los proyectos
empresariales, no persigue la elaboración de componentes para una posterior
reutilización en otros sistemas. Es por ello, que aquellos subsistemas que pudieran
estar incluidos como arquitectura de soporte ya fueron considerados en los
subsistemas específicos.
A.1.3.3. Diseño de los Casos de Uso Reales
Esta actividad, se especificará el comportamiento del sistema de información para un
caso de uso, mediante objetos o subsistemas de diseño que interactúan, y determinar
las operaciones de las clases e interfases de los distintos subsistemas de diseño.
Programación Domótica Basada en Sistemas Expertos
117
A.1.3.3.1. Identificación de las Clases Asociadas con un Caso
de Uso
En esta tarea se identificarán las clases que intervienen en cada caso de uso, a
partir del conjunto de clases definidas en la tarea Identificación de Clases
Adicionales (DSI 4.1). Dichas clases se identifican a partir de las clases del modelo
del análisis y de aquellas clases adicionales necesarias para el escenario que se
está diseñando.
Teniendo en cuenta lo desarrollado hasta el momento en la etapa de Diseño y lo
visto en la etapa de Análisis, concluimos que las clases identificadas para los casos
de uso obtenidas en ésta última etapa son válidas y completas. Para más
información, referirse a 2.2.4.1. Identificación de Clases Asociadas a un Caso de
Uso.
A.1.3.3.2. Revisión de la Interfaz de Usuario
En esta tarea, se revisaron los diseños de interfaz hechos en Microsoft Visio en
2.2.8. Definición de Interfases de Usuario y se analizó si las mismas pueden
completarse utilizando las herramientas de desarrollo elegidas: Flex para el lado
Cliente y Java para el lado Servidor. Se concluyó que las interfases propuestas
pueden construirse en los lenguajes a utilizar.
A.1.3.3.3. Revisión de Subsistemas de Diseño e Interfases
En 2.2.4.1. Identificación de Clases Asociadas a un Caso de Uso, figura además de
las clases asociadas a cada caso de uso, los subsistemas con los que dichas clases
se encuentran relacionadas.
A.1.3.4. Diseño de Clases
En esta actividad, se transformará el modelo de clases lógico, que proviene del análisis,
en un modelo de clases de diseño. Dicho modelo recoge la especificación detallada de
cada una de las clases, es decir, sus atributos, operaciones, métodos, y el diseño
preciso de las relaciones establecidas entre ellas, bien sean de agregación, asociación o
Programación Domótica Basada en Sistemas Expertos
118
jerarquía. Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones
tomadas sobre el entorno tecnológico y el entorno de desarrollo elegido para la
implementación.
A.1.3.4.1. Identificación de Clases Adicionales
En esta tarea se identificará un conjunto de clases que completen el modelo de
clases analizado en la tarea Validación de los Modelos (2.2.9.3) del proceso
anterior. Las siguientes clases fueron identificadas teniendo en cuenta las
enumeradas en 2.2.4.1, las interfases de usuario proyectadas en 2.2.8 y lo visto en
esta etapa de Diseño. Dichas clases e interfases (en este último caso, sus nombres
empiezan con I) están fundamentalmente relacionadas con patrones de diseño
(Builders, Factorys) para la construcción de objetos complejos o bien dedicadas a
servicios de la interfaz de usuario.
Nombre de la Clase o Interfaz
Caso(s) de Uso Asociado(s) Subsistema(s) asociado(s)
BuilderDiagrama CrearDiagrama, Editar Diagrama
Editor de Diagramas
BuilderPrograma CrearDiagrama, Editar Diagrama
Editor de Diagramas
BuilderMapper CrearDiagrama, Editar Diagrama
Editor de Diagramas
DraggableImage Editar Diagrama Editor de Diagramas ICaminoFlecha Editar Diagrama Editor de Diagramas Punto Editar Diagrama Editor de Diagramas Línea Editar Diagrama Editor de Diagramas Rectángulo Editar Diagrama Editor de Diagramas OpenDlg Editar Diagrama Editor de Diagramas SaveDlg Guardar Diagrama Editor de Diagramas ManagerDlg Administrar Diagramas Editor de Diagramas IBuilderHome, BuildSimulatedHome
Ejecutar Programa, VisualizarEstado, Simular Cambio en Sensor
Emulador de las variables del hogar, estado de la casa
IBuilderExpression, BuilderExpression
Generar Programa Generador de Código
IBuilderProgram, BuilderProgramCLIPS
Generar Programa Generador de Código
IFactoryExpression, FactoryExpression
Generar Programa Generador de Código
IFactoryProgram, FactoryProgramCLIPS
Generar Programa Generador de Código
BuilderDispatcher Administrar Programas Ejecutor de Código BuilderFileConditions Administrar Programas Ejecutor de Código BuilderSensorSystem Administrar Programas Ejecutor de Código
Programación Domótica Basada en Sistemas Expertos
119
Descripción de las Clases Adicionales
BuilderDiagrama: clase encargada de construir un objeto de la clase Diagrama a
partir de los datos almacenados, provenientes de una edición previa.
BuilderPrograma: clase responsable de la construcción de un objeto de la clase
Programa a partir de los datos almacenados, provenientes de una edición previa.
BuilderMapper: esta clase se ocupa de construir un objeto de la clase Mapper a
partir de los datos almacenados, provenientes de una edición previa.
DraggableImage: clase responsable de modelar los comportamientos de una
imagen arrastrable (drag&drop) por la pantalla de edición del diagrama, utilizada
por cada una de las figuras del mismo.
ICaminoFlecha: interfaz que declara los métodos utilizados para definir la
estrategia a utilizar para dibujar la flecha entre dos figuras.
Punto: clase responsable de modelar un punto dentro del diagrama.
Línea: clase responsable de modelar una línea dentro del diagrama.
Rectángulo: clase encargada de modelar las coordenadas de un rectángulo dentro
del diagrama.
OpenDlg: clase que modela el comportamiento del cuadro “Abrir Diagrama” (ver
2.2.8.4)
SaveDlg: clase que modela el comportamiento del cuadro “Guardar/Guardar como
Diagrama” (ver 2.2.8.4)
ManagerDlg: clase que modela el comportamiento del cuadro “Administrar
Diagramas” (ver 2.2.8.4)
IBuilderHome: interfaz que declara los métodos utilizados para construir un objeto
Home. BuildSimulatedHome implementa la interfaz para una casa simulada con
una configuración de habitaciones predeterminadas.
BuilderDispatcher: clase que crea un objeto de la clase Dispatcher con todos los
archivos que ésta debe vigilar.
BuilderFileConditions: clase que crea un objeto de la clase FileConditions a partir
de información persistente.
Programación Domótica Basada en Sistemas Expertos
120
BuilderSensorSystem: clase que crea un objeto de la clase SensorSystem a partir
de información serializada.
IBuilderExpression: interfaz que declara los métodos utilizados para construir un
objeto de la clase Expression (haciendo uso de un factory) a partir de información
serializada. BuilderExpression implementa esta interfaz.
IBuilderProgram: interfaz que declara los métodos utilizados para construir un
objeto Program (haciendo uso de un factory) a partir de la información
persistente. BuilderProgramCLIPS implementa esta interfaz para programas
escritos en CLIPS.
IFactoryExpression: interfaz que declara los métodos para construir los objetos de
la clase Expression y sus derivadas. FactoryExpression implementa esta interfaz.
IFactoryProgram: interfaz que declara los métodos para construir los objetos
relacionados con la clase Program. FactoryProgramCLIPS implementa esta interfaz
para programas escritos en CLIPS
A.1.3.4.2. Diseño de Asociaciones y Agregaciones
En esta tarea, se completarán las asociaciones y agregaciones entre las clases. Para
facilitar la lectura, y hacer el proceso más eficiente, se transcribirán los resultados
una vez realizadas esta actividad y las siguientes:
A.1.3.4.3. Identificación de los Atributos de las Clases
En esta tarea se identificarán y describirá, una vez especificado el entorno de
desarrollo, los atributos de las clases.
Y además,
A.1.3.4.4. Identificación de las Operaciones de las Clases
En esta tarea se definirán, de forma detallada, las operaciones de cada clase de
diseño. Para ello, se tomará como punto de partida el modelo de clases generado
en el análisis, así como el diseño de los casos de uso reales y los requisitos de
diseño que pueden aparecer al definir el entorno de desarrollo.
Programación Domótica Basada en Sistemas Expertos
121
Se actualizarán los diagramas de clases generados en 2.2.5. Análisis de las Clases,
de acuerdo a las nuevas clases identificadas, se completarán con sus asociaciones,
agregaciones, atributos y operaciones.
Editor de Diagramas
Programación Domótica Basada en Sistemas Expertos
122
Emulador de las variables del hogar, estado de la casa
Programación Domótica Basada en Sistemas Expertos
123
Generador de Código
Programación Domótica Basada en Sistemas Expertos
124
Ejecutor de Código
Programación Domótica Basada en Sistemas Expertos
125
Simulador
No se registraron nuevas clases durante la etapa de Diseño, por lo cual se
conserva el diagrama de la etapa de Análisis (tarea 2.2.5. Análisis de las Clases).
A.1.3.4.5. Diseño de la Jerarquía
En esta tarea se revisará la jerarquía de clases que ha surgido en el modelo de
clases a lo largo de las tareas anteriores y comprobará si esa jerarquía es viable
según los mecanismos disponibles en el entorno de desarrollo utilizado.
Se verificó la jerarquía de clases y se determinó que es viable, en función de las
herramientas a utilizar para el desarrollo del sistema. En los diagramas expuestos
en 2.3.4 Diseño de clases, ya figuran interfases y clases abstractas útiles que
pudieron ser identificadas.
A.1.3.4.6. Descripción de los Métodos de las Operaciones
En esta tarea se describirán los métodos que se usan para detallar como se realiza
cada una de las operaciones de una clase. Los métodos pueden especificarse
mediante un algoritmo, usando pseudocódigo o lenguaje natural.
Debido al número de clases y de métodos, para simplificar la lectura, se decidió
especificar en borrador a los más representativos y esa información se utilizará a la
hora de generar la documentación para el programador (JavaDoc en el caso de
Java y ASDoc en el caso de Flex). Por ello, además del presente informe, se
entregará documentación la cual estará formada en parte de los archivos que sean
generados durante la construcción del sistema, sean JavaDocs y ASDocs.
A.1.3.4.7. Especificación de Necesidades de Migración y Carga
Inicial de Datos
En esta tarea se realiza, en los casos que sea necesario y a partir de los resultados
de la tarea 2.2.6.4, una primera especificación de las necesidades de migración o
Programación Domótica Basada en Sistemas Expertos
126
carga inicial de los datos requeridos por el sistema, que se completa en la actividad
Diseño de la Migración y Carga Inicial de Datos (2.3.9).
En el caso del presente Trabajo Profesional, como se decidió realizar un Diseño
Orientado a Objetos, no se realizó 2.2.6.4. Sin embargo, las necesidades carga
inicial de datos y migración en este Proyecto estarán relacionadas con las
funciones domóticas disponibles, las habitaciones donde cada una de ellas podrán
realizarse y los parámetros que toman estas funciones.
Se llegó a la conclusión que la mejor forma de cumplir con esta carga inicial es
delegar esta tarea al instalador de la aplicación servidor y que éste se ocupe de
generar las tablas apropiadas junto con los datos que se requieran para activar la
aplicación. El instalador podrá pedir que exista un motor de bases de datos
instalado y que se encuentre en funcionamiento al momento de comenzar el
proceso de instalación.
A.1.3.5. Diseño de la Arquitectura de Módulos del Sistema
Esta actividad se omite, debido a que su realización es únicamente en los casos de
Diseño Estructurado.
A.1.3.6. Diseño Físico de Datos
En esta actividad se definirá la estructura física de datos que utilizará el sistema, a
partir del modelo lógico de datos normalizado o modelo de clases, de manera que
teniendo presentes las características específicas del sistema de gestión de datos
concreto a utilizar, los requisitos establecidos para el sistema de información, y las
particularidades del entorno tecnológico, se consiga una mayor eficiencia en el
tratamiento de los datos.
A.1.3.6.1. Diseño del Modelo Físico de Datos
En el presente trabajo, se utilizará un motor de una Base de Datos relacional, para
almacenar y recuperar los diagramas generados, determinar su estado y recuperar
Programación Domótica Basada en Sistemas Expertos
127
la información acerca de las funciones domóticas disponibles del hogar y de cada
habitación en particular.
Para realizar este diseño, se creó un Diagrama Entidad‐Relación
Como puede verse en el Diagrama, el diseño de la Base de Datos es sencillo.
Por un lado, se tiene a la entidad FILE (Archivo) que tiene varios atributos, id
representa a la identificación unívoca para cada archivo de diagrama; name es el
nombre de dicho archivo, content es el contenido de ese archivo que representa el
diagrama (en formato XML) y active indica si ese diagrama está activo (activado) o
no.
Por el otro lado, se encuentra la entidad ROOM (habitación) que modela a cada
habitación de la vivienda; el atributo id es la clave y el atributo name define el
nombre de la habitación. La entidad FUNCTION (función) por su parte, representa
cada función domótica disponible en el hogar; posee una clave id, un atributo
name para el nombre que toma la función, has_return indica si la función devuelve
algún valor y help es la ayuda en línea para el usuario sobre cómo utilizar esa
función. La última entidad, denominada PARAMETER (parámetro) representa a
cada parámetro que toma una función con su nombre (atributo name) y clave (id).
Programación Domótica Basada en Sistemas Expertos
128
Cada habitación puede ejecutar 0 ó más funciones mientras que cada función está
disponible en 0 ó más habitaciones (relación Ejecuta). Asimismo, cada función
puede tener 0 ó más parámetros mientras que cada parámetro está relacionado
con una y sólo una función.
A partir de estas entidades se construirán las tablas correspondientes que serán
explotadas principalmente por el subsistema Editor de Diagramas.
El acceso a dichas tablas permitirá llenar los cuadros de diálogo especificados en
2.2.8.4. Especificación del Comportamiento Dinámico de la Interfaz.
Teniendo en cuenta que el motor de base de datos a utilizar es MySQL (ver 2.2.1.2.
Identificación del Entorno Tecnológico), las sentencias para generación de las
tablas serían:
CREATE TABLE files( id INT NOT NULL AUTO_INCREMENT PRIMARY
KEY , name VARCHAR(50), content TEXT, active INT NOT NULL)
ENGINE=InnoDB;
CREATE TABLE rooms (id INT NOT NULL PRIMARY KEY , name VARCHAR(50)) ENGINE=InnoDB; CREATE TABLE functions (id INT NOT NULL PRIMARY KEY, name VARCHAR(50), help VARCHAR(200), has_return INT NOT NULL ) ENGINE=InnoDB; CREATE TABLE parameters(id INT NOT NULL PRIMARY KEY, name VARCHAR(50)) ENGINE=InnoDB; CREATE TABLE rooms_functions (id_room INT NOT NULL REFERENCES rooms(id) ON UPDATE CASCADE ON DELETE CASCADE, id_function INT NOT NULL REFERENCES functions(id) ON UPDATE CASCADE ON DELETE CASCADE, PRIMARY KEY(id_room, id_function)) ENGINE=InnoDB; CREATE TABLE functions_parameters (id_function INT NOT NULL REFERENCES functions(id) ON UPDATE CASCADE ON DELETE CASCADE, id_parameter INT NOT NULL REFERENCES parameters(id) ON UPDATE CASCADE ON DELETE CASCADE, PRIMARY KEY(id_function, id_parameter)) ENGINE=InnoDB;
La tabla rooms_functions representa la relación Ejecuta mientras que la tabla
functions_parameters representa la relación Recibe.
Programación Domótica Basada en Sistemas Expertos
129
A.1.3.6.2. Especificación de los Caminos de Acceso a los Datos
El objetivo de esta tarea es determinar los caminos de acceso a los datos
persistentes del sistema, utilizados por los principales módulos/clases de acuerdo
al modelo físico de datos, con el fin de optimizar el rendimiento de los gestores de
datos o sistemas de ficheros y el consumo de recursos, así como disminuir los
tiempos de respuesta.
A continuación, se especificarán los caminos para obtener datos desde la Base de
Datos:
a. Lista de archivos (diagramas) almacenados (cuadros Abrir, Guardar y
Guardar como)
Requieren el acceso a una única tabla (files), los datos deben ser leídos,
serializados a XML por parte del mediador (archivo) entre la Base MySQL y
la interfaz web (Flex), la cual mostrará el listado en pantalla.
b. Guardar archivo (diagrama)
A partir del ítem anterior, es necesario un único acceso a la tabla files para
guardar el nuevo archivo con un nuevo id ó guardar un archivo existente
con su correspondiente id.
c. Lista de archivos (diagramas) almacenados y activados/desactivados
(cuadro Administrar Diagramas)
Requiere el acceso a una única tabla (files), los datos deben ser leídos,
serializados a XML por parte del mediador (archivo) entre la Base MySQL y
la interfaz web (Flex), la cual mostrará el listado en pantalla y cuáles se
encuentran activados y cuáles no.
Programación Domótica Basada en Sistemas Expertos
130
d. Recuperar funciones domóticas disponibles, con sus parámetros y en qué
habitaciones pueden ejecutarse
En este caso, es necesario acceder a 5 tablas (rooms, functions,
parameters, rooms_functions y functions_parameters), los datos deben ser
leídos, serializados a XML por parte del mediador (archivo) entre la Base
MySQL y la interfaz web (Flex), la cual mostrará el listado en pantalla y
cuáles se encuentran activados y cuáles no.
A continuación, se evaluará si conviene desnormalizar para acelerar la
performance.
A.1.3.6.3. Optimización del Modelo Físico de los Datos
En esta tarea se decidirá si optimizar el diseño físico de datos, con el objetivo de
mejorar el tiempo de respuesta en el acceso a datos persistentes, hacer una
adecuada utilización de los recursos del sistema y, en consecuencia, garantizar que
el diseño satisface las necesidades de tratamiento establecidas para el sistema de
información en cuanto a que se ajusta a los requisitos de rendimiento exigidos.
Dados los caminos de accesos definidos en el 2.3.6.2, el único que puede ser
mejorado (aquel con una cantidad de accesos mayor a uno) es d. Teniendo en
cuenta la naturaleza del Trabajo Profesional, la arquitectura decidida para el
sistema, los requerimientos funcionales antes expresados y el hecho de que las
funciones domóticas son como mucho un par de decenas, se decidió mantener la
estructura normalizada descrita en 2.3.6.1. Además, no existirán gran cantidad de
accesos concurrentes (este sistema corre en el entorno de una vivienda y
automatiza las tareas para esa en particular, podrán existir accesos remotos pero
pocas personas –los habitantes de la misma‐ serán los interesados en utilizar el
Editor de Diagramas).
Programación Domótica Basada en Sistemas Expertos
131
A.1.3.6.4. Especificación de la Distribución de Datos
El Gestor de Datos con las tablas antes mencionadas en la Actividad, estará
ubicado en el Servidor que puede verse en el Diagrama de Arquitectura, en la
actividad 2.3.1. Definición de la Arquitectura del Sistema.
A.1.3.7. Verificación y Aceptación de la Arquitectura del Sistema
El objetivo de esta actividad es garantizar la calidad de las especificaciones del diseño
del sistema de información y la viabilidad del mismo, como paso previo a la generación
de las especificaciones de construcción.
A.1.3.7.1. Verificación de las Especificaciones de Diseño
El grupo de trabajo verificó cada uno de los modelos generados y se comprobó
que éstos estaban de acuerdo a las técnicas seguidas para la elaboración de cada
producto.
A.1.3.7.2. Análisis de Consistencia de las Especificaciones de
Diseño
En esta tarea, el grupo de trabajo verificó que las especificaciones de diseño
fueran coherentes entre sí y que carezcan de ambigüedades o duplicación de
información. Pudo asegurarse, entonces, la consistencia entre las especificaciones
de diseño y los modelos del análisis.
A.1.3.7.3. Aceptación de la Arquitectura del Sistema
Los Directores del presente Trabajo Profesional aceptaron la arquitectura
presentada del sistema, y sus sugerencias fueron incorporadas en la descripción de
las anteriores tareas de Diseño de este informe.
Programación Domótica Basada en Sistemas Expertos
132
A.1.3.8. Generación de las Especificaciones de Construcción
En esta actividad se generarán las especificaciones para la construcción del sistema de
información, a partir del diseño detallado.
Estas especificaciones definen la construcción del sistema de información a partir de
las unidades básicas de construcción (componentes), entendiendo como tales
unidades independientes y coherentes de construcción y ejecución, que se
corresponden con un empaquetamiento físico de los elementos del diseño de detalle,
como pueden ser módulos, clases o especificaciones de interfaz.
A.1.3.8.1. Especificación del Entorno de Construcción
En esta tarea se definirá el entorno necesario para la construcción de los
componentes del sistema de información, en cuanto a hardware, software,
comunicaciones y herramientas de construcción.
El entorno de construcción de este Trabajo Profesional está limitado a los recursos
disponibles por parte del alumno, pudiendo mencionar:
• Hardware
o Una PC (Intel Core Duo 1,6 GHz, 2GB RAM, Disco de 80 GB, Resolución 1280 x 800 píxeles)
• Software
o Windows XP SP2 Professional
o Microsoft Virtual PC 6.0
o Navegadores web (Internet Explorer 7, Mozilla Firefox 2.0, Google Chrome 1.0)
o EasyPHP 1.8 (Apache 1.3.x, Base de Datos MySQL 4.1.x, PHP 4.3.x)
o Adobe Flash Player 9
Programación Domótica Basada en Sistemas Expertos
133
o Herramientas de construcción
Java 1.6 (JDK 1.6.0.11)
CLIPS (versión 6.3)
IDE Eclipse (3.3.0) con FlexBuilder 3 Plug‐in
Nullsoft Scriptable Install System versión 2.44 (Generador
de instaladores)
• Comunicaciones
o Conexión a Internet por Banda Ancha a 1 Mbps
A.1.3.8.2. Definición de Componentes y Subsistemas de
Construcción
En esta tarea, se definieron a los subsistemas de diseño como subsistemas de
construcción, es decir, existirán cinco subsistemas de construcción:
1. Editor de Diagramas
2. Generador de Código
3. Simulador y visualizador de eventos
4. Emulador de las variables del hogar, estado de la casa
5. Ejecutor de Código
Los subsistemas 1 y 3 serán construidos en Flex para ser utilizados a través del
navegador web, desde el lado Cliente del sistema.
El resto de los subsistemas serán construidos como programas independientes en
Java, formando el lado Servidor del sistema.
La comunicación para sincronización y notificación de eventos entre los
subsistemas del Servidor será vía el protocolo TCP/IP mediante el formato
apropiado mientras que la comunicación entre los subsistemas del lado Cliente
con los del lado Servidor será estrictamente vía el protocolo HTTP, desarrollándose
los archivos PHP necesarios para brindar los Web Services apropiados.
Programación Domótica Basada en Sistemas Expertos
134
A.1.3.9. Diseño de la Migración
Esta actividad sólo se lleva a cabo cuando es necesaria una carga inicial de
información, o una migración de datos de otros sistemas, cuyo alcance y estrategia a
seguir se habrá establecido previamente.
Para ello, se toma como referencia el plan de migración y carga inicial de datos, que
recoge las estructuras físicas de datos del sistema o sistemas origen implicadas en la
conversión, la prioridad en las cargas y secuencia a seguir, las necesidades previas de
depuración de la información, así como los requisitos necesarios para garantizar la
correcta implementación de los procedimientos de migración sin comprometer el
funcionamiento de los sistemas actuales.
En este Trabajo, como no existe migración de datos de otros sistemas, sólo se
trabajará en esta actividad la carga inicial de datos.
A.1.3.9.1. Diseño de Procedimientos de Carga Inicial
En esta tarea se definirán los procedimientos necesarios para llevar a cabo la carga
inicial de datos del sistema.
Como punto de partida se tiene en cuenta, junto con los requisitos y
especificaciones de carga inicial, el modelo físico de datos optimizado y su
localización en los nodos, así como la definición del entorno tecnológico del
sistema de información.
Los procedimientos asociados son, principalmente, los relacionados con la
preparación, la realización y la posterior verificación del proceso.
Para este punto, se tomaron los siguientes criterios a la hora de la carga inicial de
datos:
• La carga inicial de datos deberá estar incluida en el proceso de instalación
del lado Servidor.
Programación Domótica Basada en Sistemas Expertos
135
• Deberá desarrollarse un programa que a partir del nombre de usuario y
contraseña (especificados por quien está instalando el sistema), se
encargue de generar las tablas correspondientes y cargar los datos
iniciales, sin mayor intervención que mantener el motor de la base de
datos activo.
• En caso de existir las tablas, deberán descartarse y crearse y llenarse desde
cero.
• Ante la eventual desinstalación del lado Servidor, las tablas y sus datos
deberán permanecer almacenadas.
• Las tablas deberán ser creadas y posteriormente llenadas en este orden:
rooms, functions, parameters, rooms_functions y functions_parameters. La
tabla files que contiene los diagramas deberá ser inicializada antes que
todas y sin registros.
A.1.3.10. Especificación Técnica del Plan de Pruebas
En esta actividad se realizará la especificación de detalle del plan de pruebas del
sistema de información para cada uno de los niveles de prueba establecidos en el
proceso Análisis del Sistema de Información:
• Pruebas unitarias
• Pruebas de integración
• Pruebas del sistema
• Pruebas de implantación
• Pruebas de aceptación
Para ello se toma como referencia el plan de pruebas, que recoge los objetivos de la
prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del
marco adecuado para planificar paso a paso las actividades de prueba.
Programación Domótica Basada en Sistemas Expertos
136
A.1.3.10.1. Especificación del Entorno de Pruebas
En esta tarea se definirá el entorno necesario para la realización de las pruebas del
sistema: unitarias, de integración, de implantación y de aceptación.
El objetivo de esta tarea ya fue cubierto en la Etapa de Análisis, en el punto
2.2.10.2. Definición de Requisitos del Entorno de Pruebas.
A.1.3.10.2. Especificación Técnica de los Niveles de Prueba
En esta tarea se realizará la descripción de los principios técnicos que guiarán a
cada uno de los niveles de las pruebas:
• Pruebas Unitarias de las Clases
Las Pruebas Unitarias de las Clases o unit testing se limitará, como ya se
mencionó en la fase de análisis, a aquellas clases que provean servicios
fundamentales para que el sistema cumpla su objetivo en el lado Servidor,
esto significa que se probarán en particular las clases dedicadas a la
interpretación del diagrama, generación y ejecución del programa y las
funciones. Para ello se usará JUnit. El lado cliente de la aplicación, dado su
carácter netamente interactivo y visual, impide la automatización de las
pruebas, con lo cual las clases de los subsistemas que lo componen serán
probadas a través de pruebas de integración y de sistema.
• Pruebas de Integración
Las Pruebas de Integración tendrán como objetivo asegurar que los distintos
subsistemas reciban la información en el formato esperado y que su salida esté
acorde a la esperada por el subsistema que depende del primero. Se verificará
entonces, que al generar un diagrama, este puede ser interpretado
correctamente y que se genere un programa capaz de ser interpretado por el
motor de inferencias y que las funciones utilizadas se ejecuten correctamente.
Programación Domótica Basada en Sistemas Expertos
137
• Pruebas de Sistema
Las pruebas de sistema tendrán como objetivo verificar todo el proceso, desde
la generación del diagrama, el guardado, una eventual reapertura, la
generación del programa, la puesta en espera para ejecución del mismo y la
activación correspondiente con su comprobación en el simulador de las
acciones tomadas.
• Pruebas de Aceptación del Sistema
Las pruebas de Aceptación del Sistema son similares a las Pruebas de Sistema
pero las primeras se realizan en presencia de los Directores del Trabajo
Profesional.
A.1.3.11. Establecimiento de Requisitos de Implantación
En esta actividad se completará el catálogo de requisitos con aquellos relacionados con
la documentación que el usuario requiere para operar con el nuevo sistema, y los
relativos a la propia implantación del sistema en el entorno de operación.
La incorporación de estos requisitos permite ir preparando, los medios y recursos
necesarios para que los usuarios, tanto finales como de operación, sean capaces de
utilizar el nueva sistema de forma satisfactoria.
A.1.3.11.1. Especificación de los Requisitos de Documentación
de Usuario
En esta tarea se recogerá toda la información necesaria para la especificación de la
documentación a entregar al usuario.
La documentación a entregar al Usuario consistirá en un archivo de ayuda por cada
uno de los subsistemas generado, en formato de Ayuda Compilada en HTML
(CHM), pudiéndose instalar del lado servidor desde el instalador. Adicionalmente,
podrá instalarse esta documentación de ayuda del lado Cliente en formato HTML
plano, y así ser accesible a través de la Web desde el Editor de Diagramas y/o
Simulador.
Programación Domótica Basada en Sistemas Expertos
138
A.1.3.11.2. Especificación de Requisitos de Implantación
En esta tarea se especificarán de forma detallada los requisitos de implantación,
generalmente relacionados con la formación, infraestructura e instalación, con el
fin de preparar y organizar, con la antelación suficiente, todos los recursos
necesarios para la implantación e instalación del sistema de información.
Requisitos de Formación
Los requisitos de formación del usuario de este sistema (lado Cliente) son
conocimientos básicos de diagramas de flujo, manejo de PC e Internet. Del lado
servidor, para la instalación del sistema y puesta en marcha, es deseable que
posea conocimientos de instalación y configuración de un servidor Web y Base de
Datos así como experiencia en programación; sin embargo estas tareas pueden
ser llevadas adelante por un técnico que realice dicha configuración inicial.
Requisitos de Infraestructura e Instalación
El lado servidor de la aplicación deberá poder ejecutarse en una PC con un
procesador de 800 MHz o superior, con al menos 512 MB de RAM y 30 MB de
espacio libre en el disco para la instalación del sistema. Deberá tener instalado por
lo menos un browser (Internet Explorer 7, Mozilla Firefox 2.0, Google Chrome 1.0
ó superiores), un Web Server (Apache 1.3 recomendado), Base de Datos (MySQL
4.1 recomendado), PHP (4.3 recomendado), Adobe Flash plug‐in versión 9 o
superior y Java 1.6 o superior. Una conexión a internet de banda ancha es un
requisito deseable (en particular, si se desea acceder al sistema desde fuera del
hogar) pero no imprescindible (caso contrario, puede programarse desde el mismo
servidor).
Programación Domótica Basada en Sistemas Expertos
139
A.1.3.12. Aprobación del Diseño del Sistema de Información
A.1.3.12.1. Presentación y Aprobación del Sistema de
Información
Los directores del Trabajo Profesional revisaron y aprobaron el Diseño del Sistema
de Información presentado en esta Etapa que figura en el presente informe.
Programación Domótica Basada en Sistemas Expertos
140
A.1.4. Construcción del Sistema de Información
En este proceso se genera el código de los componentes del Sistema de Información, se
desarrollarán todos los procedimientos de operación y seguridad y se elaborarán todos los
manuales de usuario final y de explotación con el objetivo de asegurar el correcto
funcionamiento del Sistema para su posterior implantación.
A.1.4.1. Preparación del Entorno de Generación y Construcción
El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y
facilidades para que se pueda llevar a cabo la construcción del sistema de información.
Entre estos medios, cabe destacar la preparación de los puestos de trabajo, equipos
físicos y lógicos, gestores de bases de datos, bibliotecas de programas, herramientas
de generación de código, bases de datos o ficheros de prueba, entre otros.
A.1.4.1.1. Preparación del Entorno de Generación y
Construcción
En esta tarea se procederá a:
• Crear los elementos del sistema gestor de base de datos o sistema de
ficheros.
• Reservar el espacio de almacenamiento, definiendo, entre otros, los
dispositivos físicos a emplear, tamaño de los bloques, tipo de registro
físico, zona de desbordamiento, opciones de almacenamiento de datos,
etc.
• Inicializar la base de datos o ficheros, cargando los datos considerados
necesarios en el espacio de almacenamiento previamente definido.
Base de Datos
En la base de datos se almacenarán los diagramas creados por el usuario y se
recuperará la información de que funciones domóticas están disponibles en
cuál o cuáles habitaciones y que parámetros toman. A continuación se detalla
el script de creación de la base de datos.
Programación Domótica Basada en Sistemas Expertos
141
CREATE DATABASE newport;
USE newport;
CREATE TABLE files( id INT NOT NULL AUTO_INCREMENT
PRIMARY KEY , nombre VARCHAR(50), content TEXT, active
INT NOT NULL) ENGINE=InnoDB;
CREATE TABLE rooms (id INT NOT NULL PRIMARY KEY , name
VARCHAR(50)) ENGINE=InnoDB;
CREATE TABLE functions (id INT NOT NULL PRIMARY KEY,
name VARCHAR(50), help VARCHAR(200), has_return INT NOT
NULL ) ENGINE=InnoDB;
CREATE TABLE parameters(id INT NOT NULL PRIMARY KEY,
name VARCHAR(50)) ENGINE=InnoDB;
CREATE TABLE rooms_functions (id_room INT NOT NULL
REFERENCES rooms(id) ON UPDATE CASCADE ON DELETE
CASCADE, id_function INT NOT NULL REFERENCES
functions(id) ON UPDATE CASCADE ON DELETE CASCADE,
PRIMARY KEY(id_room, id_function)) ENGINE=InnoDB;
CREATE TABLE functions_parameters (id_function INT NOT
NULL REFERENCES functions(id) ON UPDATE CASCADE ON
DELETE CASCADE, id_parameter INT NOT NULL REFERENCES
parameters(id) ON UPDATE CASCADE ON DELETE CASCADE,
PRIMARY KEY(id_function, id_parameter)) ENGINE=InnoDB;
En la tabla files figurarán un registro por cada diagrama salvado por el usuario,
el campo content representa el contenido del diagrama en formato XML (dicho
formato se explicará en detalle más adelante en este punto). Esta tabla se
inicializará vacía al momento de la carga de inicial de datos.
El resto de las tablas corresponden a las funciones domóticas con los
parámetros que toma cada una de ellas y en que habitaciones de la vivienda
están disponibles.
Programación Domótica Basada en Sistemas Expertos
142
A continuación se detallarán cada una de estas funciones:
Nombre de la función
Descripción Parámetro(s) Disponible
en: Devuelve
luz Ajusta la intensidad de la luz de una habitación
Intensidad (entero 0..10)
Living Cocina
Comedor Baño
Dormitorio Garage
‐
fijarTemperatura
Fija la temperatura de la habitación seleccionada
Valor (entero 20..30)
Living Cocina
Comedor Baño
Dormitorio Garage
‐
enviarSMS Envía un mensaje de texto mensaje a un número de teléfono nro
• Nro (entero) • Mensaje (texto)
General ‐
regadores Activa los regadores con la intensidad especificada
Intensidad (entero 0..10)
Patio ‐
activarAlarma Dispara la alarma de la vivienda
‐ General ‐
incrementar Incrementa en 1 el valor del parámetro valor
Valor (entero) General Valor
incrementado en 1
suma Suma dos valores
• Sumando1 • Sumando2 (enteros)
General Sumando1
+ Sumando2
abrirPorton Abre el portón del Garage
‐ Garage ‐
cerrarPorton Cierra el portón del Garage
‐ Garage ‐
obtTemperatura Devuelve la temperatura en grados centígrados de la habitación seleccionada
‐
Living Cocina
Comedor Baño
Dormitorio Garage
Temperatura de la
habitación en °C
encenderMicroondas
Activa el horno a microondas con la intensidad y durante el tiempo determinado
• cantSegundos (entero): cantidad de segundos de cocción
• intensidad (entero 0..10): intensidad
Cocina ‐
Programación Domótica Basada en Sistemas Expertos
143
de cocción debug Despliega un
mensaje (paramDebug1 concatenado con paramDebug2) en la consola de eventos del simulador
• paramDebug1 (texto)
• paramDebug2 (texto)
General ‐
resta
Resta dos valores
• Minuendo (entero)
• Sustraendo (entero)
General Minuendo
‐ Sustraendo
NOT
Niega a valor Valor (entero) General
• Cero si valor es
distinto de 0
• Uno si valor es igual a 0
grabarTV Graba el canal de TV especificado durante la cantidad de minutos solicitada
• Canal (entero)
• DuracionMin (duración de la grabación en minutos
Living ‐
Formatos de Archivo a Utilizar
La forma de intercambio de datos entre subsistemas será a partir de archivos
XML, con lo cual, a continuación se definirán las estructuras de los principales,
utilizando XSD Schema.
• Archivos generados por el editor de diagramas
Estos archivos son generados al guardar un diagrama en la base de
datos y son almacenados en el campo content de cada registro de la
tabla files. Para abrir un diagrama, se recupera a un archivo por id de
la tabla files, se interpreta el content y se regenera el diagrama
correspondiente. La definición formal con el XSD Schema es:
Programación Domótica Basada en Sistemas Expertos
144
<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="file"> <xs:complexType> <xs:sequence> <xs:element name="diagrama"> <xs:complexType> <xs:sequence> <xs:element name="figura" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="left" type="xs:integer"/> <xs:element name="top" type="xs:integer"/> <xs:element name="width" type="xs:integer"/> <xs:element name="height" type="xs:integer"/> <xs:element name="label" type="xs:string"/> <xs:element name="tooltip" type="xs:string" /> <xs:element name="siguiente" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="destino" type="xs:integer" use="required"/> </xs:complexType> </xs:element> <xs:element name="verdadero" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="destino" type="xs:integer" use="required"/> </xs:complexType> </xs:element> <xs:element name="falso" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="destino" type="xs:integer" use="required"/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="type" type="xs:string" use="required"/> <xs:attribute name="id" type="xs:integer" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="programa"> <xs:complexType> <xs:sequence> <xs:element name="start_id" type="xs:integer" minOccurs="0" maxOccurs="1"/> <xs:element name="block" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:any/> </xs:sequence> <xs:attribute name="type" type="xs:string" use="required"/> <xs:attribute name="id" type="xs:integer" use="required"/> <xs:attribute name="next" type="xs:integer"/> <xs:attribute name="verdadero" type="xs:integer"/> <xs:attribute name="falso" type="xs:integer"/> </xs:complexType>
Programación Domótica Basada en Sistemas Expertos
145
</xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="mapper"> <xs:complexType> <xs:sequence> <xs:element name="item" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="figura" type="xs:string"/> <xs:element name="bloque" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Gráficamente, usando el Visual Studio, se aprecia que la estructura del XML que se generará es
sencilla:
Cada elemento del XML está representado como un rectángulo, y cada uno a su vez puede
contener atributos o/y otros elementos. De la figura, puede deducirse que el elemento
principal del XML es file y contiene tres elementos: diagrama, programa y mapper. El primero
contiene 0 ó más figuras, una por cada figura de la Vista que forma el diagrama de flujo. Las
figuras pueden estar conectadas entre sí por medio de los elementos siguiente, verdadero y
Programación Domótica Basada en Sistemas Expertos
146
falso y allí especificando como atributo el id de la figura destino. El elemento programa es al
Modelo del editor de diagramas lo que diagrama es a la Vista. Contiene 0 o más elementos
block con las características de un bloque de código (configuración establecida por el usuario).
Los bloques pueden unirse usando los atributos next, verdadero y falso con el id de la figura
destino.
Finalmente, el elemento mapper contiene a su vez elementos (0 ó más) item, que mantienen
la correspondencia entre cada figura de la vista y bloque del modelo.
• Archivos de intercambio entre Editor de Diagramas y Base de Datos
El editor de diagramas del lado cliente utiliza archivos XML para recibir
información proveniente del servidor. Esta información es la necesaria
para llenar los cuadros Abrir Diagrama, Guardar Diagrama, Administrar
Diagrama y el listado de funciones disponibles.
Abrir, Guardar y Administrar Diagrama, listan los archivos disponibles a
partir de un XML que sigue el siguiente Schema:
<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="filesystem"> <xs:complexType> <xs:sequence> <xs:element name="files"> <xs:complexType> <xs:sequence> <xs:element name="file" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="id" type="xs:integer"/> <xs:element name="active" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Programación Domótica Basada en Sistemas Expertos
147
Gráficamente,
El formato del XML consta de un elemento filesystem que tiene a su vez un elemento files que
tiene 0 ó más elementos file que contienen name (nombre), id (ID del archivo), active (indica si
un diagrama está activo –si/no‐).
Las funciones disponibles para ejecutar en un diagrama, se listan a partir
de un XML que sigue el siguiente Schema:
<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="response"> <xs:complexType> <xs:sequence> <xs:element name="success"> <xs:complexType> <xs:attribute name="value" type="xs:integer" use="required" /> </xs:complexType> </xs:element> <xs:element name="data"> <xs:complexType> <xs:sequence> <xs:element name="room" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="func" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="help" type="xs:string" /> <xs:element name="param" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="id" type="xs:integer" use="required" /> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="id" type="xs:integer" use="required" /> <xs:attribute name="has_return" type="xs:integer" use="required" /> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> </xs:element> </xs:sequence>
Programación Domótica Basada en Sistemas Expertos
148
<xs:attribute name="id" type="xs:integer" use="required" /> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Gráficamente:
Como aparece en la figura, la estructura consta de un elemento response, que contiene un
elemento success y un elemento data y éste último contiene 0 ó más room (habitación) con 0
ó más func (función), la cual puede tener 0 ó más param (parámetro).
Respuestas de acciones en el servidor, recibidas por el lado cliente:
Ejemplos de estas respuestas son: notificación al editor de que el diagrama
fue correctamente almacenado, que el diagrama fue ejecutado
satisfactoriamente, entre otros. El Schema correspondiente es:
<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="response"> <xs:complexType> <xs:sequence> <xs:element name="success"> <xs:complexType> <xs:attribute name="value" type="xs:integer" /> </xs:complexType> </xs:element> <xs:element name="error" minOccur="0" maxOccur="1"> <xs:complexType> <xs:sequence> <xs:element name="description" type="xs:string" /> </xs:sequence> <xs:attribute name="number" type="xs:integer" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Programación Domótica Basada en Sistemas Expertos
149
Gráficamente,
En la figura, el elemento response contiene un elemento success (que posee un atributo
numérico que indica si la operación se efectuó con éxito ‐1‐ ó no ‐0‐) y opcionalmente un
elemento error (con description que describe el error en forma de texto y un atributo number
que representa el código de error asociado).
• Archivos de intercambio entre el Lado Servidor y Simulador
Los eventos en la vivienda son reportados del servidor hacia el cliente en
un XML que se ajusta al siguiente esquema:
<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="response"> <xs:complexType> <xs:sequence> <xs:element name="success"> <xs:complexType> <xs:attribute name="value" type="xs:integer" use="required" /> </xs:complexType> </xs:element> <xs:element name="error" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="description" type="xs:string" /> </xs:sequence> <xs:attribute name="number" type="xs:integer" use="required" /> </xs:complexType> </xs:element> <xs:element name="log" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="entry" minOccurs="0" maxOccurs="unbounded"> <xs:complexType>
Programación Domótica Basada en Sistemas Expertos
150
<xs:sequence> <xs:element name="date" type="xs:string" /> <xs:element name="message" type="xs:string" /> <xs:any /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="time" type="xs:integer" use="required" /> <xs:attribute name="timeLastEntry" type="xs:integer" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Gráficamente,
En la imagen, se aprecia que el elemento principal del XML es response, el cual está
compuesto por un elemento success cuyo valor es 1 si no hubo errores, 0 en caso contrario. En
este último caso, response tiene otro elemento llamado error (con descripción y número de
error). En cualquier caso, response tiene un elemento log (donde figuran 0 ó más entry con la
descripción de cada evento generado) y dos atributos que marcan el tiempo en el que el
último entry fue generado al log (atributo timeLastEntry) y el tiempo en el que fue generado el
XML (atributo time).
• Archivos en el Lado Servidor necesarios para la ejecución de los
diagramas
Programación Domótica Basada en Sistemas Expertos
151
Cuando el subsistema CodeGen toma el diagrama y genera el código
ejecutable, está armando en paralelo dos archivos: uno con el código
ejecutable en reglas del sistema experto (CLIPS) y el otro con las
condiciones de activación de dicho programa (hora, día de la semana,
activación de algún sensor externo). Se describirá primero el archivo
con las condiciones por su sencillez y posteriormente al archivo con las
reglas generadas a partir del diagrama.
Archivo de Condiciones de Ejecución (.cond)
<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="start"> <xs:complexType> <xs:sequence> <xs:element name="options"> <xs:complexType> <xs:attribute name="days" type="xs:boolean" use="required" /> <xs:attribute name="time" type="xs:boolean" use="required" /> <xs:attribute name="triggers" type="xs:boolean" use="required" /> </xs:complexType> </xs:element> <xs:element name="days"> <xs:complexType> <xs:attribute name="sun" type="xs:boolean" use="required" /> <xs:attribute name="mon" type="xs:boolean" use="required" /> <xs:attribute name="tue" type="xs:boolean" use="required" /> <xs:attribute name="wed" type="xs:boolean" use="required" /> <xs:attribute name="thru" type="xs:boolean" use="required" /> <xs:attribute name="fri" type="xs:boolean" use="required" /> <xs:attribute name="sat" type="xs:boolean" use="required" /> </xs:complexType> </xs:element> <xs:element name="trigs"> <xs:complexType> <xs:attribute name="sunrise" type="xs:boolean" use="required" /> <xs:attribute name="sunset" type="xs:boolean" use="required" /> <xs:attribute name="door" type="xs:boolean" use="required" /> <xs:attribute name="alarm" type="xs:boolean" use="required" /> </xs:complexType> </xs:element> <xs:element name="time"> <xs:complexType> <xs:attribute name="hr" type="xs:integer" use="required" /> <xs:attribute name="min" type="xs:integer" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Programación Domótica Basada en Sistemas Expertos
152
Gráficamente,
La estructura del XML, como puede verse, consta de un elemento start que contiene cuatro
elementos: options, days, trigs y time. El elemento options tiene tres atributos: days, time y
triggers. El primero (si es true) indica que el programa asociado deberá ejecutarse ciertos días
de la semana. El segundo (si es true) determina que el programa se ejecute a cierta hora del
día. El último (si es true) establece que el programa se ejecutará ante la activación de algún
sensor externo.
Los siguientes elementos están siempre presentes en el XML aunque su interpretación por
parte del subsistema Executer depende del valor de los atributos previamente mencionados.
El elemento days tiene siete atributos (uno por cada día de la semana) que toman el valor true
si el usuario definió que el programa se ejecute ese día.
El elemento time tiene dos atributos que indican la hora y minutos (formato 24 horas) en el
cual ejecutar el programa.
Finalmente, el elemento trigs tiene cuatro atributos uno por cada sensor externo (detección
de amanecer y de anochecer, alarma y timbre, respectivamente) que están en true si el
programa debe ejecutarse ante la activación del sensor correspondiente.
Programación Domótica Basada en Sistemas Expertos
153
Archivos de Código Ejecutable como Reglas de Sistema Experto (.clp)
Como ya se mencionó en este informe, los diagramas generados en el
editor son almacenados como tales en la Base de Datos y,
paralelamente a esto, se genera el programa correspondiente a ese
diagrama. Dicho programa está formado por una serie de reglas de
sistema experto y una serie de hechos que son agregados
convenientemente a la base de conocimientos. Cada programa corre
con una base de conocimientos independiente del resto.
Para mayor información acerca de Programación de Sistemas Expertos,
se recomienda consultar la bibliografía que figura al final del presente
informe.
Dada la naturaleza de un diagrama de flujo, su conversión a un
programa estructurado es inmediata. Sin embargo, la conversión del
diagrama a un programa escrito en un lenguaje de sistema experto
como CLIPS es un poco más elaborada. A modo de ejemplo, se tomará
un diagrama de flujo sencillo, que puede ser generado con el Editor de
Diagramas y se explicarán las reglas básicas para la conversión a
código.
Programación Domótica Basada en Sistemas Expertos
154
La idea básica es que se genera una regla Ri por cada bloque i del diagrama de arriba (es decir,
por cada Asignación y cada Condición, la figura Comienzo solo marca el punto de arranque de
ejecución y condiciones que se utilizan para generar el archivo .cond, las figuras Fin están
presentes sólo por claridad). Dicha regla tiene como precondición para ejecutarse la existencia
de un hecho Fi en la base de conocimientos. Para que la regla Rj (que corresponde al siguiente
bloque que debe ejecutarse) se dispare efectivamente, Ri tiene como una de sus
postcondiciones la inserción de un hecho Fj y la remoción de Fi.
Pseudocódigo:
Regla Ri: Precondiciones: Ri, … Poscondiciones: InsertarHecho(Rj), EliminarHecho(Ri), …
En el archivo, la regla R0 que inicia la ejecución no tiene ningún hecho asociado, de modo que
se dispare inmediatamente al iniciar la ejecución, luego inserta un hecho F1 para que R1 se
ejecute. La regla R1 y las siguientes operan como se mencionó previamente al pseudocódigo.
Los bloques de condición son representados como dos reglas: en este caso se genera una R2T (por true) y una R2F (por false) donde la condición de comparación de T y F son opuestas.
Pseudocódigo:
Regla R2T: Precondiciones: Ri,(a < 11), … Poscondiciones: InsertarHecho(Rj), EliminarHecho(Ri), …
Regla R2F: Precondiciones: Ri,(a >= 11), … Poscondiciones: InsertarHecho(Rk), EliminarHecho(Ri), …
Las constantes del diagrama son representadas como constantes en las reglas mientras que las
variables del diagrama son representadas como hechos que se insertan en la base de
conocimientos. Como primera regla, se inicializan todas las variables usadas en el diagrama
como vacías (“”).
Cuando se utiliza una función, la regla se divide en dos: en primera instancia una regla Ri1 se
insertan ciertos hechos a la base que corresponden a la identificación de la función a ejecutar
así como los valores de sus parámetros y se invoca el comando break que detiene la ejecución
Programación Domótica Basada en Sistemas Expertos
155
de las reglas. El programa en Java encargado de la ejecución, determina en función de los
hechos la razón de la detención (se invoca la ejecución de una función como debug), ejecuta la
función, obtiene un resultado e inserta un hecho con el resultado de la función. Luego reanuda
la ejecución del programa la cual continúa en la regla Ri2.
En el programa en CLIPS además se agregan ciertas funciones macro definidas para simplificar
la escritura de las reglas. Cabe destacar que las sentencias (cada sentencia se encuentra
enmarcada entre paréntesis) en CLIPS no se ejecutan en orden de arriba hacia abajo, ya que la
ejecución depende de los hechos presentes en la base de conocimientos.
A continuación, se transcribe el programa de ejemplo ya procesado por CodeGen, en código CLIPS: (deftemplate var (slot name) (slot value)) (deftemplate func (slot value) (slot idRoom) (slot idFunc) (multislot params)) (deftemplate request (slot reason)) (deffunction var_assert (?name ?new_val) (do-for-all-facts( (?v var)) (eq ?v:name ?name) (retract ?v)) (assert (var (name ?name) (value ?new_val))) ) (deffunction toNum (?value) (if (integerp ?value) then ?value else 0 )) (deffunction func_assert_value (?idRoom ?idFunc ?new_val) (do-for-fact( (?f func)) (eq ?f:idRoom ?idRoom) (eq ?f:idFunc ?idFunc) (assert (func (value ?new_val) (idRoom ?f:idRoom) (idFunc ?f:idFunc) (params ?f:params) )) (retract ?f)) ) (defrule rule_init => (var_assert a "") (var_assert b "")
Programación Domótica Basada en Sistemas Expertos
156
(assert (fact_rule0)) ) (defrule rule0 ?id <- (fact_rule0) => ;(printout t "ejecutando comienzo rule0" crlf) (retract ?id) (assert (fact_rule0_showFilename))) (defrule rule1 ?id <- (fact_rule1) => ;(printout t "ejecutando asignacion rule1" crlf) (retract ?id) (var_assert a 26) (assert (fact_rule2))) (defrule rule2T ?id <- (fact_rule2) (var (name a) (value ?valor_a)) (test ( < (toNum ?valor_a) (toNum 11))) => ;(printout t "ejecutando condicion TRUE rule2" crlf) (retract ?id) (assert (fact_rule3))) (defrule rule2F ?id <- (fact_rule2) (var (name a) (value ?valor_a)) (not (test ( < (toNum ?valor_a) (toNum 11))) ) => ;(printout t "ejecutando condicion FALSE rule2" crlf) (retract ?id) (assert (fact_rule4))) (defrule rule3 ?id <- (fact_rule3) => ;(printout t "ejecutando asignacion rule3" crlf) (retract ?id) (var_assert b 1) (assert (fact_rule6))) (defrule rule4 ?id <- (fact_rule4) => ;(printout t "ejecutando asignacion rule4" crlf) (retract ?id) (var_assert b 2) (assert (fact_rule6))) (defrule rule5 ?id <- (fact_rule5) => ;(printout t "ejecutando fin rule5" crlf) (retract ?id)) (defrule rule6 ?id <- (fact_rule6) (var (name b) (value ?par_b_1_12)) => ;(printout t "ejecutando asignacion - funcion rule6" crlf) (assert (request (reason func))) (assert (func (idRoom 1) (idFunc 12) (params "b vale" ?par_b_1_12 ) )) (retract ?id)
Programación Domótica Basada en Sistemas Expertos
157
(assert (fact_rule6_1)) (set-break rule6_1)) (defrule rule6_1 ?id <- (fact_rule6_1) ?id_func_1_12<-(func (idRoom 1) (idFunc 12) (value ?valor_func_1_12)) => ;(printout t "ejecutando asignacion rule6_1" crlf) (retract ?id) (retract ?id_func_1_12) (assert (fact_rule5))) (defrule rule0_showFilename ?id <- (fact_rule0_showFilename) => ;(printout t "ejecutando asignacion - funcion rule0_showFilename" crlf) (assert (request (reason func))) (assert (func (idRoom 1) (idFunc 12) (params "Ejecutando el archivo: " "demo" ) )) (retract ?id) (assert (fact_rule0_showFilename_1)) (set-break rule0_showFilename_1)) (defrule rule0_showFilename_1 ?id <- (fact_rule0_showFilename_1) ?id_func_1_12<-(func (idRoom 1) (idFunc 12) (value ?valor_func_1_12)) => ;(printout t "ejecutando asignacion rule0_showFilename_1" crlf) (retract ?id) (retract ?id_func_1_12) (assert (fact_rule1))) Formato de Mensajes entre Subsistemas del Servidor
Los distintos subsistemas del servidor se comunican, como ya se dijo, vía TCP/IP. Esta
comunicación es mediante mensajes de texto, con campos separados por “;”. La respuesta a
estos mensajes es texto, donde primero figura un “0” si la operación fue exitosa seguido de un
“;” y luego “Éxito” ó “1” seguido de la descripción del error.
• Mensajes a y desde Executer: son tres: mensajes de actualización de
la lista de archivos a ejecutar, mensajes de estado de los sensores y
mensajes para la ejecución de funciones domóticas.
Actualización de lista de archivos: cuando se genera un nuevo
diagrama (y paralelamente programa) o cuando se elimina uno, debe
notificarse de los cambios a Executer para que sepa que archivos
ejecutar. Para ello, el formato de estos mensajes es:
<comando>;<nombre_archivo_clp> donde <comando> es add ó
remove (según se agregue un nuevo diagrama o se elimine uno
Programación Domótica Basada en Sistemas Expertos
158
existente, respectivamente) y <nombre_archivo_clp> es el nombre del
archivo ejecutable (.clp) correspondiente al diagrama
agregado/eliminado.
Estado de sensores: cuando cambia el valor de un sensor de la casa,
HomeState (quien posee comunicación con los mismos) notifica a
Executer de dicho cambio para que éste determine si existe algún
diagrama que deba ser ejecutado como consecuencia de ese cambio.
El formato de estos mensajes es: <sensor>;<estado> donde <sensor>
puede ser alarm, sunrise, sunset o door según los sensores emulados
descritos anteriormente en el trabajo y <estado> es true ó false, según
ese sensor se haya activado o desactivado, respectivamente. Si el
mensaje enviado es getAllSensorsState, recibe como respuesta el
estado de cada sensor, con la siguiente estructura:
<sensor1>,<estado1>;<sensor2>,<estado2>;…<sensor4>,<estado4>
Ejecución de funciones domóticas: cuando se está ejecutando un
programa y se requiere la ejecución de una función, por ejemplo, abrir
portón, Executer notifica a HomeState del pedido usando mensajes
con el siguiente formato:
requestFunctionCall;<idRoom>;<idFunc>(;<valor_param_i>)*
Donde requestFunctionCall es una constante que determina el tipo de
mensaje, <idRoom> representa el ID de Habitación (coincidente al
otorgado en la tabla rooms de la Base de Datos), <valor_param_i>
representa el valor del i‐ésimo parámetro de la función (está entre
paréntesis y con un asterisco indicando que puede haber de 0 a n
parámetros, dependiendo del tipo de función.
Programación Domótica Basada en Sistemas Expertos
159
A.1.4.1.2. Preparación del Entorno de Construcción
Se preparó el entorno de construcción, (con las librerías y bibliotecas utilizadas) el
cual consta de los medios informáticos provistos por el alumno y es el indicado en
2.3.8.1. Especificación del Entorno de Construcción.
A.1.4.2. Generación del Código de los Componentes y
Procedimientos
El objetivo de esta actividad es la codificación de los componentes del sistema de
información, a partir de las especificaciones de construcción obtenidas en el proceso
Diseño del Sistema de Información (DSI).
A.1.4.2.1. Generación del Código de Componentes
En esta tarea se genera el código correspondiente a cada uno de los componentes
del sistema de información, identificados en la tarea Definición de Componentes y
Subsistemas de Construcción (2.3.8.2).
Se generó el código de cada subsistema, en el lenguaje elegido, compilándolo,
verificando y corrigiendo los errores sintácticos, y el enlace del código objeto
obtenido con las correspondientes bibliotecas.
En el CD que acompaña a este informe, se incluye el código fuente del Sistema
generado.
A.1.4.3. Ejecución de las Pruebas Unitarias
En esta actividad se realizarán las pruebas unitarias de cada uno de los componentes
del sistema de información, una vez codificados, con el objeto de comprobar que su
estructura es correcta y que se ajustan a la funcionalidad establecida.
Programación Domótica Basada en Sistemas Expertos
160
A.1.4.3.1. Preparación del Entorno de las Pruebas Unitarias
En esta tarea se prepararán todos los recursos necesarios para realizar las pruebas
unitarias de cada uno de los componentes del sistema de información.
El entorno utilizado para llevar a cabo las pruebas unitarias corresponde al mismo
entorno de desarrollo, con la adición del plug‐in JUnit (versión 3.8.2) para el IDE
Eclipse (en cada proyecto de cada subsistema), el cual permitirá automatizar las
tareas de las pruebas unitarias dentro de dicho IDE. Las pruebas unitarias
consisten en codificar clases que extienden las clases de JUnit y que hacen uso de
las clases que se pretenden probar. En el caso de clases complejas, que contienen
objetos de otras clases, estos últimos son reemplazados por Objetos mock o falsos
para restringir las pruebas a los comportamientos propios de la clase a analizar.
A.1.4.3.2. Realización y Evaluación de las Pruebas Unitarias
El objetivo de esta tarea es comprobar el correcto funcionamiento de los
componentes del sistema de información, codificados en la actividad Generación
del Código de los Componentes y Procedimientos (2.4.2), conforme a las
verificaciones establecidas en el plan de pruebas para el nivel de pruebas unitarias,
en la actividad Especificación Técnica del Plan de Pruebas (2.3.10).
Las pruebas unitarias fueron diseñadas y ejecutadas a medida que se codificaban
las clases, y hasta que no fueran superadas todas las pruebas para esa clase, no se
pasaba a la siguiente. Se adoptó la convención (si la clase a evaluar se llamaba por
ejemplo, Punto), llamar a la clase donde se hace su unit test como PuntoTest y de
agrupar todas las clases de unit test en un paquete llamado test. Se creó un test
suite por subsistema que engloba todos los unit test del mismo y permite acelerar
las pruebas.
Los test suites de cada subsistema fueron ejecutados en forma íntegra por última
vez antes de generar los JARs de Java correspondientes para asegurar que las
pruebas unitarias siguieran siendo satisfactorias.
Programación Domótica Basada en Sistemas Expertos
161
De los cincos subsistemas de 2.2.3. Identificación de Subsistemas de Análisis,
como ya se justificó en 2.3.10.2. Especificación Técnica de los Niveles de Prueba,
sólo los tres subsistemas del lado servidor fueron objeto del unit testing, con los
siguientes resultados finales (justo antes de generar los JARs):
• HomeState (30 clases, 59 tests): 59/59 tests exitosos
• CodeGen (12 clases, 28 tests): 28/28 tests exitosos
• Executer (5 clases, 19 tests): 19/19 test exitosos.
A.1.4.4. Ejecución de las Pruebas de Integración
En las pruebas de integración se verificará si los componentes o subsistemas
interactúan correctamente a través de sus interfaces, tanto internas como externas,
cubren la funcionalidad establecida, y se ajustan a los requisitos especificados en las
verificaciones correspondientes.
Antes de comenzar a describir los resultados de las pruebas de integración, se sugiere
referirse a 2.2.3.2. Integración de Subsistemas de Análisis para tener presente el
diagrama con los subsistemas, sus dependencias y las interfaces que existen entre
ellos. Las pruebas de integración se desarrollarán según lo descrito en 2.2.10.
Especificación del Plan de Pruebas y 2.3.10. Especificación Técnica del Plan de
Pruebas.
A.1.4.4.1. Preparación del Entorno de las Pruebas de
Integración
La preparación del entorno de las pruebas de integración fue breve, debido a que
el mismo es coincidente con el entorno de construcción. Se utilizó el IDE Eclipse
para hacer la depuración necesaria, con sus correspondientes breakpoints y
watches tanto para los subsistemas Servidor (Java) como para los subsistemas
Cliente (Flex).
Programación Domótica Basada en Sistemas Expertos
162
A.1.4.4.2. Realización de las Pruebas de Integración
En esta tarea se verificará el correcto funcionamiento de las interfaces existentes
entre los distintos componentes y subsistemas, conforme a las verificaciones
establecidas para el nivel de pruebas de integración.
Para llevar a cabo estas pruebas, se partirá de la construcción de varios diagramas,
con distintas configuraciones. Los datos generados serán utilizados en las distintas
pruebas de integración.
• Diagrama A: diagrama vacío, sin figuras.
• Diagrama B: diagrama únicamente con una figura comienzo.
• Diagrama C: diagrama con un comienzo, una asignación, una condición y
dos asignaciones consecuentes (una en caso verdadero y otra en caso
falso) y un fin. Ninguna de las figuras posee propiedades.
• Diagrama D: ídem C, pero cada figura tiene propiedades ajustadas
(llamadas a función, comparaciones, variables, etc.)
• Diagrama E: una figura comienzo, seguida de una asignación (con una
función dentro de ella) y una figura fin. La figura comienzo tiene
propiedades ajustadas para que el diagrama se dispare a una hora y día
específico.
• Diagrama F: diagrama que modela un bucle:
I <- 1 MIENTRAS I < 6{
I <- I + 1 DEBUG(“i vale “, I)
} DEBUG(“FIN i vale “, I) FIN
• Diagrama G: diagrama similar a E, pero con activación por un sensor en
lugar de condición temporal (fecha y hora).
Programación Domótica Basada en Sistemas Expertos
163
a. Integración Editor de Diagramas (GraFlow) – Generador de Código
(CodeGen)
Para realizar esta verificación, se siguieron los siguientes pasos:
o Generar un diagrama en GraFlow y se guardó en la Base de Datos
o Recuperar el diagrama almacenado como XML en la Base de Datos
usando phpmyadmin y se generó un archivo de texto XML
(test.xml)
o Validar el XML del diagrama contra su schema correspondiente
(schema_graflow.xsd) con un validador web
(http://www.xmlme.com/Validator.aspx)
o Ejecutar CodeGen, pasando el archivo de diagrama XML como
parámetro, generándose así sus correspondientes archivos de
código CLIPS (test.clp) y de condiciones de disparo del programa
(test.cond)
o Validar el archivo test.cond con su schema (schema_cond.xsd)
o Abrir el archivo test.clp en la consola de CLIPS y verificar que se
pueda cargar satisfactoriamente (implicando que las reglas son
sintácticamente correctas)
b. Integración Generador de Código (CodeGen) y Ejecutor de Código
(Executer)
Para realizar esta verificación, se siguieron los siguientes pasos:
o Remover las marcas de comentarios (“;” en CLIPS) de test.clp de
las sentencias que permiten imprimir en consola que regla se
acaba de ejecutar.
o Cargar y ejecutar test.clp en Executer
o Verificar el orden en que las reglas fueron ejecutados a partir de la
impresión por consola.
c. Integración Ejecutor de Código (Executer) y Emulador de las variables del
hogar, estado de la casa (HomeState)
Programación Domótica Basada en Sistemas Expertos
164
Se siguieron los siguientes pasos:
o Ejecutar test.clp
o Verificar el estado de la casa, conectándose a HomeState vía telnet
al puerto correspondiente y solicitando el registro de eventos
d. Integración HomeState y Simulador
Se siguieron los siguientes pasos:
o Ejecutar test.clp
o Abrir simulador y verificar que los eventos correspondientes
figuren en la lista de registro de eventos. Si el evento generado
tiene una representación visual, verificar que la misma se presente
correctamente.
A.1.4.4.3. Evaluación del Resultado de las Pruebas de
Integración
A continuación, se describirán las observaciones tras la ejecución de cada una de
las pruebas de integración para cada uno de los diagramas.
Diagrama A:
1° Corrida:
En la prueba de integración A (GraFlow‐CodeGen) se detectó que el archivo de
código no se generaba correctamente.
Reporte de Prueba Nro: 1.1 Fecha: 1/7/09
Objetivo: Verificar la integración entre GraFlow‐CodeGen para el caso del
Diagrama A (diagrama vacío)
Errores encontrados:
ID Caso de Prueba Nivel Severidad Descripción DA.A Medio Al almacenarse un
diagrama vacío, el archivo de código (.clp) no se genera correctamente
Programación Domótica Basada en Sistemas Expertos
165
El archivo de diagrama fue validado con el Schema y pasó la prueba.
DA.A Medio Al almacenarse un diagrama vacío, el archivo de condiciones(.cond) no se genera correctamente El archivo de diagrama fue validado con el Schema y pasó la prueba.
Se cree que el error radica dentro del subsistema CodeGen y que está relacionado
con que el mismo espera al menos un bloque de programa en el XML de diagrama.
Pruebas de integración B, C y D no se pudieron completar, debido a que sus
entradas dependían de la salida de la prueba A.
2° Corrida: una vez solucionados los problemas reportados en la primera, se
ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
Diagrama B:
1° Corrida:
Se ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
Diagrama C:
1° Corrida:
Se ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
Diagrama D:
1° Corrida:
Se completaron las propiedades de las figuras del diagrama de flujo
predeterminado de modo que represente al siguiente pseudocódigo:
Programación Domótica Basada en Sistemas Expertos
166
temp <- 23; SI (temp < 25) ENTONCES{ DEBUG(“temp es menor a 25 y vale “, temp); }SINO{ DEBUG(“temp es mayor o igual a 25 y vale “, temp); } FIN
Se ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
1° Corrida (bis):
Se completaron las propiedades de las figuras del diagrama de flujo
predeterminado de modo que represente al siguiente pseudocódigo:
temp <- 26; SI (temp < 25) ENTONCES{ DEBUG(“temp es menor a 25 y vale “, temp); }SINO{ DEBUG(“temp es mayor o igual a 25 y vale “, temp); } FIN
Se ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
Diagrama E:
1° Corrida:
Se completaron las propiedades de las figuras del diagrama de flujo
predeterminado de modo que represente al siguiente pseudocódigo:
Ejecutar los: Martes A las: 17:03
DEBUG(“test “, “diag E”); FIN
Se ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
Programación Domótica Basada en Sistemas Expertos
167
1° Corrida (bis):
Se completaron las propiedades de las figuras del diagrama de flujo
predeterminado de modo que represente al siguiente pseudocódigo:
Ejecutar los: Martes, Miércoles A las: 17:10
DEBUG(“test “, “diag E”); FIN
Se ejecutaron las pruebas de integración A, B, D obteniéndose resultados
satisfactorios. En la prueba C se obtuvo el siguiente error:
Reporte de Prueba Nro: 5.3 Fecha: 7/7/09
Objetivo: Verificar la integración entre Executer‐HomeState para el caso del
Diagrama E
Errores encontrados:
ID Caso de Prueba Nivel Severidad Descripción DE.C Medio Al almacenarse un
diagrama que debe ejecutarse más de una vez por semana, no se termina ejecutando nunca. Si se selecciona como propiedad de comienzo cero o un día a la semana, funciona correctamente
2° Corrida: una vez solucionados los problemas reportados en la primera, se
ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
Programación Domótica Basada en Sistemas Expertos
168
Diagrama F:
1° Corrida:
Se ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
Diagrama G:
1° Corrida:
Se completaron las propiedades de las figuras del diagrama de flujo
predeterminado de modo que represente al siguiente pseudocódigo:
Ejecutar cuando: Alarma
DEBUG(“test “, “diag G”); FIN
Se ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
1° Corrida (bis):
Se completaron las propiedades de las figuras del diagrama de flujo
predeterminado de modo que represente al siguiente pseudocódigo:
Ejecutar cuando: Alarma, Timbre DEBUG(“test “, “diag G”); FIN
Se ejecutaron las pruebas de integración A, B, D obteniéndose resultados
satisfactorios. En la prueba C se obtuvo el siguiente error:
Reporte de Prueba Nro: 7.3 Fecha: 10/7/09
Objetivo: Verificar la integración entre Executer‐HomeState para el caso del
Diagrama E
Errores encontrados:
ID Caso de Prueba Nivel Severidad Descripción DG.C Medio Al almacenarse un
diagrama que debe
Programación Domótica Basada en Sistemas Expertos
169
ejecutarse ante la llegada de la señal de 2 o más sensores, no se termina ejecutando nunca. Si se selecciona como propiedad de comienzo cero o un sensor, funciona correctamente
2° Corrida: una vez solucionados los problemas reportados en la primera, se
ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados
satisfactorios.
A.1.4.5. Ejecución de las Pruebas de Sistema
A.1.4.5.1. Realización de las Pruebas de Sistema
Las pruebas de sistema serán, básicamente una unificación de las pruebas de
integración. Se generarán los diagramas indicados en estas últimas pruebas y se
verificará su correcto funcionamiento en último eslabón de la cadena, es decir, los
diagramas se dibujarán en el Editor de Diagramas (GraFlow) y en el Simulador se
evaluarán los eventos generados. Se verificará que los diagramas puedan ser
reabiertos y editados sin inconvenientes y que se puedan eliminar/activar.
Adicionalmente, en la pruebas de sistema, se comprobará el correcto
funcionamiento de la interfaz de usuario, tanto en GraFlow como en Simulador
(botones, cuadros diálogo, inserción y eliminación de figuras y flechas, etc.).
A.1.4.5.2. Evaluación del Resultado de las Pruebas de Sistema
Se probaron los diagramas A‐G, siguiendo los lineamientos de 2.4.5.2 y se
obtuvieron resultados satisfactorios, salvando dos inconvenientes:
Programación Domótica Basada en Sistemas Expertos
170
1. 1° Corrida
Reporte de Prueba Nro: 8 Fecha: 14/7/09
Objetivo: Prueba de Sistema para Diagrama A
Errores encontrados:
ID Caso de Prueba Nivel Severidad Descripción PS.A Bajo Al almacenarse un
diagrama vacío y luego reabrirse, produce un error
2° Corrida: Se verificó la correcta reparación de los inconvenientes
encontrados en la 1° Corrida.
2. 1° Corrida
Reporte de Prueba Nro: 9 Fecha: 15/7/09
Objetivo: Prueba de Sistema usando Administrar Diagramas
Errores encontrados:
ID Caso de Prueba Nivel Severidad Descripción PS.X Medio Al eliminarse el
diagrama actualmente abierto desde “Administrar diagramas” de GraFlow, se produce un error que se registra en el log de Executer
2° Corrida: Se verificó la correcta reparación de los inconvenientes
encontrados en la 1° Corrida.
Programación Domótica Basada en Sistemas Expertos
171
A.1.4.6. Elaboración de los Manuales de Usuario
A.1.4.6.1. Elaboración de los Manuales de Usuario
El objetivo de esta tarea es elaborar la documentación de usuario, tanto usuario
final como de explotación, de acuerdo a los requisitos establecidos en la tarea
Especificación de Requisitos de Documentación de Usuario (DSI 11.1), y recogidos
en el catálogo de requisitos.
Los manuales de usuario se distribuirán en forma electrónica en dos formatos:
como ayuda HTML, accesible desde un navegador web y como archivos de ayuda
compilada de Microsoft (CHM). Los archivos de ayuda en forma de HTML serán
armados sólo para las herramientas web, es decir, el Editor de Diagramas
(GraFlow) y el Simulador mientras que los cinco subsistemas/herramientas
tendrán sus correspondientes archivos CHM, los cuales el usuario podrá copiar a
su máquina desde el instalador del sistema. La estructura de los archivos de ayuda
será la típica de los archivos CHM, con una jerarquía de árbol, con capítulos y
artículos dentro de los mismos.
A.1.4.7. Definición de la Formación de los Usuarios Finales
En esta actividad se establecerán las necesidades de formación del usuario final, con el
objetivo de conseguir la explotación eficaz del nuevo sistema.
Para la definición de la formación se tendrán en cuenta las características funcionales y
técnicas propias del sistema de información, así como los requisitos relacionados con
la formación del usuario final, establecidos en la tarea Especificación de Requisitos de
Implantación (2.3.11.2).
El presente Trabajo Profesional no tiene como objetivo la puesta en producción del
sistema desarrollado por lo cual el plan de capacitación a los Usuarios Finales no aplica.
Sin embargo, se pueden enumerar una serie de conocimientos necesarios para la
operación del sistema, en el momento de la Defensa del Trabajo y ellos están descritos
en el apartado Requisitos de Formación de 2.3.11.2. Especificación de Requisitos de
Implantación.
Programación Domótica Basada en Sistemas Expertos
172
A.1.4.8. Construcción de los Componentes y Procedimientos de
Migración y Carga Inicial de los Datos
En esta actividad se codificará y probará los componentes y procedimientos de
migración y carga inicial de datos, a partir de las especificaciones recogidas en el Plan
de Migración y Carga Inicial de Datos obtenida en el proceso Diseño del Sistema de
Información.
A.1.4.8.1. Preparación del Entorno de Migración y Carga
Inicial de Datos
A partir de la Base de Datos generada previamente, con las habitaciones,
funciones y parámetros correspondientes, se preparó un script en PHP que
recuperó los datos que fueron insertados cuidadosamente durante el proceso de
codificación y se generó un archivo de texto con los datos iniciales. Este archivo
(data.sql) se utilizará junto a un archivo con las sentencias para la creación de las
tablas (createDB.sql), armado según 2.3.6.1. Diseño del Modelo Físico de Datos.
A.1.4.8.2. Generación del Código de los Componentes y
Procedimientos de Migración y Carga Inicial de Datos
En esta tarea, se generó el código para la carga inicial de los datos. Se decidió que
la forma más eficiente era desarrollando un pequeño programa (InitDB) que leyera
los archivos createDB.sql y data.sql sentencia por sentencia de SQL y las ejecutara.
Este programa fue escrito en Java y se incluye dentro del instalador del sistema. En
el momento de la instalación, el instalador solicita nombre y contraseña para
acceder a la Base de Datos y esos valores son pasados como parámetros para que
el InitDB cargue los datos iniciales. Si InitDB no puede hacerlo, devuelve un código
de error al instalador quien notifica al usuario. La activación de InitDB es
totalmente transparente para el usuario que está intentando instalar el sistema.
Se adjunta en el CD el código fuente de InitDB.
Programación Domótica Basada en Sistemas Expertos
173
A.1.4.8.3. Realización y Evaluación de las Pruebas de
Migración y Carga Inicial de Datos
Se probó a InitDB tanto en forma separada por línea de comandos como ya
integrado con el instalador, en una máquina virtual para hacer una instalación
limpia, y, se comprobó que los datos iniciales cargados eran válidos y completos.
A.1.4.9. Aprobación del Sistema de Información
A.1.4.9.1. Presentación y Aprobación del Sistema de
Información
Los directores del Trabajo Profesional revisaron y aprobaron la Construcción del
Sistema de Información presentado en esta Etapa que figura en el presente
informe.