PROGRAMACIÓN DOMÓTICA BASADA EN SISTEMAS EXPERTOS

 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
Indice 1. RESUMEN ............................................................................................................................... 1 2. INTRODUCCIÓN ..................................................................................................................... 2 2.1. 2.2. COMPONENTES DEL SISTEMA ..................................................................................................... 3 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. 9.2. 9.3. ENCENDER LAS LUCES DEL LIVING A LAS 22:15 HORAS .......................................................... 13 ENCENDER REGADORES DEL PATIO Y ABRIR EL PORTÓN DEL GARAGE .................................. 24 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. A.1.1.2. A.1.1.3. A.1.1.4. A.1.1.5. A.1.1.6. A.1.2. Análisis del Sistema de Información ........................................................................... 63 A.1.2.1. A.1.2.2. A.1.2.3. A.1.2.4. A.1.2.5. A.1.2.6. A.1.2.7. A.1.2.8. A.1.2.9. A.1.2.10. A.1.2.11. A.1.3. Establecimiento del alcance del sistema ............................................................................. 42 Estudio de la Situación Actual ............................................................................................... 45 Definición de los requisitos del sistema ............................................................................... 50 Estudio de Alternativas de Solución ..................................................................................... 52 Valoración de las Alternativas ............................................................................................... 58 Selección de la Solución ........................................................................................................ 61 Definición del Sistema ............................................................................................................ 63 Establecimiento de Requisitos ............................................................................................... 70 Identificación de Subsistemas de Análisis ........................................................................... 75 Análisis de los Casos de Uso ................................................................................................ 80 Análisis de las Clases ............................................................................................................. 82 Elaboración del Modelo de Datos ......................................................................................... 92 Elaboración del Modelo de Procesos ................................................................................... 92 Definición de Interfases de Usuario ...................................................................................... 92 Análisis de Consistencia y Especificación de Requisitos ................................................ 105 Especificación del Plan de Pruebas .................................................................................... 106 Aprobación del Análisis del Sistema de Información ....................................................... 110 Diseño del Sistema de Información .......................................................................... 111 A.1.3.1. A.1.3.2. A.1.3.3. A.1.3.4. Definición de la Arquitectura del Sistema .......................................................................... 111 Diseño de la Arquitectura de Soporte ................................................................................. 116 Diseño de los Casos de Uso Reales .................................................................................. 116 Diseño de Clases................................................................................................................... 117 i Programación Domótica Basada en Sistemas Expertos
A.1.3.5. A.1.3.6. A.1.3.7. A.1.3.8. A.1.3.9. A.1.3.10. A.1.3.11. A.1.3.12. A.1.4. Diseño de la Arquitectura de Módulos del Sistema .......................................................... 126 Diseño Físico de Datos ......................................................................................................... 126 Verificación y Aceptación de la Arquitectura del Sistema ................................................ 131 Generación de las Especificaciones de Construcción ..................................................... 132 Diseño de la Migración ......................................................................................................... 134 Especificación Técnica del Plan de Pruebas ..................................................................... 135 Establecimiento de Requisitos de Implantación ................................................................ 137 Aprobación del Diseño del Sistema de Información ......................................................... 139 Construcción del Sistema de Información ............................................................... 140 A.1.4.1. A.1.4.2. A.1.4.3. A.1.4.4. A.1.4.5. A.1.4.6. A.1.4.7. A.1.4.8. los Datos A.1.4.9. Preparación del Entorno de Generación y Construcción ................................................. 140 Generación del Código de los Componentes y Procedimientos .................................... 159 Ejecución de las Pruebas Unitarias .................................................................................... 159 Ejecución de las Pruebas de Integración ........................................................................... 161 Ejecución de las Pruebas de Sistema ................................................................................ 169 Elaboración de los Manuales de Usuario ........................................................................... 171 Definición de la Formación de los Usuarios Finales ......................................................... 171 Construcción de los Componentes y Procedimientos de Migración y Carga Inicial de
172 Aprobación del Sistema de Información ............................................................................. 173 ii Programación Domótica Basada en Sistemas Expertos
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. 1 Programación Domótica Basada en Sistemas Expertos
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 2 Programación Domótica Basada en Sistemas Expertos
•
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. 3 Programación Domótica Basada en Sistemas Expertos
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. 4 Programación Domótica Basada en Sistemas Expertos
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 5 Programación Domótica Basada en Sistemas Expertos
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). 6 Programación Domótica Basada en Sistemas Expertos
6.1.Tabla comparativa Arquitectura X10 HEYU Distribuida Centralizada (instalación individual de equipos) HCS ExDomus Centralizado o Centralizada Distribuido, si se dispone de pocos dispositivos a automatizar Medio Baja. Requiere Media experiencia en entornos UNIX (manejo de Shell scripting y compilación a partir del código fuente) Baja. Alta Media‐Alta Facilidad de Alta (con sólo instalación conectar los equipos a la red eléctrica y asignarles un código único salen funcionando) A Facilidad de Media. uso través de múltiples controles remotos Método de Controles No posee control remotos X10 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 Control No disponible No disponible Vía telefónica, forma celulares o, remoto (fuera sin software en del hogar) adicional nativa con software adicional, vía Internet Alto Facilidad de Alta Media. programación Requiere generar scripts Poder de Bajo (muy Medio‐Alto Alto programación básico) Temporización Sólo utilizando Sí de acciones equipos adicionales Registro de No disponible Sí eventos sin software adicional Si Si Se utiliza un control remoto que se comunica con una PC con Windows Media Center No disponible Media Media (se pueden generar secuencias de acciones desde la interfaz gráfica) Si (en las versiones pagas del software) No disponible 7 Programación Domótica Basada en Sistemas Expertos
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) 8 Programación Domótica Basada en Sistemas Expertos
8. Solución Propuesta La solución propuesta consta de las siguientes partes: 9 Programación Domótica Basada en Sistemas Expertos
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). 10 Programación Domótica Basada en Sistemas Expertos
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 11 Programación Domótica Basada en Sistemas Expertos
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. 12 Programación Domótica Basada en Sistemas Expertos
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 13 Programación Domótica Basada en Sistemas Expertos
3. Mover la figura hasta la ubicación deseada (Mantener botón izquierdo apretado sobre la figura, mover y luego soltar el botón) 14 Programación Domótica Basada en Sistemas Expertos
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 15 Programación Domótica Basada en Sistemas Expertos
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” 16 Programación Domótica Basada en Sistemas Expertos
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” 17 Programación Domótica Basada en Sistemas Expertos
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” 18 Programación Domótica Basada en Sistemas Expertos
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 19 Programación Domótica Basada en Sistemas Expertos
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. 20 Programación Domótica Basada en Sistemas Expertos
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. 21 Programación Domótica Basada en Sistemas Expertos
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. 22 Programación Domótica Basada en Sistemas Expertos
23. A la hora indicada, se verifica que la ejecución del programa fue exitosa. 23 Programación Domótica Basada en Sistemas Expertos
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. 24 Programación Domótica Basada en Sistemas Expertos
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. 25 Programación Domótica Basada en Sistemas Expertos
6. Unir a la segunda Asignación con la figura Fin. 26 Programación Domótica Basada en Sistemas Expertos
7. Configurar a la primera Asignación. 8. Seleccionar “función”. 9. Fijar los regadores del patio a intensidad 4, Aceptar y Aceptar nuevamente. 27 Programación Domótica Basada en Sistemas Expertos
10. Configurar a la primera Asignación y elegir “función”. 11. Seleccionar “Garage” y “abrirPorton” y luego Aceptar dos veces. 28 Programación Domótica Basada en Sistemas Expertos
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 29 Programación Domótica Basada en Sistemas Expertos
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 30 Programación Domótica Basada en Sistemas Expertos
3. Insertar una figura Fin 31 Programación Domótica Basada en Sistemas Expertos
4. Insertar una figura Condición 5. Unir las figuras como se muestra en la siguiente imagen 32 Programación Domótica Basada en Sistemas Expertos
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” 33 Programación Domótica Basada en Sistemas Expertos
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: 34 Programación Domótica Basada en Sistemas Expertos
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. 35 Programación Domótica Basada en Sistemas Expertos
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” 36 Programación Domótica Basada en Sistemas Expertos
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. 37 Programación Domótica Basada en Sistemas Expertos
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. 38 Programación Domótica Basada en Sistemas Expertos
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) 39 Programación Domótica Basada en Sistemas Expertos
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. 40 Programación Domótica Basada en Sistemas Expertos
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) 41 Programación Domótica Basada en Sistemas Expertos
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 42 Programación Domótica Basada en Sistemas Expertos
encargado de actuar sobre los equipos según las condiciones sensadas en las variables del ambiente. •
ID Catálogo de Objetivos EVS Autor Tipo Descripción Estado APROB. ESTRATÉGICO Presentar un Trabajo Profesional de Calidad en Tiempo y Forma OBJ2 FRIAS, ESTRATEGICO Desarrollar APROB. G. un Sistema de Control Domótico OBJ3 Merlino, ESTRATEGICO Seguir una APROB. H. Metodología Conocida y Eficaz OBJ1 FRIAS, G. •
ID Fecha Prioridad de creación ALTA 1/8/08 ALTA 1/8/08 ALTA 1/8/08 Prioridad Fecha
de creación Catálogo de Requisitos Autor Tipo REQ1 Merlino, DOCUMENT
H. AC REQ2 FRIAS, G. NO FUNCIONAL REQ3 FRIAS, G. NO FUNCIONAL REQ4 FRIAS, G. FUNCIONAL REQ5 FRIAS, G. FUNCIONAL REQ6 FRIAS, G. FUNCIONAL Descripción Usar Métrica 3 como Metodología de Desarrollo Capacidad de programar el Sistema desde una ubicación remota Facilidad de uso, programació
n de modo gráfico Generar un registro de eventos Temporizació
n de Acciones Activación de programas Estado INCORP. ALTA 1/8/08 APROB. ALTA 1/8/08 APROB. ALTA 1/8/08 APROB. BAJA 20/8/08
APROB. MEDIA 17/8/08
APROB. MEDIA 20/8/08
43 Programación Domótica Basada en Sistemas Expertos
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. 44 Programación Domótica Basada en Sistemas Expertos
o
Estructura Organizativa ID EO1 EO2 EO3 EO4 A.1.1.2.
Apellido y Nombre Merlino, Hernán García‐Martínez, Ramón Fernández, Enrique Frías, Guillermo Rol Director del Trabajo Profesional Director del Trabajo Profesional Consultor en Métrica 3 Analista / Programador / Tester 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 45 Programación Domótica Basada en Sistemas Expertos
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 46 Programación Domótica Basada en Sistemas Expertos
(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). 47 Programación Domótica Basada en Sistemas Expertos
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: 48 Programación Domótica Basada en Sistemas Expertos
Arquitectura X10 HEYU Centralizada Distribuida (instalación individual de equipos) HCS ExDomus Centralizado o Centralizada Distribuido, si se dispone de pocos dispositivos a automatizar Medio Baja. Requiere Media experiencia en entornos UNIX (manejo de Shell scripting y compilación a partir del código fuente) Baja. Alta Media‐Alta Facilidad de Alta (con sólo instalación conectar los equipos a la red eléctrica y asignarles un código único salen funcionando) Facilidad de Media. A uso través de múltiples controles remotos Método de Controles No posee control remotos X10 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 Control No disponible No disponible Vía telefónica, remoto (fuera sin software en forma celulares o, del hogar) adicional nativa con software adicional, vía Internet Alto Facilidad de Alta Media. programación Requiere generar scripts Poder de Bajo (muy Medio‐Alto Alto programación básico) Temporización Sólo utilizando Sí de acciones equipos adicionales Registro de No disponible Sí eventos sin software adicional Si Si Se utiliza un control remoto que se comunica con una PC con Windows Media Center No disponible Media Media (se pueden generar secuencias de acciones desde la interfaz gráfica) Si (en las versiones pagas del software) No disponible 49 Programación Domótica Basada en Sistemas Expertos
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 DTG1 Merlino, H. Gestión DTG2 García‐
Martínez, R. Gestión DTG3 Frías, G. Técnica ALTA Uso de Métrica 3 como Metodología a seguir Desarrollo de ALTA una Memoria del Trabajo Utilización ALTA Estado Fecha de creación APROBADA 1/8/08 APROBADA 1/8/08 APROBADA 1/8/08 50 Programación Domótica Basada en Sistemas Expertos
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.
ID Autor REQ1 FRIAS, G. REQ2 FRIAS, G. REQ3 FRIAS, G. REQ4 FRIAS, G. REQ5 FRIAS, G. Catalogación de los Requisitos Tipo Descripción Arquitectura Sistema de control domótico centralizado No Facilidad de Funcional instalación No Facilidad de Funcional uso Funcional Interfaz gráfica como modo de control Funcional Visualización y control tanto local como remoto Prioridad Estado ALTA Fecha de creación APROBADO 1/8/08 MEDIA APROBADO 21/8/08 ALTA APROBADO 10/8/08 MEDIA APROBADO 1/8/08 ALTA APROBADO 1/8/08 51 Programación Domótica Basada en Sistemas Expertos
REQ6 FRIAS, G. Funcional REQ7 FRIAS, G. Funcional REQ8 FRIAS, G. REQ9 FRIAS, G. Funcional A.1.1.4.
Funcional (vía Internet) Simplicidad de programación
Capacidad de temporizar acciones Registro de eventos Activación de programas por la llegada de señales externas ALTA APROBADO 1/8/08 MEDIA APROBADO 17/8/08 BAJA APROBADO 20/8/08 MEDIA APROBADO 20/8/08 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 52 Programación Domótica Basada en Sistemas Expertos
•
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 53 Programación Domótica Basada en Sistemas Expertos
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. 54 Programación Domótica Basada en Sistemas Expertos
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) 55 Programación Domótica Basada en Sistemas Expertos
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. 56 Programación Domótica Basada en Sistemas Expertos
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. 57 Programación Domótica Basada en Sistemas Expertos
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 RIE.A.1 FRIAS, G. RIE.A.2 FRIAS, G. Descripción Gravedad Justificación Incertidumbre acerca de Media Los programas de la facilidad de uso línea de comandos requieren mayor tiempo de entrenamiento Dificultad en la Alta Las comunicaciones implantación de control entre el lado remoto y desde ubicación remota 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 58 Programación Domótica Basada en Sistemas Expertos
RIE.A.3 FRIAS, G. Complejidad de comunicación entre distintos subsistemas dentro de un mismo programa Alta RIE.A.4 FRIAS, G. Complejidad de instalación remota Media existencia de un solo programa implica que este debe comunicarse con los dispositivos de la casa de forma directa, complicando el desarrollo. Los distintos subsistemas que realizan tareas muy diferentes tienen un grado de acoplamiento muy alto ya que todos forman parte de un único programa 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 RIE.B.1 FRIAS, G. RIE.B.2 FRIAS, G. Descripción Gravedad Justificación Las comunicaciones entre el lado Dificultad en la Alta remoto y el hogar deben implantación efectuarse abriendo puertos de control específicos o con comunicación desde entre procesos remotos. Los ubicación firewalls que cada lugar posee se remota 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. Alta Los distintos subsistemas que Complejidad realizan tareas muy diferentes de tienen un grado de acoplamiento comunicación muy alto ya que todos forman entre distintos parte de un único programa subsistemas dentro de un mismo 59 Programación Domótica Basada en Sistemas Expertos
RIE.B.3 FRIAS, G. programa 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 RIE.C.1 FRIAS, G. Descripción Dificultad en la implantación de control desde ubicación remota RIE.C.2 FRIAS, G. Complejidad de instalación remota Gravedad Justificación 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. 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 RIE.D.1 FRIAS, G. Descripción Dificultad en la implantación de control desde ubicación remota Gravedad Justificación 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. 60 Programación Domótica Basada en Sistemas Expertos
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 61 Programación Domótica Basada en Sistemas Expertos
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. 62 Programación Domótica Basada en Sistemas Expertos
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: 63 Programación Domótica Basada en Sistemas Expertos
•
Glosario de términos ID T1 Término Controlador T2 Sensor T3 Actuador T4 Diagrama T5 Programa T6 T7 Traductor Simulador o Emulador de variables del hogar T8 Bloque Descripción 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 Dispositivo que mide una cantidad física y la convierte en una señal eléctrica que puede ser leída por el controlador Componente que se encarga de transformar una señal eléctrica en una acción, generalmente mecánica sobre otro elemento físico 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 Conjunto de instrucciones listas para ser ejecutadas Convierte un diagrama en un programa Permite visualizar las acciones tomadas por actuadores que se activaron y forzar la activación de algún sensor para emular su habilitación Elemento gráfico que constituye un Diagrama y que representa una acción a tomar, un condición, etc. 64 Programación Domótica Basada en Sistemas Expertos
•
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”. 65 Programación Domótica Basada en Sistemas Expertos
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. 66 Programación Domótica Basada en Sistemas Expertos
•
Modelo de Dominio 67 Programación Domótica Basada en Sistemas Expertos
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 68 Programación Domótica Basada en Sistemas Expertos
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. 69 Programación Domótica Basada en Sistemas Expertos
•
Catálogo de usuarios Se definirán las responsabilidades de los usuarios ya detectados en el EVS ID U1 U3 Rol Director del Trabajo Profesional García‐Martínez, Ramón Director del Trabajo Profesional Fernández, Enrique Consultor en Métrica 3 U4 Frías, Guillermo U2 Apellido y Nombre Merlino, Hernán A.1.2.2.
Responsabilidades • Dirección teórica y práctica • Dirección teórica y práctica • Consultoría referente al seguimiento de la metodología de desarrollo Analista / Programador • Desarrollo / Tester • Documentación • Pruebas 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. 70 Programación Domótica Basada en Sistemas Expertos
ID Autor Tipo REQ1 FRIAS, G. REQ2 FRIAS, G. FRIAS, G. FRIAS, G. Arquitectura Sistema de control domótico centralizado No Facilidad de Funcional instalación Funcional Facilidad de uso Funcional Interfaz gráfica como modo de control Funcional Visualización y control tanto local como remoto (vía Internet) Funcional Simplicidad de programación Funcional Capacidad de temporizar acciones Funcional Registro de eventos Funcional Activación de programas por la llegada de señales externas Rendimiento El lado servidor debe poder ejecutarse en una PC hogareña de acuerdo a las características de ASI 1.2 Rendimiento El lado cliente debe poder ejecutarse en un navegador web de acuerdo a las características de ASI 1.2 REQ3 REQ4 REQ5 FRIAS, G. REQ6 FRIAS, G. REQ7 FRIAS, G. REQ8 FRIAS, G. FRIAS, G. REQ9 REQ10 FRIAS, G. REQ11 FRIAS, G Descripción Prioridad Estado ALTA Fecha de creación APROBADO 1/8/08 MEDIA APROBADO 21/8/08 ALTA APROBADO 10/8/08 MEDIA APROBADO 1/8/08 ALTA APROBADO 1/8/08 ALTA APROBADO 1/8/08 MEDIA APROBADO 17/8/08 BAJA APROBADO 20/8/08 MEDIA APROBADO 20/8/08 ALTA APROBADO 29/8/08 MEDIA APROBADO 29/8/08 71 Programación Domótica Basada en Sistemas Expertos
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. 72 Programación Domótica Basada en Sistemas Expertos
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: ‐ 73 Programación Domótica Basada en Sistemas Expertos
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: ‐ 74 Programación Domótica Basada en Sistemas Expertos
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. 75 Programación Domótica Basada en Sistemas Expertos
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. 76 Programación Domótica Basada en Sistemas Expertos
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 77 Programación Domótica Basada en Sistemas Expertos
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. 78 Programación Domótica Basada en Sistemas Expertos
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. 79 Programación Domótica Basada en Sistemas Expertos
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 Diagrama Figura Programa Bloque HomeState Home Caso(s) de Uso Asociado(s) Crear Diagrama, Editar Diagrama, Guardar Diagrama, Administrar Diagramas, Eliminar Diagrama, Habilitar Diagrama Crear Diagrama, Editar Diagrama, Guardar Diagrama, Eliminar Diagrama Crear Diagrama, Editar Diagrama, Guardar Diagrama, Generar Programa, Administrar Diagramas, Eliminar Diagrama, Habilitar Diagrama Crear Diagrama, Editar Diagrama, Guardar Diagrama, Generar Programa, Eliminar Diagrama Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor Subsistema(s) asociado(s) Editor de Diagramas Editor de Diagramas Editor de Diagramas, Generador de Código Editor de Diagramas, Generador de Código Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Simulador y 80 Programación Domótica Basada en Sistemas Expertos
Room Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor Function Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor Log Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor LogEntry Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor Sensor Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor Expression Param CodeGen Executer Generar Programa Generar Programa Generar Programa Probar diagrama, Ejecutar Programa, Administrar Programas, Simular Cambios en Sensor Ejecutar Programa, Administrar Programas, Simular Cambios en Sensor Probar diagrama, Ejecutar Programa Dispatcher CodeSupervisor SensorSystem Simular Cambios en Sensor WatchDog Probar diagrama, Ejecutar Programa Probar diagrama, Ejecutar Programa RemoteFunction MotorInferencias FileConditions Probar diagrama, Ejecutar Programa Probar Diagrama, Ejecutar visualizador de eventos; Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código Generador de Código Generador de Código Generador de Código Emulador de las variables del hogar, estado de la casa; Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Ejecutor de Código Ejecutor de Código Emulador de las variables del hogar, estado de la casa; Ejecutor de Código Ejecutor de Código Ejecutor de Código 81 Programación Domótica Basada en Sistemas Expertos
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 82 Programación Domótica Basada en Sistemas Expertos
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: 83 Programación Domótica Basada en Sistemas Expertos
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. 84 Programación Domótica Basada en Sistemas Expertos
Generador de Código 85 Programación Domótica Basada en Sistemas Expertos
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. 86 Programación Domótica Basada en Sistemas Expertos
Ejecutor de Código 87 Programación Domótica Basada en Sistemas Expertos
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. 88 Programación Domótica Basada en Sistemas Expertos
Emulador de las variables del hogar, estado de la casa 89 Programación Domótica Basada en Sistemas Expertos
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. 90 Programación Domótica Basada en Sistemas Expertos
Simulador y visualizador de eventos 91 Programación Domótica Basada en Sistemas Expertos
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. 92 Programación Domótica Basada en Sistemas Expertos
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. 93 Programación Domótica Basada en Sistemas Expertos
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). 94 Programación Domótica Basada en Sistemas Expertos
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. 95 Programación Domótica Basada en Sistemas Expertos
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. 96 Programación Domótica Basada en Sistemas Expertos
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. 97 Programación Domótica Basada en Sistemas Expertos
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. 98 Programación Domótica Basada en Sistemas Expertos
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. 99 Programación Domótica Basada en Sistemas Expertos
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. 100 Programación Domótica Basada en Sistemas Expertos
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). 101 Programación Domótica Basada en Sistemas Expertos
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. 102 Programación Domótica Basada en Sistemas Expertos
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. 103 Programación Domótica Basada en Sistemas Expertos
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. 104 Programación Domótica Basada en Sistemas Expertos
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. 105 Programación Domótica Basada en Sistemas Expertos
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. 106 Programación Domótica Basada en Sistemas Expertos
•
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 107 Programación Domótica Basada en Sistemas Expertos
•
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 108 Programación Domótica Basada en Sistemas Expertos
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 109 Programación Domótica Basada en Sistemas Expertos
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. 110 Programación Domótica Basada en Sistemas Expertos
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. 111 Programación Domótica Basada en Sistemas Expertos
112 Programación Domótica Basada en Sistemas Expertos
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 113 Programación Domótica Basada en Sistemas Expertos
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 114 Programación Domótica Basada en Sistemas Expertos
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. 115 Programación Domótica Basada en Sistemas Expertos
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. 116 Programación Domótica Basada en Sistemas Expertos
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 117 Programación Domótica Basada en Sistemas Expertos
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 BuilderDiagrama BuilderPrograma BuilderMapper DraggableImage ICaminoFlecha Punto Línea Rectángulo OpenDlg SaveDlg ManagerDlg IBuilderHome, BuildSimulatedHome IBuilderExpression, BuilderExpression IBuilderProgram, BuilderProgramCLIPS IFactoryExpression, FactoryExpression IFactoryProgram, FactoryProgramCLIPS BuilderDispatcher BuilderFileConditions BuilderSensorSystem Caso(s) de Uso Asociado(s) CrearDiagrama, Editar Diagrama CrearDiagrama, Editar Diagrama CrearDiagrama, Editar Diagrama Editar Diagrama Editar Diagrama Editar Diagrama Editar Diagrama Editar Diagrama Editar Diagrama Guardar Diagrama Administrar Diagramas Ejecutar Programa, VisualizarEstado, Simular Cambio en Sensor Generar Programa Subsistema(s) asociado(s) Editor de Diagramas Editor de Diagramas Editor de Diagramas Editor de Diagramas Editor de Diagramas Editor de Diagramas Editor de Diagramas Editor de Diagramas Editor de Diagramas Editor de Diagramas Editor de Diagramas Emulador de las variables del hogar, estado de la casa Generador de Código Generar Programa Generador de Código Generar Programa Generador de Código Generar Programa Generador de Código Administrar Programas Administrar Programas Administrar Programas Ejecutor de Código Ejecutor de Código Ejecutor de Código 118 Programación Domótica Basada en Sistemas Expertos
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. 119 Programación Domótica Basada en Sistemas Expertos
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. 120 Programación Domótica Basada en Sistemas Expertos
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 121 Programación Domótica Basada en Sistemas Expertos
Emulador de las variables del hogar, estado de la casa 122 Programación Domótica Basada en Sistemas Expertos
Generador de Código 123 Programación Domótica Basada en Sistemas Expertos
Ejecutor de Código 124 Programación Domótica Basada en Sistemas Expertos
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 125 Programación Domótica Basada en Sistemas Expertos
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 126 Programación Domótica Basada en Sistemas Expertos
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). 127 Programación Domótica Basada en Sistemas Expertos
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
VARCHAR(50)) ENGINE=InnoDB;
NOT
NULL
PRIMARY
KEY
,
name
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. 128 Programación Domótica Basada en Sistemas Expertos
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. 129 Programación Domótica Basada en Sistemas Expertos
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). 130 Programación Domótica Basada en Sistemas Expertos
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. 131 Programación Domótica Basada en Sistemas Expertos
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 132 Programación Domótica Basada en Sistemas Expertos
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. 133 Programación Domótica Basada en Sistemas Expertos
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. 134 Programación Domótica Basada en Sistemas Expertos
•
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. 135 Programación Domótica Basada en Sistemas Expertos
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. 136 Programación Domótica Basada en Sistemas Expertos
•
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. 137 Programación Domótica Basada en Sistemas Expertos
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). 138 Programación Domótica Basada en Sistemas Expertos
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. 139 Programación Domótica Basada en Sistemas Expertos
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. 140 Programación Domótica Basada en Sistemas Expertos
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
REFERENCES
CASCADE,
rooms_functions
rooms(id)
ON
id_function
functions(id)
ON
(id_room
UPDATE
INT
UPDATE
CASCADE
NOT
CASCADE
INT
NULL
ON
NOT
ON
NULL
DELETE
REFERENCES
DELETE
CASCADE,
PRIMARY KEY(id_room, id_function)) ENGINE=InnoDB;
CREATE TABLE functions_parameters (id_function INT NOT
NULL
DELETE
REFERENCES
CASCADE,
parameters(id)
functions(id)
id_parameter
ON
UPDATE
ON
INT
CASCADE
UPDATE
NOT
ON
NULL
CASCADE
ON
REFERENCES
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. 141 Programación Domótica Basada en Sistemas Expertos
A continuación se detallarán cada una de estas funciones: Nombre de la función luz Descripción Ajusta la intensidad de la luz de una habitación Parámetro(s) Intensidad (entero 0..10) fijarTemperatura Fija la temperatura de la Valor (entero 20..30) habitación seleccionada Envía un mensaje • Nro (entero) de texto mensaje • Mensaje a un número de (texto) teléfono nro regadores Activa los regadores con la Intensidad (entero 0..10) intensidad especificada activarAlarma Dispara la alarma ‐ de la vivienda incrementar Incrementa en 1 el valor del Valor (entero) parámetro valor suma • Sumando1 Suma dos valores • Sumando2 (enteros) abrirPorton Abre el portón ‐ del Garage cerrarPorton Cierra el portón ‐ del Garage obtTemperatura Devuelve la temperatura en grados ‐ centígrados de la habitación seleccionada encenderMi
• cantSegundo
croondas s (entero): cantidad de Activa el horno a segundos de microondas con cocción la intensidad y durante el tiempo • intensidad determinado (entero 0..10): intensidad Disponible en: Living Cocina Comedor Baño Dormitorio Garage Living Cocina Comedor Baño Dormitorio Garage Devuelve ‐ ‐ enviarSMS General ‐ Patio ‐ General ‐ General General Valor incrementa
do en 1 Sumando1 + Sumando2 Garage ‐ Garage ‐ Living Cocina Comedor Baño Dormitorio Garage Temperatu
ra de la habitación en °C Cocina ‐ 142 Programación Domótica Basada en Sistemas Expertos
de cocción Despliega un mensaje (paramDebug1 • paramDebug
concatenado con 1 (texto) paramDebug2) en • paramDebug
la consola de 2 (texto) eventos del simulador • Minuendo (entero) Resta dos valores • Sustraendo (entero) debug resta General ‐ General Minuendo ‐ Sustraendo General • Cero si valor es distinto de 0 • Uno si valor es igual a 0 Living ‐ NOT Niega a valor grabarTV Valor (entero) Graba el canal de • Canal (entero) TV especificado durante la • DuracionMin cantidad de (duración de minutos la grabación solicitada en minutos 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: 143 Programación Domótica Basada en Sistemas Expertos
<?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>
144 Programación Domótica Basada en Sistemas Expertos
</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 145 Programación Domótica Basada en Sistemas Expertos
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>
146 Programación Domótica Basada en Sistemas Expertos
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>
147 Programación Domótica Basada en Sistemas Expertos
<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> 148 Programación Domótica Basada en Sistemas Expertos
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>
149 Programación Domótica Basada en Sistemas Expertos
<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 150 Programación Domótica Basada en Sistemas Expertos
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>
151 Programación Domótica Basada en Sistemas Expertos
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. 152 Programación Domótica Basada en Sistemas Expertos
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. 153 Programación Domótica Basada en Sistemas Expertos
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 154 Programación Domótica Basada en Sistemas Expertos
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 "")
155 Programación Domótica Basada en Sistemas Expertos
(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)
) ))
156 Programación Domótica Basada en Sistemas Expertos
(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 157 Programación Domótica Basada en Sistemas Expertos
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. 158 Programación Domótica Basada en Sistemas Expertos
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. 159 Programación Domótica Basada en Sistemas Expertos
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. 160 Programación Domótica Basada en Sistemas Expertos
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): A.1.4.4.
•
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. 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). 161 Programación Domótica Basada en Sistemas Expertos
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). 162 Programación Domótica Basada en Sistemas Expertos
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) 163 Programación Domótica Basada en Sistemas Expertos
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 DA.A Nivel Severidad Medio Descripción Al almacenarse un diagrama vacío, el archivo de código (.clp) no se genera correctamente 164 Programación Domótica Basada en Sistemas Expertos
DA.A Medio El archivo de diagrama fue validado con el Schema y pasó la prueba. 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: 165 Programación Domótica Basada en Sistemas Expertos
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. 166 Programación Domótica Basada en Sistemas Expertos
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 DE.C Nivel Severidad Medio Descripción 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. 167 Programación Domótica Basada en Sistemas Expertos
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 DG.C Nivel Severidad Medio Descripción Al almacenarse un diagrama que debe 168 Programación Domótica Basada en Sistemas Expertos
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: 169 Programación Domótica Basada en Sistemas Expertos
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 PS.A Nivel Severidad Bajo Descripción 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 PS.X Nivel Severidad Medio Descripción 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. 170 Programación Domótica Basada en Sistemas Expertos
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. 171 Programación Domótica Basada en Sistemas Expertos
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. 172 Programación Domótica Basada en Sistemas Expertos
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. 173