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

i

Indice

1. RESUMEN ............................................................................................................................... 1

2. INTRODUCCIÓN ..................................................................................................................... 2

2.1. COMPONENTES DEL SISTEMA ..................................................................................................... 3 2.2. TIPOS DE ARQUITECTURA ........................................................................................................... 3

3. PRESENTACIÓN DEL PROBLEMA ...................................................................................... 4

4. OBJETIVO DEL TRABAJO PROFESIONAL ........................................................................ 4

5. ÁREA DE APLICACIÓN ......................................................................................................... 4

6. PRODUCTOS EXISTENTES EN EL MERCADO .................................................................. 5

6.1. TABLA COMPARATIVA .................................................................................................................. 7

7. REQUISITOS DEL SISTEMA ................................................................................................. 8

8. SOLUCIÓN PROPUESTA ...................................................................................................... 9

9. CASOS DE VALIDACIÓN ..................................................................................................... 13

9.1. ENCENDER LAS LUCES DEL LIVING A LAS 22:15 HORAS .......................................................... 13 9.2. ENCENDER REGADORES DEL PATIO Y ABRIR EL PORTÓN DEL GARAGE .................................. 24 9.3. REDUCIR LA TEMPERATURA DEL DORMITORIO EN 2°C SI LA MISMA SUPERA LOS 23°C ......... 30

10. CONCLUSIÓN .................................................................................................................... 40

11. REFERENCIAS .................................................................................................................. 41

A. METODOLOGÍA ..................................................................................................................... 42

A.1. DESARROLLO DE SISTEMAS DE INFORMACIÓN ........................................................................ 42 A.1.1. Estudio de Viabilidad del Sistema (EVS) ................................................................... 42

A.1.1.1. Establecimiento del alcance del sistema ............................................................................. 42 A.1.1.2. Estudio de la Situación Actual ............................................................................................... 45 A.1.1.3. Definición de los requisitos del sistema ............................................................................... 50 A.1.1.4. Estudio de Alternativas de Solución ..................................................................................... 52 A.1.1.5. Valoración de las Alternativas ............................................................................................... 58 A.1.1.6. Selección de la Solución ........................................................................................................ 61

A.1.2. Análisis del Sistema de Información ........................................................................... 63 A.1.2.1. Definición del Sistema ............................................................................................................ 63 A.1.2.2. Establecimiento de Requisitos ............................................................................................... 70 A.1.2.3. Identificación de Subsistemas de Análisis ........................................................................... 75 A.1.2.4. Análisis de los Casos de Uso ................................................................................................ 80 A.1.2.5. Análisis de las Clases ............................................................................................................. 82 A.1.2.6. Elaboración del Modelo de Datos ......................................................................................... 92 A.1.2.7. Elaboración del Modelo de Procesos ................................................................................... 92 A.1.2.8. Definición de Interfases de Usuario ...................................................................................... 92 A.1.2.9. Análisis de Consistencia y Especificación de Requisitos ................................................ 105 A.1.2.10. Especificación del Plan de Pruebas .................................................................................... 106 A.1.2.11. Aprobación del Análisis del Sistema de Información ....................................................... 110

A.1.3. Diseño del Sistema de Información .......................................................................... 111 A.1.3.1. Definición de la Arquitectura del Sistema .......................................................................... 111 A.1.3.2. Diseño de la Arquitectura de Soporte ................................................................................. 116 A.1.3.3. Diseño de los Casos de Uso Reales .................................................................................. 116 A.1.3.4. Diseño de Clases................................................................................................................... 117


ii

A.1.3.5. Diseño de la Arquitectura de Módulos del Sistema .......................................................... 126 A.1.3.6. Diseño Físico de Datos ......................................................................................................... 126 A.1.3.7. Verificación y Aceptación de la Arquitectura del Sistema ................................................ 131 A.1.3.8. Generación de las Especificaciones de Construcción ..................................................... 132 A.1.3.9. Diseño de la Migración ......................................................................................................... 134 A.1.3.10. Especificación Técnica del Plan de Pruebas ..................................................................... 135 A.1.3.11. Establecimiento de Requisitos de Implantación ................................................................ 137 A.1.3.12. Aprobación del Diseño del Sistema de Información ......................................................... 139

A.1.4. Construcción del Sistema de Información ............................................................... 140 A.1.4.1. Preparación del Entorno de Generación y Construcción ................................................. 140 A.1.4.2. Generación del Código de los Componentes y Procedimientos .................................... 159 A.1.4.3. Ejecución de las Pruebas Unitarias .................................................................................... 159 A.1.4.4. Ejecución de las Pruebas de Integración ........................................................................... 161 A.1.4.5. Ejecución de las Pruebas de Sistema ................................................................................ 169 A.1.4.6. Elaboración de los Manuales de Usuario ........................................................................... 171 A.1.4.7. Definición de la Formación de los Usuarios Finales ......................................................... 171 A.1.4.8. Construcción de los Componentes y Procedimientos de Migración y Carga Inicial de los Datos 172 A.1.4.9. Aprobación del Sistema de Información ............................................................................. 173


1

1. Resumen

Los actuales soluciones para la programación de los sistemas de hogar (domóticos) existentes

en el mercado tienden a mejorar la calidad de vida de los habitantes de una vivienda,

proveyendo comodidades para la activación o ajuste de dispositivos a través de controles

remotos que requieren de la acción de un individuo.

Dichas soluciones, sin embargo, se tornan demasiado complejas para el usuario promedio si se

intenta que el grado de automatización involucre a varios dispositivos, siendo necesarios

conocimientos técnicos en sistemas electrónicos y/o de información.

El proyecto en cuestión brinda una solución a la programación de los distintos dispositivos del

hogar mediante una forma gráfica e intuitiva para el usuario (convirtiendo los gráficos en

reglas ejecutables por un sistema experto) y provee al mismo tiempo una interfaz para su

control y verificación en forma remota.


2

2. Introducción

El término domótica proviene de la unión de las palabras domus (en latín, casa) y tica (en

griego, que funciona por sí misma). Dicho término agrupa a todas aquellas soluciones

destinadas a automatizar ciertos procesos de la vida cotidiana dentro del hogar, entre los que

se destacan seguridad, confort, comunicación y ahorro de energía. Para poder llevar a cabo

estas funciones, los diversos dispositivos se encuentran interconectados por medio de redes

interiores y exteriores de comunicación, cableadas o inalámbricas, y cuyo control goza de

cierta comodidad y ubicación conveniente, dentro y fuera del hogar.

De acuerdo a [2], se denomina “Domótica” o Automatización del Hogar a la aplicación de

nuevas soluciones tecnológicas basadas en la electrónica y en las telecomunicaciones al

ambiente doméstico, con el objetivo de mejorar dispositivos existentes y proveer un mayor

número de servicios de utilidad doméstica.

La domótica surgió en los años 70, con el fin de interconectar dispositivos de iluminación y

seguridad, otorgando un nivel básico de automatización al usuario. Dicha interconexión

persigue como resultado la asistencia y la simplificación de las condiciones de confort para

todos sus usuarios.

La domótica tiene diversos usos, entre los cuales se destacan:

• Ahorro energético: puede ser alcanzado de diversas maneras, no sólo a través de la

instalación de equipos que consuman menos sino también gracias al manejo eficiente

de los mismos.

o Climatización: programación de encendido/apagado de equipos y

temperaturas de uso.

o Racionalización eléctrica: encendido/ajuste/apagado de equipos eléctricos de

iluminación y entretenimiento.

• Comfort: abarca todos los comportamientos que mejoren la comodidad de los

habitantes de la casa. Esos comportamientos pueden ser activos, pasivos o mixtos.

o Iluminación: encendido/ajuste/apagado de luces.

o Generación de macros o programas de forma sencilla para el usuario.

o Control vía internet

o Automatización de equipos


3

• Seguridad: comprende las funciones de protección tanto de bienes personales como

de sus habitantes.

o Simulación de presencia

o Cerramiento de la propiedad

• Comunicaciones: la vivienda se comunica con el exterior tanto para regular su control

como para notificar de eventos generados.

o Control por internet vía PC, PDAs o teléfonos celulares

o Notificación de alarmas

2.1. Componentes del sistema

• Controlador: es el dispositivo informático (generalmente una PC) y el conjunto de

software que se encarga de recibir las señales provenientes del actuador, procesarlas y

generar y transmitir las órdenes apropiadas a los actuadores adecuados.

• Sensor: dispositivo que mide una cantidad física y la convierte en una señal eléctrica

que puede ser leída por el controlador.

• Actuador: componente que se encarga de transformar una señal eléctrica en una

acción, generalmente mecánica sobre otro elemento físico.

2.2. Tipos de arquitectura

Desde el punto de vista de donde reside la inteligencia del sistema domótico, existen tres

enfoques principales:

• Centralizada: un control central recibe información de los distintos sensores y, una vez

procesada, genera y transmite las órdenes adecuadas a cada actuador.

• Distribuida: la inteligencia del sistema está ubicada en los sensores y actuadores.

• Mixta: existen varios dispositivos capaces de recopilar la información de los sensores y

transmitir órdenes al resto de los dispositivos.


4

3. Presentación del Problema

Muchas de las soluciones domóticas existentes en el mercado tienden a mejorar la calidad de

vida de los habitantes de una vivienda, proveyendo comodidades para la activación o ajuste de

dispositivos a través de controles remotos que requieren de la acción de un individuo. Los

ajustes automáticos se reducen a activaciones producto de temporizadores en dispositivos

puntuales tales como el aire acondicionado o el DVR (Digital Video Recorder, Grabador de

Video Digital). Si se intenta que el grado de automatización involucre a dos o más dispositivos,

gran parte de las opciones disponibles requieren conocimientos técnicos de programación y/o

electrónica. Además, las capacidades de visualizar el estado de la vivienda o agregar nuevos

programas estando fuera del hogar, resultan limitadas. Por ello, queda en evidencia la

necesidad de un sistema que permita automatizar (de modo sencillo para un usuario medio)

tareas que involucren a varios dispositivos y que permita decidir las condiciones de activación

de dichas tareas tales como hora, condiciones externas, etc. tanto desde el hogar como en una

ubicación remota.

4. Objetivo del Trabajo Profesional

El Objetivo del presente Trabajo Profesional es desarrollar un sistema que permita programar

la automatización de equipos de domótica vía web, representando dicha programación como

diagramas de flujo, los cuales se traducirán a código ejecutable de un sistema experto quien

será el encargado de actuar sobre los equipos según las condiciones sensadas en las variables

del ambiente. En este trabajo, no habrá una conexión real con dichos artefactos sino que los

mismos se simularán con un programa con interfaz gráfica.

5. Área de Aplicación

La aplicación está destinada a todo usuario avanzado/semi avanzado de equipos de

automatización del hogar o la oficina, que no tenga conocimientos de programación más allá

de diagramas de flujo y que desee programar sus equipos más allá del nivel básico que otorgan

las interfaces de usuario de cada uno de ellos.


5

6. Productos existentes en el mercado

• X10: estándar internacional abierto para la comunicación entre dispositivos, utilizado

en domótica. Utiliza fundamentalmente las líneas eléctricas para señalización y

control, aunque define también un protocolo de transporte inalámbrico. Fue

desarrollado en 1975 por Pico Electronics, Escocia para permitir el control remoto de

artefactos en el hogar. Fue la primera tecnología de propósito general para redes

domóticas y aún sigue siendo la más utilizada.

Pueden conectarse hasta 256 dispositivos, aprovechando un espacio de direcciones de

8 bits. Este estándar puede considerarse un método de conexión y comunicación de

equipos, que aprovecha la red eléctrica para sus comunicaciones, por lo cual no

requiere la instalación de un cableado original, reduciendo costos pero también al

mismo tiempo podría ser considerado un método de control básico de equipos: por

ejemplo, si se pretende prender y apagar una luz en forma remota, basta con conectar

a la lámpara a un dispositivo X10 y a éste último a la red eléctrica, otorgándole un

código único dentro de la casa y del otro lado, se conecta otro artefacto compatible

con X10, el cual pueda enviar señales para el código de la lámpara. Desde este punto

de vista, puede considerarse que X10 otorga una forma de programación básica y de

fácil instalación pero al mismo tiempo, bastante limitada.

• HEYU: es un programa de consola para Linux y otras Sistemas Operativos derivados de

UNIX (Mac OS X, FreeBSD, Solaris, entre otros) para el control de luces y dispositivos

en la oficina y el hogar. El sistema es capaz de interactuar con equipos X10, temporizar

acciones y de monitorear/registrar los eventos generados.

El software permite asimismo generar scripts de acciones para su posterior ejecución.

En resumen, HEYU actúa como controlador a los sensores y actuadores basados en el

protocolo X10, brindando cierto grado de automatización pero teniendo la limitación

de ser un producto para línea de comandos con lo cual el espectro de posibles usuarios

queda restringido de gran manera. Del mismo modo, cuenta con el inconveniente que

es difícil de operar y monitorear en forma remota, cuando el usuario se encuentra

fuera de su casa.

• Home Control System (HCS) de Home Automation, Inc (HAI): este sistema propietario

puede funcionar como sistema centralizado (comprando un equipo de hardware que


6

actúa como módulo central) o como sistema distribuido (ciertos equipos pueden

actuar de forma localizada y autónoma).

HCS permite la temporización de acciones, el envío de notificaciones y el control de

funciones de seguridad, ahorro de energía y entretenimiento. Puede ser operado

mediante una interfaz gráfica táctil (que se compra por separado) o vía telefónica. En

forma opcional puede ser controlado con control remoto a través de una PC que corra

Windows Media Center o vía internet mediante software adicional.

En pocas palabras, HCS es un sistema altamente configurable y escalable, a costa de

requerir equipo específico de hardware para poder funcionar y software adicional para

poder realizar muchas de las tareas que HEYU no permite.

• ExDomus: es un software para el Media Center de Windows XP/Vista que permite

controlar luces, cortinas, calentadores, cámaras, sistemas de seguridad, etc. usando

como protocolo de conexión X10 o KNX, según la versión. Permite la temporización de

acciones así como también la ejecución de acciones disparadas por un evento externo,

tal como la activación de la alarma.

Se trata de un software pago (aunque cuenta con una versión básica gratuita) que

permite automatizar ciertas tareas pero dentro del ámbito del hogar (no cuenta con

herramientas para la programación o visualización de eventos en forma remota).


7

6.1. Tabla comparativa

X10 HEYU HCS ExDomus Arquitectura Distribuida

(instalación individual de equipos)

Centralizada Centralizado o Distribuido, si se dispone de pocos dispositivos a automatizar

Centralizada

Facilidad de instalación

Alta (con sólo conectar los equipos a la red eléctrica y asignarles un código único salen funcionando)

Baja. Requiere experiencia en entornos UNIX (manejo de Shell scripting y compilación a partir del código fuente)

Media Medio

Facilidad de uso

Media. A través de múltiples controles remotos

Baja. Alta Media‐Alta

Método de control

Controles remotos X10

No posee interfaz gráfica, es un programa de línea de comandos

Se utiliza un control remoto que se comunica con una PC con Windows Media Center


Control remoto (fuera del hogar)

No disponible sin software adicional

No disponible en forma nativa

Vía telefónica, celulares o, con software adicional, vía Internet

No disponible

Facilidad de programación

Alta Media. Requiere generar scripts

Alto Media

Poder de programación

Bajo (muy básico)

Medio‐Alto Alto Media (se pueden generar secuencias de acciones desde la interfaz gráfica)

Temporización de acciones

Sólo utilizando equipos adicionales

Sí Si Si (en las versiones pagas del software)

Registro de eventos


Sí Si No disponible


8

7. Requisitos del Sistema

a. Sistema de control domótico centralizado

b. Facilidad de instalación

c. Facilidad de uso, a través de una interface gráfica sencilla pero poderosa

d. Interfaz gráfica como modo de control

e. Visualización y control tanto local como remoto (vía Internet)

f. Simplicidad de programación

g. Capacidad de temporizar acciones

h. Registro de eventos

i. Posibilidad de activar programas por la llegada de señales externas (alarma por

ejemplo)


9

8. Solución Propuesta

La solución propuesta consta de las siguientes partes:


10

1. Generador gráfico de programas para la automatización de la casa (editor de diagramas), que puede ser accedido vía Internet desde cualquier lugar

En el trabajo profesional, se decidió que para que este componente cumpliese con el

requisito e, la alternativa más conveniente era desarrollar un programa capaz de ser

accesible mediante un navegador web. Teniendo en cuenta los requisitos c‐d‐f, se

decidió que, para mejorar la facilidad de uso, el programa debía estar basado

fuertemente en la manipulación de elementos gráficos. Por ello, se optó por la

programación a partir de la construcción de diagramas de flujo, cuyo concepto es

similar a diagramas aprendidos durante el colegio secundario, con lo cual el grado de

instrucción para su uso inicial se ve reducido considerablemente. Cada diagrama es

almacenado en un servidor dentro de la casa para su eventual posterior edición desde

cualquier lugar. Paralelamente, se convierte el diagrama en un programa ejecutable

(ver 2).

Dentro de las posibilidades para

desarrollo web, se decidió por el

desarrollo utilizando la plataforma

web de Adobe Air/Flex, debido a su

madurez en el mercado, la

documentación disponible, la facilidad

y poder para el desarrollo y la calidad

de los productos construidos bajo la misma.

2. Traductor de los diagramas a código ejecutable

Este componente del trabajo profesional, tal como fue mencionado brevemente en 1,

es el encargado de convertir los diagramas de flujo en código ejecutable. Las opciones

disponibles en el mercado para generación de código van desde la generación de un

programa a partir de un lenguaje estructurado tal como C, pasando por lenguajes

orientados a objetos como Java o C++ y lenguajes de sistemas expertos.

Los lenguajes orientados a objetos fueron rápidamente descartados, debido a que los

diagramas de flujo modelan algoritmos que son rápidamente encapsulados dentro de

una única clase (con lo cual las ventajas de abstracción/encapsulamiento al utilizar

múltiples clases queda perdida).


11

Los lenguajes de sistemas expertos tienen la ventaja de que pueden generar reglas del

estilo SI PRECONDICION ENTONCES POSTCONDICION, que son justamente el tipo de

estructuras que aparecen en forma predominante en los diagramas que se generarán.

Si bien esto también puede hacerse con un lenguaje estructurado, la generación de

reglas SI ENTONCES es una representación más natural. Los lenguajes de sistemas

expertos tienen, respecto a los estructurados, una ventaja adicional: al generar un

programa, el motor del sistema experto tiene herramientas para realizar una ejecución

regla por regla lo cual no sólo facilita la depuración al momento del desarrollo sino que

también provee facilidades para detectar cuando un programa entra en un bucle

infinito (las condiciones de corte no ocurren nunca), esto último es un requisito

fundamental para que la unidad descrita en 3 cumpla eficientemente con su función.

Dentro de los lenguajes de sistema experto, existen distintas opciones, pero se decidió

finalmente por CLIPS por su extensa documentación online, robustez y madurez de la

plataforma, facilidad de integración en múltiples lenguajes, además de la existencia de

múltiples ejemplos de aplicación.

3. Ejecutor de los programas, activados cuando se cumplan las condiciones de inicio definidas por el usuario De los requisitos g e i se deduce que aquella unidad encargada de ejecutar los

diagramas debe estar disponible las 24 horas del día los 7 días de la semana, con lo

cual dicha unidad deberá estar activa todo el tiempo en un servidor en el hogar. A

medida que se vayan cumpliendo las condiciones de cada programa (hora o día de la

semana, llegada de un evento externo como la activación de la alarma), se encargará

de ejecutar cada programa generado por 2. Es por ello que contará con una instancia

del motor del sistema experto. Esta unidad, se encargará además, de recibir las

notificaciones de eventos provenientes de 5 y de indicarle a éste mismo que acciones

tomar (cambiar temperatura en living, abrir portón, etc.).

4. Simulador que actúe como sustituto de los equipos que se pretenden controlar

(actuadores) Este simulador consiste en una pantalla en donde el usuario puede ver que artefactos

se han ido activando en el hogar así como también ver el registro de los eventos


12

generados (Requisito h). Si bien este simulador, tal como se dijo en la propuesta del

presente trabajo profesional, se desarrolló con el fin de mostrar el resultado de la

ejecución de los programas (porque no hay una implementación en dispositivos físicos

en la casa) también tiene como finalidad mostrar en una pantalla al usuario el estado

actual de la casa. Según los

requisitos d y e, este simulador

también es una herramienta

web, que puede utilizarse

desde cualquier navegador,

dentro o fuera de la vivienda en

cuestión. Por idénticas razones

a 1, se desarrolló en Adobe

Flex.

5. Emulador de las variables del hogar Esta unidad se encargará de generar los eventos y valores de variables que en el

mundo real provendrían de los sensores. Además, en el mundo real, sería la encargada

de comunicarse con los dispositivos reales (termostatos, luces, puertas, etc.) para que

realicen las tareas solicitadas por los programas gobernados por 3.


13

9. Casos de Validación

A continuación, se detallará la construcción de algunos casos de validación (ejemplos de uso) desde la perspectiva del usuario, es decir, la formulación y construcción de los diagramas, la etapa de prueba de los mismos y la verificación de los resultados en el simulador. Hay que destacar que en el servidor debe estar ejecutando los programas correspondientes al inciso 3 y 5 del punto anterior.

9.1. Encender las luces del living a las 22:15 horas Para poder realizar este programa, es necesario construir un sencillo diagrama, consistente en una figura Comienzo unida a una figura Asignación, unida a una figura Fin. La figura Asignación tiene una llamada a una función que enciende las luces del living a la intensidad deseada.

1. Iniciar el Editor de Diagramas

2. Insertar una figura comienzo


14

3. Mover la figura hasta la ubicación deseada (Mantener botón izquierdo apretado sobre la figura, mover y luego soltar el botón)


15

4. Configurar las condiciones de inicio del diagrama. Botón derecho sobre la figura Comienzo y seleccionar “Propiedades”

5. Tildar la opción “A las” para que el diagrama se ejecute a la hora especificada. Seleccionar “22” en el cuadro de horas y “15” en el cuadro de minutos. Aceptar para salir del diálogo


16

6. Insertar una figura Asignación

7. Mover la figura Asignación

8. Configurar la figura Asignación. Botón derecho sobre la figura y seleccionar “Propiedades”


17

9. Elegir la función que se pretender ejecutar. Seleccionar “función” en el desplegable.

10. Seleccionar “Living” en el desplegable “Habitación” y “luz” en el desplegable “Función”


18

11. Seleccionar “intensidad” en el desplegable “Parámetro” y “constante” en el desplegable “Tipo de valor”. Por último ingresar “1” en el cuadro “Valor” y Aceptar dos veces.

12. Dibujar una flecha desde Comienzo a Asignación. Botón derecho sobre la figura Comienzo y seleccionar “Siguiente”


19

13. Elegir como destino de la flecha a la figura Asignación haciendo Click con el botón izquierdo sobre la misma.

14. Insertar una figura Fin


20

15. Mover la figura Fin. Dibujar flecha desde Asignación a Comienzo por similar procedimiento al punto 12.

16. Guardar el diagrama.

17. Elegir un nombre para el diagrama creado, por ejemplo “living” y Aceptar.


21

18. Probar la ejecución del diagrama actual en el simulador. Abrir el simulador.

19. En el editor de diagramas, probar el diagrama actual. (En este modo, se forzará la ejecución sin importar las condiciones de inicio seleccionadas).

20. Verificar el resultado de la ejecución en el simulador.


22

21. Activar el diagrama (esto hará que el diagrama se ejecute cuando se cumplan las condiciones especificadas en la figura comienzo).

22. Seleccionar al diagrama “living” y tildar la casilla “activado”. Aceptar para finalizar.


23

23. A la hora indicada, se verifica que la ejecución del programa fue exitosa.


24

9.2. Encender regadores del patio y abrir el portón del Garage

Este programa es similar al anterior aunque muestra la capacidad de establecer secuencias de acciones y cómo se respeta ese orden al momento de la ejecución.

1. Insertar una figura Comienzo.

2. Insertar dos figuras Asignación.


25

3. Insertar una figura Fin.

4. Unir la figura Comienzo con una figura Asignación.

5. Unir a la primera con la segunda Asignación.


26

6. Unir a la segunda Asignación con la figura Fin.


27

7. Configurar a la primera Asignación.

8. Seleccionar “función”.

9. Fijar los regadores del patio a intensidad 4, Aceptar y Aceptar nuevamente.


28

10. Configurar a la primera Asignación y elegir “función”.

11. Seleccionar “Garage” y “abrirPorton” y luego Aceptar dos veces.


29

12. Guardar diagrama con el nombre “abre porton”, por ejemplo.

13. Probar la ejecución del programa

14. Se verifica la ejecución del programa, con las acciones especificadas


30

9.3. Reducir la temperatura del dormitorio en 2°C si la misma supera los 23°C

Este programa muestra el funcionamiento de una condición lógica y el uso de variables como parámetros de las funciones del sistema.

Para ello,

• Comenzar

• Asignar el valor de la temperatura del dormitorio a la variable temp.

• Comparar si ese valor es mayor a 23

• Si es así: o Decrementar en 2 el valor de temp o Ajustar la temperatura del dormitorio en temp grados.

• Fin

(En negrita aparecen las palabras que corresponden a cada figura)

1. Insertar una figura Comienzo.

2. Insertar tres figuras Asignación


31

3. Insertar una figura Fin


32

4. Insertar una figura Condición

5. Unir las figuras como se muestra en la siguiente imagen


33

6. Dibujar la flecha Verdadera desde Condición a la Asignación. Botón derecho sobre la figura Condición y seleccionar “Verdadera”

7. Elegir como destino de la flecha a la figura Asignación haciendo Click con el botón izquierdo sobre la misma.

8. Dibujar la flecha Falsa desde Condición al Fin. Botón derecho sobre la figura

Condición y seleccionar “Falsa”


34

9. Elegir como destino de la flecha a la figura Fin haciendo Click con el botón izquierdo sobre la misma.

10. El diagrama deberá quedar de la siguiente manera:


35

11. Configurar a la Asignación “A” Escriba en el cuadro de texto el nombre de la variable: “temp” y seleccione en el desplegable “función”

Seleccionar la función “obtTemperatura” (obtener temperatura) de “Dormitorio” y Aceptar dos veces.


36

12. Configurar la Condición. Botón derecho sobre la figura Condición y seleccionar “Propiedades”

En el desplegable superior, elegir “variable”, seleccionar “temp” y Aceptar En el desplegable del medio, seleccionar al operador mayor “>”

En el desplegable inferior, seleccionar “constante”, escribir “23” y dar “Aceptar”

Aceptar nuevamente para establecer las propiedades de la Condición

13. Configurar a la Asignación “B”. Click derecho sobre la figura y elegir “Propiedades”


37

En el cuadro de texto escribir “temp” y en el desplegable seleccionar “función”

Seleccionar como Habitación a “(General)” y como función “resta” Seleccionar como parámetro “minuendo” como tipo de valor “variable” y como nombre “temp”

Seleccionar como parámetro “sustraendo”, como tipo de valor “constante” y como nombre “2” y Aceptar dos veces.


38

14. Configurar a la Asignación “C”. Click derecho sobre la figura y elegir “Propiedades” Seleccionar “función” en el desplegable. Elegir “Dormitorio” como habitación, “fijarTemperatura” como función, “valor” como parámetro, “variable” como tipo de valor y “temp” como nombre.

Aceptar dos veces.


39

15. Guardar el diagrama, por ejemplo con el nombre “condición”

16. Probar el programa

17. Verificar en el Simulador que el programa se ejecutó correctamente

(Se ejecutó la rama verdadera de la condición pues en la simulación, el dormitorio inicialmente tiene una temperatura de 24°C)


40

10. Conclusión

En la presente memoria, se ha hecho una breve introducción a la domótica, los conceptos

asociados a la misma, los problemas que ella resuelve, la arquitectura de las posibles

soluciones. Se describió la situación que el presente Trabajo Profesional resuelve, cuáles son

sus objetivos y la arquitectura de la solución propuesta junto con las justificaciones de las

tecnologías adoptadas.

Finalmente, se incluyeron Casos de Validación, que corresponden a ejemplos típicos de uso del

sistema, pudiéndose notar que la elaboración de los mismos es sencilla y altamente gráfica,

incluso para usuarios poco experimentados.

Como última observación, puede concluirse que el sistema permite una programación flexible

y escalable de distintas tareas quedando como línea de expansión para futuros trabajos la

implementación de la conexión entre el servidor y los sensores físicos.


41

11. Referencias

[1] García Martínez, R. y Britos, P. 2004. Ingeniería de Sistemas Expertos. Editorial Nueva

Librería. ISBN 987‐1104‐15‐4.

[2] Gerhart, J. 1999. Home Automation and wiring. Mc Graw‐Hill Professional.

[3] Karwowski, W. 2006. International Encyclopedia of Ergonomics and Human Factors.

CRC Press.

[4] Sierra, E., García‐Martínez, R., Hossian, A., Britos, P. y Balbuena, E. (2006). Providing

Intelligent User‐Adapted Control Strategies in Building Environments. Research in

Computing Science Journal, 19: 235‐241.

[5] Sierra, E., Hossian, A., Britos, P., Rodríguez , D. & García‐Martínez, R. (2007). Fuzzy

Control for Improving Energy Management Within Iindoor Building Environments.

Proceedings CERMA 2007 Electronics, Robotics & Automative Mechanics

Conference.Pag. 412‐ 416. IEEE Computer Society Press. ISBN 978‐0‐7695‐2974‐5.

[6] Sierra, E., Hossian, A., García‐Martínez, R. y Marino, P. (2005). Sistema Experto para

Control Inteligente de las Variables Ambientales de un Edificio Energéticamente

Eficiente. Proceedings de la XI Reunión de Trabajo en Procesamiento de la

Información y Control. Universidad Nacional de Río Cuarto.Pág. 446‐452.

[7] Sierra, E., Hossian, A., Rodríguez, D., García‐Martínez, M., Britos, P., García‐Martínez,

R. (2008). Optimizing Building’s Environments Performance Using Intelligent Systems.

Lecture Notes on Artificial Intelligence, 5027: 486‐491.

[8] Velastin, S y otros. 2006. Intelligent distributed video surveillance systems. IET.

[9] http://es.wikipedia.org/wiki/Domótica (07/05/09)

[10] http://en.wikipedia.org/wiki/X10_(industry_standard) (07/05/09)

[11] http://www.exdomus.com (07/05/09)

[12] http://www.homeauto.com/Products/Products_main.asp (07/05/09)

[13] http://www.heyu.org (07/05/09)

[14] http://www.smarthome.com/about_x10.html (07/05/09)

[15] http://www.xmlme.com/Validator.aspx (validador de XSD al 11/8/09)

[16] http://www.csae.map.es/csi/metrica3/index.html (Referencia de Métrica Versión 3

al 11/8/09)


42

A. Metodología

En el presente apéndice, se describirá el desarrollo del sistema, siguiendo los lineamientos de la metodología de desarrollo de software Métrica Versión 3.

A.1. Desarrollo de Sistemas de Información

Este proceso de MÉTRICA Versión 3 contiene todas las actividades y tareas que se deben llevar

a cabo para desarrollar un sistema, cubriendo desde el análisis de requisitos hasta la

instalación del software.

A.1.1. Estudio de Viabilidad del Sistema (EVS)

En este proceso, se analizarán el conjunto concreto de necesidades, con la idea de

proponer una solución a corto plazo. Los criterios con los que se hará esta propuesta no

serán estratégicos sino tácticos y relacionados con aspectos económicos, técnicos, legales

y operativos.

A.1.1.1. Establecimiento del alcance del sistema

En esta actividad, se estudiará el alcance de la necesidad planteada, realizando una

descripción general de la misma. Se determinarán los objetivos y requisitos. Se

analizarán también posibles restricciones, tanto generales como específicas, que

podrían condicionar el estudio y la planificación de las alternativas de solución que se

propongan.

Se detallará la composición del equipo de trabajo necesario para este proceso y su

planificación. Se identificarán los perfiles, dejando en claro tareas y responsabilidades.

A.1.1.1.1. Estudio de la solicitud

• Descripción general del sistema

El Sistema a permitirá programar la automatización de equipos de domótica

vía web, representando dicha programación como diagramas de flujo, los

cuales se traducirán a código ejecutable de un sistema experto quien será el


43

encargado de actuar sobre los equipos según las condiciones sensadas en las

variables del ambiente.

• Catálogo de Objetivos EVS

ID Autor Tipo Descripción Estado Prioridad Fecha de

creación OBJ1 FRIAS,

G. ESTRATÉGICO Presentar

un Trabajo Profesional de Calidad en Tiempo y Forma

APROB. ALTA 1/8/08

OBJ2 FRIAS, G.

ESTRATEGICO Desarrollar un Sistema de Control Domótico

APROB. ALTA 1/8/08

OBJ3 Merlino, H.

ESTRATEGICO Seguir una Metodología Conocida y Eficaz

APROB. ALTA 1/8/08

• Catálogo de Requisitos

ID Autor Tipo Descripción Estado Prioridad Fechade

creación REQ1 Merlino,

H. DOCUMENTAC

Usar Métrica 3 como Metodología de Desarrollo

INCORP. ALTA 1/8/08

REQ2 FRIAS, G.

NO FUNCIONAL

Capacidad de programar el Sistema desde una ubicación remota

APROB. ALTA 1/8/08

REQ3 FRIAS, G.

NO FUNCIONAL

Facilidad de uso, programación de modo gráfico

APROB. ALTA 1/8/08

REQ4 FRIAS, G.

FUNCIONAL Generar un registro de eventos

APROB. BAJA 20/8/08

REQ5 FRIAS, G.

FUNCIONAL Temporización de Acciones

APROB. MEDIA 17/8/08

REQ6 FRIAS, G.

FUNCIONAL Activación de programas

APROB. MEDIA 20/8/08


44

por llegada de señales externas

A.1.1.1.2. Identificación del alcance del sistema

Se analizará el alcance de la necesidad planteada y se identificarán las restricciones

relativas a la sincronización con otros proyectos, que puedan interferir en la

planificación y futura puesta a punto del sistema objeto del estudio. Una vez

establecido el alcance, se identifican las unidades organizativas afectadas por el

sistema, así como su estructura y responsables de las mismas.

• Catálogo de Requisitos (Relativos a Restricciones o Dependencias con

Otros Proyectos)

En el caso del Trabajo Profesional a desarrollar, como no existen dependencias

con otros proyectos, los requisitos relacionados a restricciones o dependencias

con los mismos no se aplican a este contexto.

• Catálogo de Usuarios

ID Apellido y Nombre

U1 Merlino, Hernán

U2 García‐Martínez, Ramón

U3 Fernández, Enrique

U4 Frías, Guillermo

• Descripción general del sistema

o Contexto del sistema

Dentro del contexto del sistema, y teniendo en cuenta su naturaleza de

trabajo profesional y extensión, no habrá una conexión real los

sensores y actuadores sino que los mismos se simularán con un

programa con interfaz gráfica.


45

o Estructura Organizativa

ID Apellido y Nombre Rol EO1 Merlino, Hernán Director del Trabajo Profesional EO2 García‐Martínez, Ramón Director del Trabajo Profesional EO3 Fernández, Enrique Consultor en Métrica 3 EO4 Frías, Guillermo Analista / Programador / Tester

A.1.1.2. Estudio de la Situación Actual

La situación actual es el estado en el que se encuentran los sistemas de información

existentes en el momento en el que se inicia su estudio. Teniendo en cuenta el

objetivo del estudio de la situación actual, se realizará una valoración de la

información existente acerca de los sistemas de información afectados. En función de

dicha valoración, se especificará el nivel de detalle con que se debe llevar a cabo el

estudio. Se constituirá un equipo de trabajo específico para su realización y se

identificarán los usuarios participantes en el mismo.

A.1.1.2.1. Valoración del estudio de la situación actual

En función de los objetivos establecidos para el estudio de la situación actual, y

considerando el contexto del sistema especificado en la descripción general del

mismo, se identificarán los sistemas de información existentes que es necesario

analizar con el fin de determinar el alcance del sistema actual. Se determinará el

nivel de detalle con el que se va a llevar a cabo el estudio de cada uno de los

sistemas de información implicados.

• Descripción de la Situación Actual

o Descripción de los Sistemas de Información Actuales

A través de las sesiones de trabajo y a la investigación de las

soluciones existentes en el mercado, se recopiló información de los

productos disponibles en el mismo.

X10: estándar internacional abierto para la comunicación entre

dispositivos, utilizado en domótica. Utiliza fundamentalmente las

líneas eléctricas para señalización y control, aunque define también un


46

protocolo de transporte inalámbrico. Fue desarrollado en 1975 por

Pico Electronics, Escocia para permitir el control remoto de artefactos

en el hogar. Fue la primera tecnología de propósito general para redes

domóticas y aún sigue siendo la más utilizada.

Pueden conectarse hasta 256 dispositivos, aprovechando un espacio

de direcciones de 8 bits. Este estándar puede considerarse un método

de conexión y comunicación de equipos, que aprovecha la red eléctrica

para sus comunicaciones, por lo cual no requiere la instalación de un

cableado original, reduciendo costos pero también al mismo tiempo

podría ser considerado un método de control básico de equipos: por

ejemplo, si se pretende prender y apagar una luz en forma remota,

basta con conectar a la lámpara a un dispositivo X10 y a éste último a

la red eléctrica, otorgándole un código único dentro de la casa y del

otro lado, se conecta otro artefacto compatible con X10, el cual pueda

enviar señales para el código de la lámpara. Desde este punto de vista,

puede considerarse que X10 otorga una forma de programación básica

y de fácil instalación pero al mismo tiempo, bastante limitada.

HEYU: es un programa de consola para Linux y otras Sistemas

Operativos derivados de UNIX (Mac OS X, FreeBSD, Solaris, entre otros)

para el control de luces y dispositivos en la oficina y el hogar. El

sistema es capaz de interactuar con equipos X10, temporizar acciones

y de monitorear/registrar los eventos generados.

El software permite asimismo generar scripts de acciones para su

posterior ejecución.

En resumen, HEYU actúa como controlador a los sensores y actuadores

basados en el protocolo X10, brindando cierto grado de

automatización pero teniendo la limitación de ser un producto para

línea de comandos con lo cual el espectro de posibles usuarios queda

restringido de gran manera. Del mismo modo, cuenta con el

inconveniente que es difícil de operar y monitorear en forma remota,

cuando el usuario se encuentra fuera de su casa.

Home Control System (HCS) de Home Automation, Inc (HAI): este

sistema propietario puede funcionar como sistema centralizado


47

(comprando un equipo de hardware que actúa como módulo central) o

como sistema distribuido (ciertos equipos pueden actuar de forma

localizada y autónoma). HCS permite la temporización de acciones, el

envío de notificaciones y el control de funciones de seguridad, ahorro

de energía y entretenimiento. Puede ser operado mediante una

interfaz gráfica táctil (que se compra por separado) o vía telefónica. En

forma opcional puede ser controlado con control remoto a través de

una PC que corra Windows Media Center o vía internet mediante

software adicional.

En pocas palabras, HCS es un sistema altamente configurable y

escalable, a costa de requerir equipo específico de hardware para

poder funcionar y software adicional para poder realizar muchas de las

tareas que HEYU no permite.

ExDomus: es un software para el Media Center de Windows XP/Vista

que permite controlar luces, cortinas, calentadores, cámaras, sistemas

de seguridad, etc. usando como protocolo de conexión X10 o KNX,

según la versión. Permite la temporización de acciones así como

también la ejecución de acciones disparadas por un evento externo, tal

como la activación de la alarma.

Se trata de un software pago (aunque cuenta con una versión básica

gratuita) que permite automatizar ciertas tareas pero dentro del

ámbito del hogar (no cuenta con herramientas para la programación o

visualización de eventos en forma remota).


48

A.1.1.2.2. Identificación de los Usuarios Participantes en el

Estudio de la Situación Actual

En función del nivel de detalle establecido para el estudio de la situación actual, se

identificarán los usuarios participantes de cada una de las unidades organizativas

afectadas por dicho estudio.

ID Apellido y Nombre

U1 Merlino, Hernán

U2 García‐Martínez, Ramón

U3 Fernández, Enrique

U4 Frías, Guillermo

A.1.1.2.3. Descripción de los Sistemas de Información

Existentes

En esta tarea se describirán los sistemas de información existentes afectados,

según el alcance y nivel de detalle establecido en la tarea Valoración del Estudio de

la Situación Actual. Se describirán los sistemas a nivel lógico, aplicando las técnicas

de modelización y siguiendo un método descendente.

(Realizado en conjunto con 2.1.2.1 Valoración del estudio de la situación actual)

A.1.1.2.4. Realización del Diagnóstico de la Situación Actual

Se analizará la información de los Sistemas de Información existentes, obtenida en

la tarea anterior y se identifican problemas, deficiencias y mejoras.

Teniendo en cuenta las alternativas estudiadas en 2.1.2.1, podemos establecer el

siguiente tabla comparativa:


49

X10 HEYU HCS ExDomus Arquitectura Distribuida

(instalación individual de equipos)

Centralizada Centralizado o Distribuido, si se dispone de pocos dispositivos a automatizar

Centralizada


Alta (con sólo conectar los equipos a la red eléctrica y asignarles un código único salen funcionando)

Baja. Requiere experiencia en entornos UNIX (manejo de Shell scripting y compilación a partir del código fuente)

Media Medio

Facilidad de uso

Media. A través de múltiples controles remotos

Baja. Alta Media‐Alta

Método de control

Controles remotos X10

No posee interfaz gráfica, es un programa de línea de comandos



Control remoto (fuera del hogar)


No disponible en forma nativa

Vía telefónica, celulares o, con software adicional, vía Internet

No disponible

Facilidad de programación

Alta Media. Requiere generar scripts

Alto Media

Poder de programación

Bajo (muy básico)

Medio‐Alto Alto Media (se pueden generar secuencias de acciones desde la interfaz gráfica)

Temporización de acciones

Sólo utilizando equipos adicionales

Sí Si Si (en las versiones pagas del software)

Registro de eventos


Sí Si No disponible


50

Dentro de los problemas y deficiencias, podemos ver que X10 por sí solo no es

demasiado poderoso en términos de programación de equipos y que HEYU es

difícil de usar pues no posee de una interfaz gráfica. Para las cuatro alternativas, el

control fuera del hogar es dificultoso porque no poseen de una forma de acceso

adecuada como en el caso de HCS que es vía telefónica o directamente no

disponen de un método de acceso remoto. Como mejora, se propone poder

acceder vía internet, a una herramienta para la programación de los equipos. Otra

posible mejora, es la generación de un instalador que simplifique en gran medida

la instalación del sistema. La temporización de acciones y el registro de eventos

son características deseables debido a que pocas alternativas las poseen.

A.1.1.3. Definición de los requisitos del sistema

En esta actividad, se determinarán los requisitos generales, mediante una serie de

sesiones de trabajo planificadas y realizadas con los usuarios participantes. Se analizará

la información obtenida definiendo los requisitos y sus prioridades, que se añadirán al

catálogo de requisitos que servirá para el estudio y valoración de las distintas

alternativas de solución que se propongan.

A.1.1.3.1. Identificación de las Directrices Técnicas y de

Gestión

La realización de esta tarea permitirá considerar los términos de referencia para el

sistema en estudio desde el punto de vista de directrices tanto técnicas como de

gestión.

ID Autor Tipo Descripción Prioridad Estado Fecha de creación

DTG1 Merlino, H.

Gestión Uso de Métrica 3 como Metodología a seguir

ALTA APROBADA 1/8/08

DTG2 García‐Martínez, R.

Gestión Desarrollo de una Memoria del Trabajo

ALTA APROBADA 1/8/08

DTG3 Frías, G. Técnica Utilización ALTA APROBADA 1/8/08


51

de herramientas de desarrollo reconocidas y probadas

A.1.1.3.2. Identificación de los Requisitos

Teniendo en cuenta la información recopilada en 2.1.2 (Estudio de la Situación

Actual) sobre las soluciones disponibles y a partir de las Sesiones de Trabajo se

identificaron los siguientes requisitos:

a. Sistema de control domótico centralizado

b. Facilidad de instalación

c. Facilidad de uso, a través de una interfase gráfica sencilla pero poderosa

d. Interfaz gráfica como modo de control

e. Visualización y control tanto local como remoto (vía Internet)

f. Simplicidad de programación

g. Capacidad de temporizar acciones

h. Registro de eventos

i. Posibilidad de activar programas por la llegada de señales externas (alarma por

ejemplo)

A.1.1.3.3. Catalogación de los Requisitos


REQ1 FRIAS, G.

Arquitectura Sistema de control domótico centralizado

ALTA APROBADO 1/8/08

REQ2 FRIAS, G.

No Funcional


MEDIA APROBADO 21/8/08

REQ3 FRIAS, G.

No Funcional

Facilidad de uso


REQ4 FRIAS, G.

Funcional Interfaz gráfica como modo de control


REQ5 FRIAS, G.

Funcional Visualización y control tanto local como remoto



52

(vía Internet) REQ6 FRIAS,

G. Funcional Simplicidad

de programación


REQ7 FRIAS, G.

Funcional Capacidad de temporizar acciones


REQ8 FRIAS, G.

Funcional Registro de eventos

BAJA APROBADO 20/8/08

REQ9 FRIAS, G.

Funcional Activación de programas por la llegada de señales externas


A.1.1.4. Estudio de Alternativas de Solución

En este estudio, se propondrán diversas alternativas que respondan satisfactoriamente

a los requisitos planteados, considerando también los resultados obtenidos en 2.1.2

(Estudio de la Situación Actual). Se realizará una descomposición del sistema en

subsistemas, teniendo en cuenta el ámbito y funcionalidad, para facilitar su estudio.

A.1.1.4.1. Preselección de Alternativas de Solución

En esta tarea, se estudiarán diferentes opciones para configurar una solución,

teniendo en cuenta los requisitos a cubrir por el sistema ya obtenidos. Las

soluciones podrán ser desarrollos a medida, o parte desarrollo y parte de

productos comerciales. Se descarta la opción de adquirir una solución

enteramente comercial pues este no es el objetivo del desarrollo de un trabajo

profesional.

Para llevar a cabo esta preselección, en primer lugar se dividirá al sistema a

desarrollar en los siguientes subsistemas:

• Herramienta de programación del hogar

• Generador de código ejecutable

• Unidad de ejecución del código


53

• Simulador de los equipos físicos

• Emulador de las variables del hogar (sensores)

Se procederá entonces a explicar las posibles alternativas de solución.

Alternativa A (Desarrollo de un programa único o standalone,

programación mediante comandos de texto)

La alternativa de solución más sencilla es construir un único programa que

contenga los subsistemas descritos más arriba. Desde este sistema se podrán

construir los programas para automatización del hogar, se generará el código

ejecutable, se ejecutará el código resultante, se visualizarán resultados y se

simularán equipos físicos y sensores. La programación se haría desde una PC

Local en donde el usuario ingresa comandos en un editor de texto.

Diagrama de Representación


54

Alternativa B (Desarrollo de un programa único o standalone,

programación gráfica)

Idem Alternativa A, sólo que la programación se hace mediante la unión de

elementos gráficos en lugar de ingresar comandos en un editor de texto.

Alternativa C (Separar la generación y ejecución de código de la

programación gráfica y visualización de los resultados en dos programas

separados standalone)

Según esta alternativa, se separan los subsistemas dedicados a la generación y

ejecución del código de la programación en sí y se agrega la posibilidad de

visualizar los resultados de esa programación.


55

Alternativa D (Separar la generación y ejecución de código en un server

de la programación gráfica y visualización de resultados, accesibles

desde un navegador)


56

A.1.1.4.2. Descripción de las Alternativas de Solución

Para cada alternativa propuesta, se identifican los subsistemas que cubre y los

requisitos a los que se da respuesta. En 2.1.4.1 se referencia a los subsistemas

involucrados, es por ello, que en este ítem se atacará los requisitos que cada

solución cubre y cuáles no.



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.



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.


57




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.


58

A.1.1.5. Valoración de las Alternativas

Ya descritas las alternativas, se valorarán las mismas, considerando el impacto en la

organización, desde el punto de vista tecnológico, operativo, organizativo, posibles

beneficios, costos y riesgos.

A.1.1.5.1. Estudio de la Inversión

En este punto, debería evaluarse, para cada alternativa de solución propuesta, la

viabilidad económica, realizando un análisis de coste/beneficio, que pondere los

beneficios tangibles e intangibles.

Debido a la naturaleza del presente proyecto, en el cual se lleva adelante un

trabajo profesional, el estudio de inversión no es aplicable pues no existen costos

o inversiones asociadas. Se pasará al estudio de la siguiente tarea.

A.1.1.5.2. Estudio de los Riesgos

Se seleccionarán factores de situación que deberán considerarse, relativos tanto a

la incertidumbre como a la complejidad del sistema.



ID Autor Descripción Gravedad Justificación RIE.A.1 FRIAS,

G. Incertidumbre acerca de la facilidad de uso

Media Los programas de línea de comandos requieren mayor tiempo de entrenamiento

RIE.A.2 FRIAS, G.

Dificultad en la implantación de control desde ubicación remota

Alta Las comunicaciones entre el lado remoto y el hogar deben efectuarse abriendo puertos específicos o con comunicación entre procesos remotos. Los firewalls que cada lugar posee se convierten en una dificultad adicional. La


59

existencia de un solo programa implica que este debe comunicarse con los dispositivos de la casa de forma directa, complicando el desarrollo.

RIE.A.3 FRIAS, G.

Complejidad de comunicación entre distintos subsistemas dentro de un mismo programa

Alta Los distintos subsistemas que realizan tareas muy diferentes tienen un grado de acoplamiento muy alto ya que todos forman parte de un único programa

RIE.A.4 FRIAS, G.

Complejidad de instalación remota

Media Para controlar en forma remota a la aplicación, es necesario instalar componentes específicos en la máquina desde donde se pretende acceder



ID Autor Descripción Gravedad Justificación RIE.B.1 FRIAS,

G. Dificultad en la implantación de control desde ubicación remota

Alta Las comunicaciones entre el lado remoto y el hogar deben efectuarse abriendo puertos específicos o con comunicación entre procesos remotos. Los firewalls que cada lugar posee se convierten en una dificultad adicional. La existencia de un solo programa implica que este debe comunicarse con los dispositivos de la casa de forma directa, complicando el desarrollo.

RIE.B.2 FRIAS, G.

Complejidad de comunicación entre distintos subsistemas dentro de un mismo

Alta Los distintos subsistemas que realizan tareas muy diferentes tienen un grado de acoplamiento muy alto ya que todos forman parte de un único programa


60

programa RIE.B.3 FRIAS,

G. Complejidad de instalación remota





ID Autor Descripción Gravedad Justificación RIE.C.1 FRIAS,


Media Las comunicaciones entre el lado remoto y el hogar deben efectuarse abriendo puertos específicos o con comunicación entre procesos remotos. Los firewalls que cada lugar posee se convierten en una dificultad adicional.

RIE.C.2 FRIAS, G.

Complejidad de instalación remota


Alternativa D (Separar la generación y ejecución de código en un server de

la programación gráfica y visualización de resultados, accesibles desde un

navegador)

ID Autor Descripción Gravedad Justificación RIE.D.1 FRIAS,


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.


61

A.1.1.6. Selección de la Solución

Se seleccionará entre las alternativas a la solución a adoptar.

A.1.1.6.1. Convocatoria de la presentación

En esta tarea, se efectuaría la convocatoria de la presentación de las distintas

alternativas propuestas, adjuntando los productos de la actividad anterior con el

fin de que el Comité de Dirección pueda estudiar previamente su contenido. Se

esperaría confirmación por parte del Comité de Dirección de las alternativas a

presentar.

Dada la naturaleza del presente proyecto como un Trabajo Profesional, este punto

no se aplica.

A.1.1.6.2. Evaluación de las Alternativas y Selección

y

A.1.1.6.3. Aprobación de la Solución

Se evaluarán las alternativas mencionadas en 2.1.5, debatiendo ventajas en

inconvenientes de cada una de ellas y se seleccionará la más adecuada.

De las cuatro alternativas presentadas en 2.1.5 (A,B,C y D), se saca como

conclusión que las alternativas A y B parecen ser la de más simple implementación

a primera vista pero tienen como riesgos la difícil instalación y utilización en forma

remota (RIE.A.2, RIE.A.4, RIE.B.1 y RIE.B.3). Teniendo en cuenta los requerimientos

REQ5 y REQ2 de prioridad alta y media, respectivamente, podemos concluir que

estos son inconvenientes de gran peso.

Tanto las alternativas C como la D tienen una implementación que puede parecer

más compleja que la A y B pues separan la programación/visualización de la

generación de código y ejecución pero traen como ventajas la separación y

encapsulación de tareas muy diferentes, haciendo más eficiente el desarrollo y


62

prueba. La alternativa C tiene como desventaja el hecho de que el programa para

realizar la programación y visualización debe instalarse en toda máquina de la cual

se pretenda controlar el hogar (RIE.C.2) y que la implementación de la

comunicación entre dos programas a través de la red puede verse interrumpido

por la existencia de firewalls o puertos bloqueados como en algunas empresas

(RIE.C.1). Teniendo en cuenta el peso de los requerimientos REQ5 y REQ2, alto y

medio, respectivamente, se puede concluir que la alternativa D tiene puntos

importantes a favor: no requiere instalación en las máquinas remotas (se usa a

partir del navegador web) y la comunicación entre este cliente y la máquina en el

hogar es posible en todas aquellas máquinas que tengan acceso a internet (no

requiere de puertos adicionales).

Como conclusión, la alternativa D ofrece la solución más completa a los

requerimientos analizados en 2.1.3.3. Si bien es una alternativa más compleja que

A o B, compensa esa complejidad con menores riesgos una vez finalizado el

proyecto (cuando el sistema esté en uso), según lo analizado en 2.1.5.2. Las

diferencias entre C y D son menores, pero la conveniencia de prescindir de

instalación en las máquinas remotas (presente en la alternativa D), termina por

definir como solución a adoptar a esta última.


63

A.1.2. Análisis del Sistema de Información

En este proceso se obtendrá una especificación detallada del sistema de información que

satisfaga las necesidades de información de los usuarios y sirva de base para el posterior

diseño del sistema.

Métrica Versión 3 es una metodología que cubre diseños tanto estructurados como

orientados a objetos y las actividades de ambas actividades están integradas en una

estructura común.

A.1.2.1. Definición del Sistema

En esta actividad, se llevará a cabo la descripción inicial del sistema de información, a

partir de los productos generados en el Estudio de Viabilidad del Sistema. Se delimitará

el alcance del sistema, se generará un catálogo de requisitos generales y se describirá

el sistema mediante unos modelos iniciales de alto nivel. También se identificarán los

usuarios que participarán en el proceso de análisis, determinando sus perfiles,

responsabilidades y dedicaciones necesarias. Se elaborará, al mismo tiempo, el plan

de trabajo a seguir.

A.1.2.1.1. Determinación del Alcance del Sistema

En esta tarea se delimitará el Alcance del Sistema de Información, utilizando como

punto de partida el Estudio de Viabilidad del Sistema.

Gracias a las sesiones de trabajo con los usuarios involucrados (ver 2.1.1.2,

Catálogo de usuarios), se obtuvieron los siguientes resultados, aplicando las

técnicas descritas a continuación:


64

• Glosario de términos

ID Término Descripción T1 Controlador Dispositivo informático (generalmente una

PC) y el conjunto de software que se encarga de recibir las señales provenientes del actuador, procesarlas y generar y transmitir las órdenes apropiadas a los actuadores adecuados

T2 Sensor Dispositivo que mide una cantidad física y la convierte en una señal eléctrica que puede ser leída por el controlador

T3 Actuador Componente que se encarga de transformar una señal eléctrica en una acción, generalmente mecánica sobre otro elemento físico

T4 Diagrama Representación mediante elementos gráficos de una tarea de programación en la cual se podrá solicitar información a uno más sensores y se podrá pedir una acción a uno o más actuadores

T5 Programa Conjunto de instrucciones listas para ser ejecutadas

T6 Traductor Convierte un diagrama en un programa T7 Simulador o Emulador de

variables del hogar Permite visualizar las acciones tomadas por actuadores que se activaron y forzar la activación de algún sensor para emular su habilitación

T8 Bloque Elemento gráfico que constituye un Diagrama y que representa una acción a tomar, un condición, etc.


65

• Diagrama de Casos de Uso

Actores involucrados

• Usuario: es quien puede realizar altas, bajas y modificaciones de los diagramas y quien puede habilitar/deshabilitar los mismos para su ejecución.

• Tiempo: actor temporal que dispara el caso de uso “Ejecutar Programa” cuando llega cierto instante previamente definido en un diagrama.

• Cambio en Sensor Externo: actor que representa el cambio de valor en una variable global (por ej.: temperatura exterior, intrusión en la residencia, etc.) que dispara el caso de uso “Ejecutar Programa”.

• Casa: actor que modela a los dispositivos dentro de la misma que se activarán o modificarán su estado como consecuencia de que se dispare el caso de uso “Ejecutar Programa”.


66

Descripción de los Casos de Uso

1. Crear Diagrama: creación de un nuevo diagrama de flujo.

2. Editar Diagrama: en este caso de uso se realiza la modificación de

un diagrama de flujo, tanto en su estructura (figuras involucradas y

su interconexión) como en su función.

3. Administrar Diagramas: se realizan tareas de mantenimiento al

conjunto de diagramas (eliminar, habilitar).

4. Eliminar Diagrama: elimina un diagrama de flujo de los diagramas

disponibles.

5. Habilitar Diagrama: en este caso, se indica si un diagrama debe o

no figurar como disponible para ejecución.

6. Generar Programa: en este caso de uso, se convierte un diagrama

de flujo en un programa para su posterior ejecución.

7. Guardar Diagrama: se almacena el diagrama para su posterior

modificación.

8. Probar diagrama: ejecuta inmediatamente un diagrama por única

vez.

9. Ejecutar Programa: ejecuta un programa previamente generado.

10. Administrar Programas: determina qué programas deben

ejecutarse en el instante actual.

11. Visualizar Estado: se muestra que eventos se originaron en el

hogar y que equipos se activaron.

12. Simular Cambio en Sensor: se simula la activación de un sensor

para estudiar la ejecución de los programas.


67

• Modelo de Dominio


68

A.1.2.1.2. Identificación del Entorno Tecnológico

En esta tarea se definirá, en alto nivel, el entorno tecnológico que se requiere para

dar respuesta a las necesidades de información, especificando sus condicionantes

y restricciones. Para ello se tendrá en cuenta el entorno tecnológico propuesto en

la descripción de la solución, que se obtuvo en el Estudio de Viabilidad del Sistema.

Dentro del Entorno Tecnológico a utilizar, y de acuerdo a las soluciones propuestas

en el Estudio de Viabilidad del Sistema, mediante sesiones de trabajo se determinó

el entorno de hardware: para el lado servidor de la aplicación deberá poder

ejecutarse en una computadora hogareña de rango medio‐bajo, con un

procesador de al menos 800 MHz, 512 MB de RAM y 80 GB de disco duro. El

sistema operativo a utilizar será Microsoft Windows XP/Vista. Del lado cliente,

deberá poder ejecutarse en un navegador moderno tal como Internet Explorer 7,

Mozilla Firefox 2.x o Google Chrome 1.x en adelante, con los requerimientos de

hardware y software que su utilización derive.

En cuanto al Entorno Tecnológico de Software, se decidió por la utilización de

herramientas probadas y de amplia utilización en el mercado: Servidor Web

Apache 1.3.x, Base de Datos MySQL 4.1.x, PHP 4.3.x para responder a las consultas

realizadas por el lado cliente. Para el resto de los componentes del servidor se

utilizará Java 1.6 como plataforma de desarrollo por su poder, flexibilidad y

soporte en el mercado.

Para construir el lado cliente, se utilizará Adobe Flex (con Adobe Flash Player

versión 9) por su amplio uso en el mercado, la flexibilidad y poder del lenguaje y la

calidad final de las interfases gráficas realizadas en el mismo.

Respecto a la generación del código ejecutable, las opciones disponibles en el

mercado van desde la generación de un programa a partir de un lenguaje

estructurado tal como C, pasando por lenguajes orientados a objetos como Java o

C++ y lenguajes de sistemas expertos. Los lenguajes orientados a objetos fueron

rápidamente descartados, debido a que los diagramas de flujo modelan algoritmos

que son rápidamente encapsulados dentro de una única clase (con lo cual las

ventajas de abstracción/encapsulamiento al utilizar múltiples clases queda


69

perdida). Los lenguajes de sistemas expertos tienen la ventaja de que pueden

generar reglas del estilo SI PRECONDICION ENTONCES POSTCONDICION, que son

justamente el tipo de estructuras que aparecen en forma predominante en los

diagramas que se generarán. Si bien esto también puede hacerse con un lenguaje

estructurado, la generación de reglas SI ENTONCES es una representación más

natural. Los lenguajes de sistemas expertos tienen, respecto a los estructurados,

una ventaja adicional: al generar un programa, el motor del sistema experto tiene

herramientas para realizar una ejecución regla por regla lo cual no sólo facilita la

depuración al momento del desarrollo sino que también provee facilidades para

detectar cuando un programa entra en un bucle infinito (las condiciones de corte

no ocurren nunca), esto último es un requisito fundamental para que la unidad

descrita en 3 cumpla eficientemente con su función. Dentro de los lenguajes de

sistema experto, existen distintas opciones, pero se decidió finalmente por CLIPS

por su extensa documentación online, robustez y madurez de la plataforma,

facilidad de integración en múltiples lenguajes, además de la existencia de

múltiples ejemplos de aplicación.

A.1.2.1.3. Especificación de Estándares y Normas

En esta tarea se considerarían referencias de estándares, normativas, leyes o

recomendaciones, para el proceso de desarrollo del sistema de información en

estudio.

En el caso del presente proyecto, y dada la naturaleza de Trabajo Profesional del

mismo, los estándares, normativas y leyes no se aplican, salvo la directiva, antes

mencionada en este documento, que el Trabajo Profesional debe ser desarrollado

siguiendo Métrica 3.

A.1.2.1.4. Identificación de los Usuarios Participantes y

Finales

En esta tarea se identificarán usuarios participantes y finales, interlocutores tanto

en la obtención de requisitos como en la validación de los distintos productos y la

aceptación final del sistema.


70

• Catálogo de usuarios

Se definirán las responsabilidades de los usuarios ya detectados en el EVS

ID Apellido y Nombre Rol Responsabilidades U1 Merlino, Hernán Director del Trabajo

Profesional • Dirección teórica y

práctica U2 García‐Martínez, Ramón Director del Trabajo

Profesional • Dirección teórica y

práctica U3 Fernández, Enrique Consultor en Métrica 3 • Consultoría

referente al seguimiento de la metodología de desarrollo

U4 Frías, Guillermo Analista / Programador / Tester

• Desarrollo • Documentación • Pruebas

A.1.2.2. Establecimiento de Requisitos

En esta actividad, se llevará a cabo la definición, análisis y validación de los requisitos a

partir de la información facilitada por el usuario, completándose el catálogo de

requisitos obtenido en la actividad Definición del Sistema. El objetivo de esta actividad

es obtener un catálogo detallado de requisitos, a partir del cual comprobar que los

productos generados de las actividades de modelización se ajusten a los requisitos de

usuario.

A.1.2.2.1. Obtención de Requisitos

En esta tarea, comenzará la obtención detallada de información mediante sesiones

de trabajo con los usuarios, identificados previamente en la Definición del Sistema.

Gran parte de los requisitos ya se obtuvieron en parte durante el Estudio de

Viabilidad del Sistema, se repetirán en este punto y se agregarán los nuevos

requisitos detectados durante el Análisis del Sistema de Información.


71


REQ1 FRIAS, G.

Arquitectura Sistema de control domótico centralizado


REQ2 FRIAS, G.

No Funcional



REQ3 FRIAS, G.

Funcional Facilidad de uso


REQ4 FRIAS, G.

Funcional Interfaz gráfica como modo de control


REQ5 FRIAS, G.

Funcional Visualización y control tanto local como remoto (vía Internet)


REQ6 FRIAS, G.

Funcional Simplicidad de programación


REQ7 FRIAS, G.

Funcional Capacidad de temporizar acciones


REQ8 FRIAS, G.

Funcional Registro de eventos

BAJA APROBADO 20/8/08

REQ9 FRIAS, G.

Funcional Activación de programas por la llegada de señales externas


REQ10 FRIAS, G.

Rendimiento El lado servidor debe poder ejecutarse en una PC hogareña de acuerdo a las características de ASI 1.2


REQ11 FRIAS, G

Rendimiento El lado cliente debe poder ejecutarse en un navegador web de acuerdo a las características de ASI 1.2



72

El Diagrama de Casos de Uso (y la breve descripción de cada caso) fue ya

presentado en 2.2.2.1

A.1.2.2.2. Especificación de Casos de Uso

En esta tarea, la cual es obligatoria para desarrollos orientados a objetos, como es

este el caso, se especificarán los casos de usos identificados, en términos de

escenario, precondiciones, poscondiciones y excepciones.

1. Crear Diagrama

Escenarios: el usuario desea iniciar la construcción de un nuevo diagrama

Precondiciones: si se estuvo modificando otro diagrama, deben

preguntarse al usuario si desea o no guardar los cambios y de ser

afirmativa la respuesta, actualizar dicho diagrama.

Poscondiciones: se creó un diagrama en blanco

Excepciones: si existía un diagrama abierto que se modificó y no se deseó

guardar esos cambios.

2. Editar Diagrama

Escenarios: el usuario agrega, elimina o mueve figuras, une o desune

figuras del diagrama, cambia las propiedades de las mismas.

Precondiciones: existe un diagrama abierto.

Poscondiciones: el diagrama abierto ha sido modificado.

Excepciones: ‐

3. Administrar Diagramas

Escenarios: el usuario elimina y habilita/deshabilita diagramas

almacenados ya existentes.

Precondiciones: existe al menos un diagrama almacenado.

Postcondiciones: los diagramas indicados por el usuario fueron

eliminados, habilitados o deshabilitados.

Excepciones: el diagrama abierto no puede ser eliminado.


73

4. Eliminar Diagrama

Escenarios: el usuario elimina un diagrama almacenado.

Precondiciones: el diagrama a eliminar existe y no está abierto.

Poscondiciones: se eliminó el diagrama indicado.

Excepciones: ‐

5. Habilitar Diagrama

Escenarios: el usuario habilita o deshabilita un diagrama

Precondiciones: el diagrama a habilitar/deshabilitar se encuentra

almacenado.

Poscondiciones: se habilitó/deshabilitó el diagrama almacenado.

Excepciones: ‐

6. Generar Programa

Escenarios: el usuario guarda un diagrama y como consecuencia de ello se

generará el programa correspondiente.

Precondiciones: el diagrama cuyo programa se intenta generar es

guardado.

Poscondiciones: se generó el programa asociado al diagrama guardado.

Excepciones: ‐

7. Guardar Diagrama

Escenarios: el usuario intenta guardar un diagrama actual, crear uno

nuevo pero antes guardar los cambios del anterior, abrir otro diagrama

pero guardar los cambios del actual.

Precondiciones: Existe un diagrama actual.

Poscondiciones: Se guardó al diagrama actual.

Excepciones: ‐


74

8. Probar Diagrama

Escenarios: el usuario desea forzar la ejecución del diagrama actual a

modo de prueba, sin tener que habilitarlo.

Precondiciones: el diagrama ha sido guardado y no presenta

modificaciones desde ese momento

Poscondiciones: el programa generado a partir del diagrama fue ejecutado

por única vez con éxito.

Excepciones: ‐

9. Ejecutar Programa

Escenarios: el usuario desea forzar la ejecución de un programa, se

cumplieron las condiciones de comienzo de un cierto programa.

Precondiciones: el programa a ejecutar existe y ya fue generado a partir

del diagrama correspondiente.

Poscondiciones: el programa fue ejecutado con éxito.

Excepciones: ‐

10. Administrar Programas

Escenarios: una condición externa (cambio en un sensor, paso del tiempo)

dispara la ejecución de los programas que dependen de dicha condición.

Precondiciones: existe al menos un programa almacenado que depende

de la condición que cambió.

Poscondiciones: los programas que dependen de esa condición fueron

disparados y marcados como ejecutados.

Excepciones: ‐

11. Visualizar Estado

Escenarios: el usuario intenta ver el estado de la casa, que eventos se

generaron, que equipos se activaron y cuáles programas se ejecutaron

Precondiciones: ‐


75

Poscondiciones: se muestra en pantalla el estado de la casa y los eventos

generados.

Excepciones: ‐

12. Simular Cambio en Sensor

Escenarios: el usuario simula el cambio en el valor de un sensor para

analizar qué cambios se producen en el estado de la casa

Precondiciones: ‐

Poscondiciones: el sensor cuyo cambio se simuló cambió de valor.

Excepciones: ‐

A.1.2.2.3. Análisis de los Requisitos

En esta tarea se estudiará la información capturada previamente en esta actividad

para detectar inconsistencias, ambigüedades, duplicidad o escasez de información.

Se analizó la información de las Tareas 2.2.2.1 y 2.2.2.2 en búsqueda de

inconsistencias, ambigüedades, etc. y se determinó que este no era el caso. Se

continúa el análisis en el siguiente punto.

A.1.2.2.4. Validación de Requisitos

En esta tarea, el grupo de usuarios definido en 2.2.1.4, determinó que el catálogo

de requisitos de 2.2.2.1 así como los casos de usos especificados en 2.2.2.2 son

válidos, consistentes y completos.

A.1.2.3. Identificación de Subsistemas de Análisis

En esta actividad, se descompondrá al sistema de información en subsistemas, con el

objeto de facilitar su análisis.


76

A.1.2.3.1. Determinación de Subsistemas de Análisis

En esta tarea, se descompondrá al sistema en subsistemas y se definirán las

dependencias entre subsistemas analizando los elementos compartidos entre ellos

y las interfases entre ellos.

Teniendo en cuenta la información vertida en el modelo de negocio, en el modelo

de dominio, los casos de uso con sus respectivas especificaciones y el catálogo de

requerimientos, se llegó a la conclusión de que debía hacerse una división en

subsistemas para mejorar la comprensión del sistema, mejorar la confiabilidad y

simplificar el desarrollo del mismo.

1. Editor de Diagramas

Descripción: Subsistema encargado de crear, modificar y eliminar

diagramas que posteriormente se convertirán en Programas por CodeGen.

Casos de Uso Asociados: Crear diagrama, Editar diagrama, Administrar

Diagramas, Eliminar Diagrama, Habilitar Diagrama, Guardar diagrama,

Probar Diagrama.

Requisitos Asociados: Facilidad de Uso, interfaz gráfica como modo de

control, visualización y control tanto local como remoto, simplicidad de

programación, lado cliente debe poder ejecutarse en un navegador web

de acuerdo a las características de ASI 1.2.


77

2. Generador de Código

Descripción: Subsistema encargado de generar, a partir de los diagramas,

los programas correspondientes que posteriormente se ejecutarán.

Casos de Uso Asociados: Generar programa, Guardar diagrama, Probar

diagrama.

Requisitos Asociados: Sistema de control domótico centralizado, lado

servidor debe poder ejecutarse en una PC hogareña de acuerdo a las

características de ASI 1.2.

3. Simulador y visualizador de eventos

Descripción: Subsistema responsable de desplegar en pantalla los eventos

que se generaron, equipos que se activaron y de proveer una interfaz para

simular la activación de los sensores.

Casos de Uso Asociados: Ejecutar programa, Visualizar Estado, Simular

Cambio en Sensor.

Requisitos Asociados: Facilidad de uso, interfaz gráfica como modo de

control, visualización y control tanto local como remoto, registro de

eventos, activación de programas por la llegada de señales externas, lado

cliente debe poder ejecutarse en un navegador web de acuerdo a las

características de ASI 1.2.

4. Emulador de las variables del hogar, estado de la casa

Descripción: Subsistema responsable de emular la comunicación con los

dispositivos físicos que estarían conectados en la implementación real

(lámparas, termostatos, comandos para apertura de puertas, sensores por

ejemplo alarma, etc.) y de mantener el estado de la casa y sus dispositivos.

Casos de Uso Asociados: Ejecutar programa, Visualizar Estado, Simular

Cambio en Sensor.

Requisitos Asociados: Sistema de control domótico centralizado,

visualización y control tanto local como remoto, registro de eventos,

activación de programas por la llegada de señales externas, lado servidor


78

debe poder ejecutarse en una PC hogareña de acuerdo a las características

de ASI 1.2.

5. Ejecutor de Código

Descripción: Subsistema encargado de ejecutar los programas generados

cuando se cumplan sus condiciones de inicio (tiempo y/o cambio en

sensores).

Casos de Uso Asociados: Ejecutar Programa, Administrar Programas,

Simular Cambio en sensor.

Requisitos Asociados: Sistema de control domótico centralizado,

capacidad de temporizar acciones, activación de programas por la llegada

de señales externas, lado servidor debe poder ejecutarse en una PC

hogareña de acuerdo a las características de ASI 1.2.

A.1.2.3.2. Integración de Subsistemas de Análisis

Dado que en la tarea anterior se obtuvieron las descripciones de los subsistemas

de análisis, en esta tarea se describirán las interfases entre subsistemas.


79

Solicitar Diagramas Disponibles

Esta interfaz es la encargada de obtener la información relacionada con los

diagramas existentes, cuáles se han modificado o eliminado y cuáles están

activados o desactivados.

Solicitar Archivos de Código Disponibles

Esta interfaz obtiene la información relacionada con los archivos de código

(programas) existentes, generados a partir de los diagramas; cuáles programas se

han modificado o eliminado y cuáles están activados para su ejecución.

Actualizar Estado Dispositivos

Se ocupada de transmitir las órdenes de activación de los dispositivos del hogar,

indicados en cada programa y de mantener informado sobre el estado de los

sensores, ya que estos pueden ser condiciones de disparo de la ejecución de uno o

más programas.

Obtener Eventos y Señales Sensores

Esta interfaz es la encargada de solicitar los últimos eventos generados (activación

de dispositivos, sensores, que programas se ejecutaron, etc.) y de comunicar la

simulación de la activación de un sensor.


80

A.1.2.4. Análisis de los Casos de Uso

Dado que en el presente Trabajo Profesional, se realiza un Análisis Orientado a

Objetos, en esta actividad se identificarán las clases cuyos objetos son necesarios para

realizar un caso de uso y se describirá sus comportamientos mediante la interacción de

dichos objetos.

Esta actividad se llevará a cabo para cada uno de los casos de uso contenidos en un

subsistema de los definidos en la actividad 2.2.3.

A.1.2.4.1. Identificación de Clases Asociadas a un Caso de Uso

En esta tarea, se comenzarán a identificarán las clases de los objetos necesarios

para realizar el caso de uso, basándose en la especificación que ya existe del

mismo.

Nombre de la Clase Caso(s) de Uso Asociado(s) Subsistema(s) asociado(s) Diagrama Crear Diagrama, Editar

Diagrama, Guardar Diagrama, Administrar Diagramas, Eliminar Diagrama, Habilitar Diagrama

Editor de Diagramas

Figura Crear Diagrama, Editar Diagrama, Guardar Diagrama, Eliminar Diagrama

Editor de Diagramas

Programa Crear Diagrama, Editar Diagrama, Guardar Diagrama, Generar Programa, Administrar Diagramas, Eliminar Diagrama, Habilitar Diagrama

Editor de Diagramas, Generador de Código

Bloque Crear Diagrama, Editar Diagrama, Guardar Diagrama, Generar Programa, Eliminar Diagrama

Editor de Diagramas, Generador de Código

HomeState Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor

Emulador de las variables del hogar, estado de la casa; Simulador y visualizador de eventos; Ejecutor de Código

Home Probar Diagrama, Ejecutar Programa, Visualizar Estado, Simular Cambio en Sensor

Emulador de las variables del hogar, estado de la casa; Simulador y


81

visualizador de eventos; Ejecutor de Código

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 Generar Programa Generador de Código Param Generar Programa Generador de Código CodeGen Generar Programa Generador de Código Executer Probar diagrama, Ejecutar

Programa, Administrar Programas, Simular Cambios en Sensor

Emulador de las variables del hogar, estado de la casa; Ejecutor de Código

Dispatcher Ejecutar Programa, Administrar Programas, Simular Cambios en Sensor


CodeSupervisor Probar diagrama, Ejecutar Programa


SensorSystem Simular Cambios en Sensor Emulador de las variables del hogar, estado de la casa; Ejecutor de Código

WatchDog Probar diagrama, Ejecutar Programa

Ejecutor de Código

RemoteFunction Probar diagrama, Ejecutar Programa


MotorInferencias Probar diagrama, Ejecutar Programa

Ejecutor de Código

FileConditions Probar Diagrama, Ejecutar Ejecutor de Código


82

Programa, Administrar Programas, Simular Cambios en Sensor

A.1.2.5. Análisis de las Clases

Esta actividad, que se realiza en todo Análisis Orientado a Objetos, como en el caso del

presente Trabajo, se describirá cada una de las clases surgidas, identificando sus

responsabilidades asociadas, atributos y relaciones entre ellas.

NOTA: dado que cada una de las siguientes tres tareas (2.2.5.1, 2.2.5.2 y 2.2.5.3)

requieren un diagrama de clases para cada subsistema y con el fin de simplificar la

lectura de toda la actividad, luego de la descripción de la tarea 2.2.5.3 se colocará el

diagrama de clases final para cada subsistema.

A.1.2.5.1. Identificación de Responsabilidades y Atributos

En esta tarea, se identificarán atributos relevantes y responsabilidades de las

clases.

Las responsabilidades de una clase son las que definen su funcionalidad, y están

basadas en el papel que desempeñan sus objetos dentro de los distintos casos de

uso. A partir de las mismas, se podrán encontrar las operaciones que van a

pertenecer a esas clases.

Los atributos de una clase especifican propiedades de la clase, y se identifican por

estar implicados en sus responsabilidades.

Se identificarán responsabilidades y atributos para las clases de cada subsistema,

teniendo en cuenta requerimientos, casos de uso e interfaz de usuario (ver 2.2.8)

A.1.2.5.2. Identificación de Asociaciones y Agregaciones

En esta tarea se estudiarán los mensajes establecidos entre los objetos del

diagrama de interacción para determinar que asociaciones existen entre las clases


83

correspondientes. Dichas asociaciones estarán caracterizadas por su papel,

direccionalidad y cardinalidad.

A.1.2.5.3. Identificación de Generalizaciones

En esta tarea se representarán las clases con una organización que permita una

implementación sencilla de la herencia y una agrupación semántica de las distintas

clases.

A continuación, se presentan los diagramas de clases resultantes para cada

subsistema:


84

Editor de Diagramas

El editor de diagrama constituye la interfaz principal de uso del sistema. Su arquitectura es

la de un MVC. El usuario diseña diagramas, constituidos por Figuras, unidas por medio de

Flechas y ajusta la configuración (clase Config) de cada Bloque del Modelo, que es

representado de modo indirecto por una Figura de la Vista. La clase Control coordina que

los cambios en la Vista se vean reflejados en el Modelo y viceversa. La Vista desconoce la

existencia del Modelo y vicerversa, la Clase Mapper, controlada por Control es quien se

encarga de mantener y utilizar las asociaciones entre los elementos de una y la otra.


85

Generador de Código


86

El generador de código convierte la información almacenada por el editor de

diagramas en un programa listo para ser ejecutado. Para ello, CodeGenerator

interpreta esa información y construye un objeto compuesto de la clase Program.

Este a su vez está compuesto por una colección de objetos de la Clase Block y sus

derivadas, el método toCode() es redefinido para cada subclase y convierte a dicho

bloque en código ejecutable. Cada objeto Block puede estar o no compuesto por

una o más expresiones (Expression) y sus derivadas. Por ejemplo un BlockStart

contiene a un objeto ExpressionStart; un BlockAlloc (bloque que representa una

asignación) está conformado por un ExpressionVariable (representando el lado

izquierdo de la asignación) y un Expression (representa el lado derecho de la

asignación, puede ser constante, función, etc.). La clase Param modela a cada

parámetro de una función y puede estar formada por cualquier expresión. Una vez

construido el objeto Program, la conversión a código es trivial, invocando

sucesivamente al método toCode() de cada objeto contenido en él.


87

Ejecutor de Código


88

Executer es la clase responsable de esperar que se cumplan las condiciones de

ejecución de cada archivo y, una vez satisfechas, ordenar su ejecución. Dispatcher

es responsable de determinar, en cada momento, que archivos están en condición

de ser ejecutados, haciendo uso de las condiciones de inicio de cada archivo,

presentes en FileConditions. CodeSupervisor es, como su nombre lo indica,

responsable de supervisar ejecución del código, la cual está a cargo de

MotorInferencias. CodeSupervisor interviene en la ejecución al momento de

ejecutar funciones del hogar por ejemplo, abrir portón y delega la responsabilidad

de comunicarse con el subsistema Emulador de las variables del hogar, estado de

la casa a la clase RemoteFunction. La clase WatchDog es la encargada de

determinar si se cumplió el tiempo máximo estipulado para la ejecución (debido a

un programa que entra en bucle infinito por ejemplo) y notificar de esa condición

anómala. SensorSystem es la encargada de mantener el estado de los sensores.

StateHandler y UpdateHandler son responsables de recibir notificaciones

externas sobre cambios en los sensores ó adicionar de nuevos archivos y eliminar

ya existentes, respectivamente.


89

Emulador de las variables del hogar, estado de la casa


90

HomeState es la clase encargada de responder a los pedidos de ejecución de

funciones y de activación de sensores. Home (Hogar) es la clase ocupada de

modelar los sistemas que componen el hogar y está compuesta por habitaciones

(objetos de la clase Room y sus derivadas). Cada habitación puede ejecutar un

número de funciones (que son registradas al momento de instanciar la habitación)

representadas por objetos de la clase Function y sus subclases (se muestran sólo

un par a modo ilustrativo). Home contiene también a un conjunto de objetos de la

clase Sensor, que a su vez está especializada en la clase SensorSimulated que

modela a los sensores simulados ya que en este trabajo profesional no hay

implementación física hacia los sensores físicos.

Log es responsable del registro de eventos, cada uno de ellos, representado en la

clase LogEntry y sus clases hijas, especializadas según la función que genere dicho

evento.

StateQueryHandler y ExecuterCmdHandler se encargan de responder a los

pedidos de registro de eventos y de ejecución de funciones, respectivamente.

SensorStatusUpdater es responsable de notificar al subsistema de ejecución de

código cambios en el estado de los sensores para que éste decida que archivos

ejecutar.


91

Simulador y visualizador de eventos


92

El diagrama de clases de este subsistema es bastante simple y constituye

simplemente de una capa de visualización con lo cual no existen clases de

entidad. La clase Simulador controla el funcionamiento de la aplicación y se

encarga de pedir nuevos eventos para mostrar. StateResponder es responsable

de atender las respuestas remotas, fallidas o exitosas. La clase Home se ocupa de

modelar la casa y actualizar sus indicadores visuales en el simulador. La clase

Front muestra indicadores gráficos y/o acústicos de los sensores que se van

activando. Alarm modela la animación de la activación de la Alarma de la

vivienda. Home contiene una colección de habitaciones (objetos de la clase Room

y sus derivadas), cada uno de los cuales contiene un termómetro (Thermometer)

que muestra la temperatura interna gráficamente (ver 2.2.8). La clase Patio se

encarga de la representación visual de los eventos en el mismo, más

específicamente de la activación del Regador.

A.1.2.6. Elaboración del Modelo de Datos

Según Métrica versión 3, se desarrolla sólo para Análisis Estructurado, y como en el

caso del presente trabajo se está haciendo un Análisis Orientado a Objetos, se omitirá

esta actividad.

A.1.2.7. Elaboración del Modelo de Procesos

Según Métrica versión 3, se desarrolla sólo para Análisis Estructurado, y como en el

caso del presente trabajo se está haciendo un Análisis Orientado a Objetos, se omitirá

esta actividad.

A.1.2.8. Definición de Interfases de Usuario

En esta actividad, se especificarán las interfases entre el sistema y el usuario: formatos

de pantallas, diálogos. El objetivo es realizar un análisis de los procesos de los sistemas

de información en los que se requiere una interacción del usuario, con el fin de crear

una interfaz que satisfaga los requisitos establecidos.


93

A.1.2.8.1. Especificación de los Principios Generales de la

Interfaz

El objetivo de esta tarea, es especificar los estándares, directrices y elementos

generales a tener en cuenta en la definición de interfaz de usuario.

Principios Generales de la Interfaz

1. El entorno de la interfaz interactiva con el usuario será en todos los casos que

se aplique una interfaz gráfica.

2. La interfaz gráfica de las herramientas de visualización del estado de la casa y

la de edición de diagramas deberá ser semejante a la de los programas típicos

de Windows, con barras de menúes, barras de herramientas, botones y

menúes contextuales.

3. Al necesitar una selección por parte del usuario (abrir un archivo, modificar

propiedades de una figura, etc.), se deberá abrir un diálogo el cual no

modificará nada en el Sistema hasta que el usuario pulse Aceptar en el

mismo.

4. El lado Servidor del Sistema, por ser justamente procesos que responden a

pedidos, no necesitará tener una interfaz gráfica pero es deseable que posea

uno o varios íconos distintivos en el área de notificación de la barra de tareas

de Windows y que desde los mismos puedan detenerse dichos procesos.

5. La herramienta de visualización del estado de la casa deberá tener un panel

desde donde poder observar los últimos eventos generados en la vivienda así

como también un plano de la misma en donde poder observar en forma gráfica

la activación de los dispositivos gráficos más representativos.

6. La herramienta de edición de los diagramas, debe permitir el trazado de los

mismos arrastrando y soltando figuras y dibujando de modo sencillo las

uniones entre las mismas.


94

7. El instalador del Sistema en el lado Servidor deberá tener la interfaz de un

instalador típico de Windows, desarrollado preferentemente con alguna

herramienta específica para tal fin.

A.1.2.8.2. Identificación de Perfiles y Diálogos

El objetivo de esta tarea es identificar los perfiles de usuario, de acuerdo a su nivel

de responsabilidad y al alcance o naturaleza de las funciones que realizan, así

como analizar las características más relevantes de los usuarios que van a asumir

estos perfiles, etc. Para tal fin se genera un catálogo de perfiles de usuario.

En el caso del presente Trabajo Profesional, existe un único perfil de usuario, que

es el usuario final del sistema quien instala en su casa el software correspondiente

al lado Servidor y es a su vez quien ejecuta el sistema (edición de diagramas,

visualización del estado) desde su casa o fuera de ella.

Para ver el catálogo de usuarios, referirse a 2.2.1.4 Identificación de los Usuarios

Participantes y Finales.

A.1.2.8.3. Especificación de Formatos Individuales de la

Interfaz de Pantalla

En esta tarea se presentarán los formatos para las interfases del Sistema del

presente Trabajo Profesional más representativas. Se desarrollaron bosquejos de

la Interfaz final en Microsoft Visio.

Editor de Diagrama

De acuerdo a los Principios de Interfaz y Requisitos previamente descritos, el

editor de Diagrama deberá ser un programa web con apariencia de un programa

típico (standalone) de Windows, con menúes, barras de herramientas y un editor

con arrastrar y soltar. El objetivo es crear una aplicación accesible desde cualquier

lugar, y fácil de usar como un editor WYSIWYG (What You See Is What You Get).


95

Visualizador de eventos y simulador de señales

Esta aplicación también es una aplicación web con apariencia de programa standalone

de Windows. Desde el recuadro Control se puede simular la llegada de nuevas señales.

Abajo del mismo, aparece el registro de los últimos eventos y a su izquierda, el mapa

de la vivienda.


96

Lado Servidor

El lado Servidor se encarga de responder los pedidos del lado cliente por lo tanto sus

requerimientos de interfaz son mínimos. Debe existir, sin embargo, una forma sencilla

de detener los procesos del lado servidor.

A.1.2.8.4. Especificación del Comportamiento Dinámico de la

Interfaz

El objetivo de esta tarea es definir los flujos entre los distintos formatos de interfaz

de pantalla, y también dentro del propio formato. Este comportamiento se

describe mediante un modelo de navegación de pantalla.


97

En este punto se describirá el comportamiento dinámico del subsistema más

cercano al usuario, el Editor de Diagramas, dado que el otro componente que

necesita de la interacción del usuario (Visualizador de Eventos y Simulador de

Señales) tiene una interfaz muy sencilla, la cual no requiere de la navegación por

múltiples pantallas (ver 2.2.5.3).

Editor de Diagramas

Los bloques correspondientes a Abrir Diagrama, Guardar Diagrama y Administrar

Diagrama corresponden a cuadros de diálogo desde donde abrir, guardar y activar y

eliminar diagramas, respectivamente. El bloque Nuevo Diagrama representa la

creación de una nueva instancia de diagrama para ser posteriormente editado. Editar

diagrama comprende la manipulación gráfica del mismo (mover y agregar figuras,

dibujar flechas) mientras que los bloques propiedades (que deberán invocarse a través

de un menú con botón derecho sobre la figura a modificar) corresponden a las

opciones disponibles según el tipo de Figura. Los bloques Constante, Variable y

Función corresponden a cuadros de diálogo accesorios que ayudan a construir las

propiedades de una figura Asignación o Condición.


98

Cuadro Abrir Diagrama

Seleccionar en la lista el Diagrama a abrir y pulsar Aceptar. El botón Cancelar evita

abrir otro diagrama.

.

Cuadro Guardar Diagrama

Ingresar el nombre del nuevo archivo y pulsar Aceptar. El botón Cancelar evita guardar

el diagrama. Si el nombre está siendo usado, preguntar si se desea sobreescribir.

Cuadro Administrar Diagramas

Seleccionar en la lista el Diagrama a activar (o desactivar) y tildar (o destildar) la casilla

activado.


99

Seleccionar en la lista el Diagrama a eliminar, pulsar eliminar y confirmar la decisión.

Pulsando Aceptar se realizan las modificaciones, Cancelar omite cada una de ellas.

Propiedades Comienzo

Presenta las opciones de configuración de una figura Comienzo en el Diagrama.

La configuración de la figura de Comienzo incluye: días de la semana en que el

diagrama se ejecutará, hora del día y que señales externas podrán activar la ejecución

de ese diagrama.


100

Propiedades Asignación

Una asignación representa un bloque donde se puede hacer opcionalmente la

asignación a una variable del lado izquierdo de una expresión a un valor proveniente

de una constante, variable o función. En el caso de ser una función, esta previamente

es ejecutada y evaluada.

En el cuadro de texto se ingresa el nombre de la variable del lado izquierdo. La

expresión del lado derecho se completa eligiendo una opción del combo, la cual abrirá

un nuevo cuadro de selección, según sea su tipo. En Vista previa, se muestra la

expresión resultante en la asignación.

Propiedades Condición

Una condición evalúa una expresión lógica compuesta por una expresión a la izquierda

(representada por el combo superior), una expresión a la derecha y un operador de

comparación ( <, <= , =, != , >= , >, AND, OR). Tanto el combo de la expresión izquierda

como el de la derecha, abren distintos cuadros si se selecciona constante, variable o

función.


101

El recuadro Vista previa muestra la expresión de condición resultante de las

selecciones en los combos.

Cuadro Constante

Este cuadro permite el ingreso de cualquier cadena de caracteres (A‐Z, a‐z, _, 0‐9) o

número entero mayor o igual a cero.

Cuadro Variable

Una variable es cualquier cadena de caracteres que empieza con (A‐Z, a‐z, _ ) y sigue

con cero, uno o más de los siguientes caracteres: (A‐Z, a‐z, _, 0‐9).


102

Cada variable disponible en el desplegable fue definida previamente por el lado

izquierdo de una asignación.

Cuadro Función

Las funciones están categorizadas por la habitación en la que se ejecuta. Cada función

puede tener cero, uno o más parámetros. Cada parámetro puede recibir un valor de

una variable o una constante.

La metodología de uso del cuadro de función es ir completando los desplegables uno a

uno desde arriba hacia abajo. Hay que definir un tipo de valor y nombre para cada uno

de los parámetros que aparecen en el desplegable respectivo.


103

Vista previa muestra cómo va quedando la expresión correspondiente a la función que

se está construyendo. Si existen ? significa que hay parámetros que aún no se

definieron. Pulsando en ? al lado del desplegable de función, se puede obtener una

ayuda rápida para la función seleccionada.

Visualizador de Eventos y Simulador de Señales

Si bien la interfaz de usuario de este subsistema es sencilla, vale la pena remarcar

ciertas transiciones dinámicas de algunos eventos.

Encender la luz de la habitación

Como el plano de la casa que lo compone será un plano de arquitectura en fondo

negro, se tomará la convención que al encender la luz, el fondo de la habitación pasará

de negro a amarillo.

Por ejemplo, en el caso del living:

Luz apagada Luz encendida

Ajustar temperatura de una habitación

El ajuste de temperatura en una habitación será representado por un círculo dentro de

la misma en parte azul y en parte rojo, el cual será tanto más rojo en cuanto se esté

más cerca de la temperatura máxima y tanto más azul en cuanto se esté más cerca de

la temperatura mínima del termostato.


104

Temperatura máxima Temperatura media Temperatura mínima

Regadores del patio

La activación de los regadores del patio estará representada por una animación

consistente en círculos concéntricos azules que crecen de radio y alcanzan un radio

máximo proporcional a la intensidad fijada para el riego.

Apertura y cierre del portón

La apertura y cierre del portón deberá representarse con la existencia o no del portón

en el garaje y estará acompañada por una animación.


105

A.1.2.8.5. Especificación de los formatos de Impresión

En esta tarea, se deberían especificar los formatos y características de las entradas

y salidas impresas.

En el presente Trabajo Profesional, ni las entradas ni las salidas están presentes en

formato impreso por lo tanto este punto de la metodología no es aplicable.

A.1.2.9. Análisis de Consistencia y Especificación de Requisitos

El objetivo de esta actividad es garantizar la calidad de los distintos modelos generados

en el proceso de Análisis del Sistema de Información, y asegurar que los usuarios y los

Analistas tienen el mismo concepto del sistema. Para cumplir dicho objetivo, se llevan

a cabo las siguientes acciones:

• Verificación de la calidad técnica de cada modelo.

• Aseguramiento de la coherencia entre los distintos modelos.

• Validación del cumplimiento de los requisitos.

A.1.2.9.1. Verificación de los Modelos

y

A.1.2.9.2. Análisis de Consistencia entre los Modelos

En estas tareas, se deberán asegurar la calidad de los distintos modelos. Para ello,

se analizó la consistencia entre los mismos y su completitud. Se tuvo en cuenta el

Catálogo de Requisitos, el Diagrama de Casos de Uso con sus respectivas

especificaciones, diagrama de subsistemas (y sus especificaciones), los diagramas

de clases y la especificación de la interfaz de usuario.

Cada uno de estos modelos ya incluidos cuenta con las modificaciones para

garantizar dicha consistencia.


106

A.1.2.9.3. Validación de los Modelos

Se validaron los modelos contra el Catálogo de Requisitos así como también en

reuniones con los usuarios especificados en el Catálogo de Usuarios.

A.1.2.10. Especificación del Plan de Pruebas

En esta actividad, se iniciará la definición del Plan de Pruebas, el cual servirá como guía

para la realización de las pruebas y verificará que el sistema de información cumple

con las necesidades establecidas por el usuario, con las debidas garantías de calidad.

A.1.2.10.1. Definición del Alcance de las Pruebas

De acuerdo al sistema a desarrollar, se decidió que se utilizarán los siguientes

niveles de pruebas:

• Pruebas Unitarias de Clases: según el caso, se evaluará si se deciden

realizar pruebas automatizadas de las clases críticas (unit testing) y al resto

de las clases se les realizarán pruebas individuales en forma manual. Estas

pruebas se harán paralelamente a la codificación del sistema y sólo

cuando estas sean superadas podrá pasarse a la siguiente actividad. Estas

pruebas serán realizadas por el alumno.

• Pruebas de Integración: se ejecutarán en forma manual y tendrán como

objetivo verificar que el flujo de datos entre dos subsistemas cualesquiera

generen el producto deseado. Estas pruebas de integración se realizarán al

finalizar los subsistemas involucrados y deberán ser pasadas antes de las

pruebas de sistema. Estas pruebas serán realizadas por el alumno.

• Pruebas de Sistema: serán realizadas por el alumno y estarán orientadas

según la técnica de “caja negra”, en la cual se examinan algunos aspectos

externos del modelo del sistema sin tener en cuenta la estructura interna

del software. Una vez que la aplicación supere estas pruebas, estará lista

para las pruebas de aceptación del sistema.


107

• Pruebas de aceptación del sistema: serán similares a las pruebas de

sistema, pero realizadas en presencia de los directores del Trabajo

Profesional, una vez concluido el desarrollo, en la que se verificará el

cumplimiento de los requisitos funcionales previamente mencionados en

este documento.

A.1.2.10.2. Definición de Requisitos del Entorno de Pruebas

En esta tarea, se definirán y recopilarán los requisitos relativos al entorno de

pruebas, completando el plan de pruebas.

Siguiendo las recomendaciones de Métrica Versión 3, de separar el entorno de

pruebas del de desarrollo y operación, se determinó que para las pruebas

unitarias, de integración y de sistema a cargo del alumno se utilizará el entorno de

desarrollo, y para las actividades de prueba que resulten convenientes (por

ejemplo, prueba del instalador) se utilizará una máquina limpia donde se instalará

el sistema paso a paso. De no contar con dicha máquina limpia, podrá utilizarse

una máquina virtual a través de Microsoft Virtual PC o similar. Para las pruebas de

aceptación, podrá, asimismo, utilizarse una máquina virtual o una PC limpia y

ejecutar el instalador provisto, siguiendo las instrucciones que generadas por el

alumno que él crea conveniente.

A continuación, se enumeran los requisitos para los entornos de pruebas

Requisitos de Hardware:

• Procesador Intel o compatible de 800 MHz o superior

• 512 MB RAM

• 30 MB libres en el disco rígido

• Conexión a red

Requisitos de Software:

• Máquina Virtual de Java (JRE o JDK) 1.6 o superior

• Web Server (Apache 1.3.33 o superior recomendado)

• PHP 4.3.10 o superior

• MySQL 4.1.9 o superior


108

• Navegador web (Firefox 2.0 o superior recomendado)

• Adobe Flash Player 10

A.1.2.10.3. Definición de las Pruebas de Aceptación del

Sistema

En esta tarea se realizará la especificación de las pruebas de aceptación del

sistema, labor fundamental para que el usuario valide el sistema, como último

paso, previo a la puesta en explotación.

Se insistirán en los criterios de aceptación del sistema que sirven de base para

asegurar que satisface los requisitos exigidos.

Reporte de fallas de las pruebas

Las fallas serán identificadas durante el análisis y evaluación de los resultados de la

ejecución de las pruebas. Se utilizará el siguiente formato para las tarjetas de

reporte de pruebas.

Reporte de Prueba Nro: ………………….. Fecha: __/__/__

Objetivo: ……………………………………………………………………………………………………….

……………………………………………………………………………………………………………………………

…………………………….………………………………………………………………………………………..

Errores encontrados:

ID Caso de Prueba Nivel Severidad Descripción


109

Criterio de Paso/Falla

Los criterios a aplicar en la evaluación de las distintas instancias de prueba son:

• Paso: Todas las pruebas realizadas sobre el ítem fueron exitosas.

• Fallo: Al menos una de las pruebas realizadas no fue exitosa.

El criterio a emplear sobre las pruebas de la aplicación es el siguiente:

• Exitosa: Todas las pruebas fueron realizadas y no se encontraron defectos

de severidad 1, 2 o 3.

• Fallida: Al menos un defecto de severidad 1, 2 o 3 fue encontrado.

Severidad Descripción 1 Sistema detenido

2 Fallas de funcionalidad

3 Una solución alternativa puede aplicarse

4 Error de documentación/ayuda

5 Cambios y mejoras

Criterio de suspensión y reiniciación de pruebas

Las actividades de prueba deberían ser suspendidas si se encuentra algún

problema que impida la realización de la prueba ó un problema que impida la

realización de más pruebas. Esto implica que cuando se encuentre un problema y

se puedan seguir haciendo pruebas, las mismas deben continuar. Las pruebas

deben reiniciarse cuando los inconvenientes hayan sido solucionados,

comenzando con el primer caso de prueba para así verificar que la solución

propuesta no genere nuevos problemas.

Actividades de prueba

Las actividades de prueba contemplan: actualizar el plan de pruebas y

documentación de diseño, crear o actualizar casos de prueba, efectuar pruebas y

realizar su análisis (documentando las fallas en la tarjeta previamente

mencionada) y por último, llevar a cabo la prueba de aceptación del sistema para


110

comprobar si el mismo responde fielmente a los requisitos del sistema

previamente definidos en este documento.

A.1.2.11. Aprobación del Análisis del Sistema de Información

A.1.2.11.1. Presentación y Aprobación del Análisis del Sistema

de Información

El análisis del sistema fue presentado y aprobado por los Directores del Trabajo

Profesional.


111

A.1.3. Diseño del Sistema de Información

En esta actividad se definirá la arquitectura general del sistema de información,

especificando las distintas particiones físicas del mismo, la descomposición lógica en

subsistemas de diseño y la ubicación de cada subsistema en cada partición, así como la

especificación detallada de la infraestructura tecnológica necesaria para dar soporte al

sistema de información.

A.1.3.1. Definición de la Arquitectura del Sistema

A.1.3.1.1. Definición de los Niveles de Arquitectura

En esta tarea se describirán los niveles de la arquitectura software, mediante la

definición de las principales particiones físicas del sistema de información,

representadas como nodos y comunicaciones entre nodos.

Se entiende por nodo cada partición física o parte significativa del sistema de

información, con características propias de ejecución o función, e incluso de

diseño y construcción.

Para facilitar la comprensión del sistema, se identificarán como nodos los

elementos de infraestructura más significativos de la arquitectura en la que se va a

implementar el sistema de información.

La comunicación se expresa por una conexión entre nodos, indicando su carácter

bidireccional o unidireccional, con las principales características de los protocolos

o tipo de mensajes utilizados.


112


113

Descripción

• El Sistema se encuentra dividido en un lado Cliente (parte baja de la

imagen) y un lado Servidor (parte de arriba de la imagen).

• La comunicación entre el lado Cliente y el Servidor se realiza vía Internet,

mientras que la conexión física con la red puede ser vía ADSL,

Cablemódem ó Telefónica Dial Up. Sin embargo, una conexión de banda

ancha es deseable tanto para el Cliente como para el Servidor para

acelerar la descarga de los datos.

• El lado Cliente, representado por las dos PCs, es accesible vía un navegador

web con soporte Flash. Desde allí se controlan el Editor de Diagramas y el

Simulador, pudiéndose correr simultáneamente en la misma PC en dos

ventanas diferentes.

• El lado Servidor está compuesto por varios subsistemas que se comunican

entre sí vía TCP/IP, dentro de la máquina servidor, así como también una

Base de Datos donde persisten los diagramas creados en el editor. En el

servidor existe una capa que media entre los pedidos del cliente y el

servidor en sí, escrita en PHP.

• En el lado Servidor, el subsistema CodeGen genera el código de los

programas a partir de los diagramas en la Base de Datos y provee dichos

programas a Executer, que se encarga de ejecutarlos. Executer se encarga

a su vez de solicitar a HomeState la ejecución de las funciones remotas

quien a su vez deriva los pedidos a los sensores y actuadores que, en el

caso del presente trabajo, son ficticios y no tienen implementación física,

como ya se explicó a lo largo del presente informe.

A.1.3.1.2. Identificación de Requisitos de Diseño y

Construcción

En esta tarea se realizará la especificación de los requisitos que están

directamente relacionados con la adopción o diseño de una arquitectura o


114

infraestructura concreta, y que pueden condicionar el diseño o la construcción del


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


115

valor sea 1 si no ocurrió ningún error y 0 en caso contrario, en este último

caso indicando además código de error y descripción en modo texto. A

partir de esta información se decidirá, durante la construcción del sistema

mostrar un cuadro de aviso del error con el texto recibido u otro que se

considere conveniente. Se recomienda no desestimar el error.

• Lado Servidor (CodeGen, HomeState y Executer): dado que estos

programas corren en el lado servidor y se dedican a atender los pedidos

del lado cliente y también teniendo en cuenta que no tendrán una interfaz

gráfica, se decidió que el reporte de errores será de la siguiente manera:

cada subsistema generará un reporte en un archivo de registro o log, en

donde se detallará la naturaleza de la excepción, fecha y hora de la misma.

Estos archivos se abrirán para concatenar datos, siendo responsabilidad

del usuario interpretarlos y eliminarlos.

A.1.3.1.4. Especificación de Estándares y Normas de Diseño y

Construcción

En esta tarea se definirán los estándares técnicos y de nomenclatura, normas y

recomendaciones, que generalmente están relacionados con la adopción o diseño

de una arquitectura o infraestructura tecnológica concreta, y que pueden

condicionar el diseño o la construcción del sistema de información.

A partir del diálogo entre los directores del Trabajo Profesional y el alumno, se

determinó que en lo referente a estándares y normas de diseño y construcción, el

presente trabajo deberá basarse en la Metodología de Desarrollo Métrica versión

3 y sus recomendaciones. Asimismo, dada la naturaleza del desarrollo orientado a

objetos, deberán seguirse sus principios de extensibilidad y encapsulamiento,

indicando los patrones de diseño y/o arquitectura utilizados.

A.1.3.1.5. Identificación de los Subsistemas de Diseño

En esta tarea, se consideraron como Subsistemas de Diseño a los Subsistemas de

Análisis, identificados y descritos en 2.2.3. Identificación de Subsistemas de

Análisis.


116

A.1.3.1.6. Especificación del Entorno Tecnológico

El entorno tecnológico ya se definió en etapa de Análisis, más específicamente en

2.2.1.2. Identificación del Entorno Tecnológico.

A.1.3.2. Diseño de la Arquitectura de Soporte

En esta actividad se llevaría a cabo la especificación de la arquitectura de soporte y

comprende el diseño de los subsistemas de soporte identificados en la actividad de

Definición de la Arquitectura del Sistema (DSI 1) y la determinación de los mecanismos

genéricos de diseño. Estos últimos sirven de guía en la utilización de diferentes estilos

de diseño, tanto en el ámbito global del sistema de información, como en el diseño de

detalle.

El diseño de los subsistemas de soporte, conceptualmente, es similar al diseño de los

subsistemas específicos, aunque debe cumplir con unos objetivos claros de

reutilización. De esta manera, se consigue simplificar y abstraer el diseño de los

subsistemas específicos de la complejidad del entorno tecnológico, dotando al sistema

de información de una mayor independencia de la infraestructura que le da soporte.

En el caso del presente Trabajo Profesional, el cual a diferencia de los proyectos

empresariales, no persigue la elaboración de componentes para una posterior

reutilización en otros sistemas. Es por ello, que aquellos subsistemas que pudieran

estar incluidos como arquitectura de soporte ya fueron considerados en los

subsistemas específicos.

A.1.3.3. Diseño de los Casos de Uso Reales

Esta actividad, se especificará el comportamiento del sistema de información para un

caso de uso, mediante objetos o subsistemas de diseño que interactúan, y determinar

las operaciones de las clases e interfases de los distintos subsistemas de diseño.


117

A.1.3.3.1. Identificación de las Clases Asociadas con un Caso

de Uso

En esta tarea se identificarán las clases que intervienen en cada caso de uso, a

partir del conjunto de clases definidas en la tarea Identificación de Clases

Adicionales (DSI 4.1). Dichas clases se identifican a partir de las clases del modelo

del análisis y de aquellas clases adicionales necesarias para el escenario que se

está diseñando.

Teniendo en cuenta lo desarrollado hasta el momento en la etapa de Diseño y lo

visto en la etapa de Análisis, concluimos que las clases identificadas para los casos

de uso obtenidas en ésta última etapa son válidas y completas. Para más

información, referirse a 2.2.4.1. Identificación de Clases Asociadas a un Caso de

Uso.

A.1.3.3.2. Revisión de la Interfaz de Usuario

En esta tarea, se revisaron los diseños de interfaz hechos en Microsoft Visio en

2.2.8. Definición de Interfases de Usuario y se analizó si las mismas pueden

completarse utilizando las herramientas de desarrollo elegidas: Flex para el lado

Cliente y Java para el lado Servidor. Se concluyó que las interfases propuestas

pueden construirse en los lenguajes a utilizar.

A.1.3.3.3. Revisión de Subsistemas de Diseño e Interfases

En 2.2.4.1. Identificación de Clases Asociadas a un Caso de Uso, figura además de

las clases asociadas a cada caso de uso, los subsistemas con los que dichas clases

se encuentran relacionadas.

A.1.3.4. Diseño de Clases

En esta actividad, se transformará el modelo de clases lógico, que proviene del análisis,

en un modelo de clases de diseño. Dicho modelo recoge la especificación detallada de

cada una de las clases, es decir, sus atributos, operaciones, métodos, y el diseño

preciso de las relaciones establecidas entre ellas, bien sean de agregación, asociación o


118

jerarquía. Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones

tomadas sobre el entorno tecnológico y el entorno de desarrollo elegido para la

implementación.

A.1.3.4.1. Identificación de Clases Adicionales

En esta tarea se identificará un conjunto de clases que completen el modelo de

clases analizado en la tarea Validación de los Modelos (2.2.9.3) del proceso

anterior. Las siguientes clases fueron identificadas teniendo en cuenta las

enumeradas en 2.2.4.1, las interfases de usuario proyectadas en 2.2.8 y lo visto en

esta etapa de Diseño. Dichas clases e interfases (en este último caso, sus nombres

empiezan con I) están fundamentalmente relacionadas con patrones de diseño

(Builders, Factorys) para la construcción de objetos complejos o bien dedicadas a

servicios de la interfaz de usuario.

Nombre de la Clase o Interfaz

Caso(s) de Uso Asociado(s) Subsistema(s) asociado(s)

BuilderDiagrama CrearDiagrama, Editar Diagrama

Editor de Diagramas

BuilderPrograma CrearDiagrama, Editar Diagrama

Editor de Diagramas

BuilderMapper CrearDiagrama, Editar Diagrama

Editor de Diagramas

DraggableImage Editar Diagrama Editor de Diagramas ICaminoFlecha Editar Diagrama Editor de Diagramas Punto Editar Diagrama Editor de Diagramas Línea Editar Diagrama Editor de Diagramas Rectángulo Editar Diagrama Editor de Diagramas OpenDlg Editar Diagrama Editor de Diagramas SaveDlg Guardar Diagrama Editor de Diagramas ManagerDlg Administrar Diagramas Editor de Diagramas IBuilderHome, BuildSimulatedHome

Ejecutar Programa, VisualizarEstado, Simular Cambio en Sensor


IBuilderExpression, BuilderExpression

Generar Programa Generador de Código

IBuilderProgram, BuilderProgramCLIPS


IFactoryExpression, FactoryExpression


IFactoryProgram, FactoryProgramCLIPS


BuilderDispatcher Administrar Programas Ejecutor de Código BuilderFileConditions Administrar Programas Ejecutor de Código BuilderSensorSystem Administrar Programas Ejecutor de Código


119

Descripción de las Clases Adicionales

BuilderDiagrama: clase encargada de construir un objeto de la clase Diagrama a

partir de los datos almacenados, provenientes de una edición previa.

BuilderPrograma: clase responsable de la construcción de un objeto de la clase

Programa a partir de los datos almacenados, provenientes de una edición previa.

BuilderMapper: esta clase se ocupa de construir un objeto de la clase Mapper a

partir de los datos almacenados, provenientes de una edición previa.

DraggableImage: clase responsable de modelar los comportamientos de una

imagen arrastrable (drag&drop) por la pantalla de edición del diagrama, utilizada

por cada una de las figuras del mismo.

ICaminoFlecha: interfaz que declara los métodos utilizados para definir la

estrategia a utilizar para dibujar la flecha entre dos figuras.

Punto: clase responsable de modelar un punto dentro del diagrama.

Línea: clase responsable de modelar una línea dentro del diagrama.

Rectángulo: clase encargada de modelar las coordenadas de un rectángulo dentro

del diagrama.

OpenDlg: clase que modela el comportamiento del cuadro “Abrir Diagrama” (ver

2.2.8.4)

SaveDlg: clase que modela el comportamiento del cuadro “Guardar/Guardar como

Diagrama” (ver 2.2.8.4)

ManagerDlg: clase que modela el comportamiento del cuadro “Administrar

Diagramas” (ver 2.2.8.4)

IBuilderHome: interfaz que declara los métodos utilizados para construir un objeto

Home. BuildSimulatedHome implementa la interfaz para una casa simulada con

una configuración de habitaciones predeterminadas.

BuilderDispatcher: clase que crea un objeto de la clase Dispatcher con todos los

archivos que ésta debe vigilar.

BuilderFileConditions: clase que crea un objeto de la clase FileConditions a partir

de información persistente.


120

BuilderSensorSystem: clase que crea un objeto de la clase SensorSystem a partir

de información serializada.

IBuilderExpression: interfaz que declara los métodos utilizados para construir un

objeto de la clase Expression (haciendo uso de un factory) a partir de información

serializada. BuilderExpression implementa esta interfaz.

IBuilderProgram: interfaz que declara los métodos utilizados para construir un

objeto Program (haciendo uso de un factory) a partir de la información

persistente. BuilderProgramCLIPS implementa esta interfaz para programas

escritos en CLIPS.

IFactoryExpression: interfaz que declara los métodos para construir los objetos de

la clase Expression y sus derivadas. FactoryExpression implementa esta interfaz.

IFactoryProgram: interfaz que declara los métodos para construir los objetos

relacionados con la clase Program. FactoryProgramCLIPS implementa esta interfaz

para programas escritos en CLIPS

A.1.3.4.2. Diseño de Asociaciones y Agregaciones

En esta tarea, se completarán las asociaciones y agregaciones entre las clases. Para

facilitar la lectura, y hacer el proceso más eficiente, se transcribirán los resultados

una vez realizadas esta actividad y las siguientes:

A.1.3.4.3. Identificación de los Atributos de las Clases

En esta tarea se identificarán y describirá, una vez especificado el entorno de

desarrollo, los atributos de las clases.

Y además,

A.1.3.4.4. Identificación de las Operaciones de las Clases

En esta tarea se definirán, de forma detallada, las operaciones de cada clase de

diseño. Para ello, se tomará como punto de partida el modelo de clases generado

en el análisis, así como el diseño de los casos de uso reales y los requisitos de

diseño que pueden aparecer al definir el entorno de desarrollo.


121

Se actualizarán los diagramas de clases generados en 2.2.5. Análisis de las Clases,

de acuerdo a las nuevas clases identificadas, se completarán con sus asociaciones,

agregaciones, atributos y operaciones.

Editor de Diagramas


122



123

Generador de Código


124

Ejecutor de Código


125

Simulador

No se registraron nuevas clases durante la etapa de Diseño, por lo cual se

conserva el diagrama de la etapa de Análisis (tarea 2.2.5. Análisis de las Clases).

A.1.3.4.5. Diseño de la Jerarquía

En esta tarea se revisará la jerarquía de clases que ha surgido en el modelo de

clases a lo largo de las tareas anteriores y comprobará si esa jerarquía es viable

según los mecanismos disponibles en el entorno de desarrollo utilizado.

Se verificó la jerarquía de clases y se determinó que es viable, en función de las

herramientas a utilizar para el desarrollo del sistema. En los diagramas expuestos

en 2.3.4 Diseño de clases, ya figuran interfases y clases abstractas útiles que

pudieron ser identificadas.

A.1.3.4.6. Descripción de los Métodos de las Operaciones

En esta tarea se describirán los métodos que se usan para detallar como se realiza

cada una de las operaciones de una clase. Los métodos pueden especificarse

mediante un algoritmo, usando pseudocódigo o lenguaje natural.

Debido al número de clases y de métodos, para simplificar la lectura, se decidió

especificar en borrador a los más representativos y esa información se utilizará a la

hora de generar la documentación para el programador (JavaDoc en el caso de

Java y ASDoc en el caso de Flex). Por ello, además del presente informe, se

entregará documentación la cual estará formada en parte de los archivos que sean

generados durante la construcción del sistema, sean JavaDocs y ASDocs.

A.1.3.4.7. Especificación de Necesidades de Migración y Carga

Inicial de Datos

En esta tarea se realiza, en los casos que sea necesario y a partir de los resultados

de la tarea 2.2.6.4, una primera especificación de las necesidades de migración o


126

carga inicial de los datos requeridos por el sistema, que se completa en la actividad

Diseño de la Migración y Carga Inicial de Datos (2.3.9).

En el caso del presente Trabajo Profesional, como se decidió realizar un Diseño

Orientado a Objetos, no se realizó 2.2.6.4. Sin embargo, las necesidades carga

inicial de datos y migración en este Proyecto estarán relacionadas con las

funciones domóticas disponibles, las habitaciones donde cada una de ellas podrán

realizarse y los parámetros que toman estas funciones.

Se llegó a la conclusión que la mejor forma de cumplir con esta carga inicial es

delegar esta tarea al instalador de la aplicación servidor y que éste se ocupe de

generar las tablas apropiadas junto con los datos que se requieran para activar la

aplicación. El instalador podrá pedir que exista un motor de bases de datos

instalado y que se encuentre en funcionamiento al momento de comenzar el

proceso de instalación.

A.1.3.5. Diseño de la Arquitectura de Módulos del Sistema

Esta actividad se omite, debido a que su realización es únicamente en los casos de

Diseño Estructurado.

A.1.3.6. Diseño Físico de Datos

En esta actividad se definirá la estructura física de datos que utilizará el sistema, a

partir del modelo lógico de datos normalizado o modelo de clases, de manera que

teniendo presentes las características específicas del sistema de gestión de datos

concreto a utilizar, los requisitos establecidos para el sistema de información, y las

particularidades del entorno tecnológico, se consiga una mayor eficiencia en el

tratamiento de los datos.

A.1.3.6.1. Diseño del Modelo Físico de Datos

En el presente trabajo, se utilizará un motor de una Base de Datos relacional, para

almacenar y recuperar los diagramas generados, determinar su estado y recuperar


127

la información acerca de las funciones domóticas disponibles del hogar y de cada

habitación en particular.

Para realizar este diseño, se creó un Diagrama Entidad‐Relación

Como puede verse en el Diagrama, el diseño de la Base de Datos es sencillo.

Por un lado, se tiene a la entidad FILE (Archivo) que tiene varios atributos, id

representa a la identificación unívoca para cada archivo de diagrama; name es el

nombre de dicho archivo, content es el contenido de ese archivo que representa el

diagrama (en formato XML) y active indica si ese diagrama está activo (activado) o

no.

Por el otro lado, se encuentra la entidad ROOM (habitación) que modela a cada

habitación de la vivienda; el atributo id es la clave y el atributo name define el

nombre de la habitación. La entidad FUNCTION (función) por su parte, representa

cada función domótica disponible en el hogar; posee una clave id, un atributo

name para el nombre que toma la función, has_return indica si la función devuelve

algún valor y help es la ayuda en línea para el usuario sobre cómo utilizar esa

función. La última entidad, denominada PARAMETER (parámetro) representa a

cada parámetro que toma una función con su nombre (atributo name) y clave (id).


128

Cada habitación puede ejecutar 0 ó más funciones mientras que cada función está

disponible en 0 ó más habitaciones (relación Ejecuta). Asimismo, cada función

puede tener 0 ó más parámetros mientras que cada parámetro está relacionado

con una y sólo una función.

A partir de estas entidades se construirán las tablas correspondientes que serán

explotadas principalmente por el subsistema Editor de Diagramas.

El acceso a dichas tablas permitirá llenar los cuadros de diálogo especificados en

2.2.8.4. Especificación del Comportamiento Dinámico de la Interfaz.

Teniendo en cuenta que el motor de base de datos a utilizar es MySQL (ver 2.2.1.2.

Identificación del Entorno Tecnológico), las sentencias para generación de las

tablas serían:

CREATE TABLE files( id INT NOT NULL AUTO_INCREMENT PRIMARY

KEY , name VARCHAR(50), content TEXT, active INT NOT NULL)

ENGINE=InnoDB;

CREATE TABLE rooms (id INT NOT NULL PRIMARY KEY , name VARCHAR(50)) ENGINE=InnoDB; CREATE TABLE functions (id INT NOT NULL PRIMARY KEY, name VARCHAR(50), help VARCHAR(200), has_return INT NOT NULL ) ENGINE=InnoDB; CREATE TABLE parameters(id INT NOT NULL PRIMARY KEY, name VARCHAR(50)) ENGINE=InnoDB; CREATE TABLE rooms_functions (id_room INT NOT NULL REFERENCES rooms(id) ON UPDATE CASCADE ON DELETE CASCADE, id_function INT NOT NULL REFERENCES functions(id) ON UPDATE CASCADE ON DELETE CASCADE, PRIMARY KEY(id_room, id_function)) ENGINE=InnoDB; CREATE TABLE functions_parameters (id_function INT NOT NULL REFERENCES functions(id) ON UPDATE CASCADE ON DELETE CASCADE, id_parameter INT NOT NULL REFERENCES parameters(id) ON UPDATE CASCADE ON DELETE CASCADE, PRIMARY KEY(id_function, id_parameter)) ENGINE=InnoDB;

La tabla rooms_functions representa la relación Ejecuta mientras que la tabla

functions_parameters representa la relación Recibe.


129

A.1.3.6.2. Especificación de los Caminos de Acceso a los Datos

El objetivo de esta tarea es determinar los caminos de acceso a los datos

persistentes del sistema, utilizados por los principales módulos/clases de acuerdo

al modelo físico de datos, con el fin de optimizar el rendimiento de los gestores de

datos o sistemas de ficheros y el consumo de recursos, así como disminuir los

tiempos de respuesta.

A continuación, se especificarán los caminos para obtener datos desde la Base de

Datos:

a. Lista de archivos (diagramas) almacenados (cuadros Abrir, Guardar y

Guardar como)

Requieren el acceso a una única tabla (files), los datos deben ser leídos,

serializados a XML por parte del mediador (archivo) entre la Base MySQL y

la interfaz web (Flex), la cual mostrará el listado en pantalla.

b. Guardar archivo (diagrama)

A partir del ítem anterior, es necesario un único acceso a la tabla files para

guardar el nuevo archivo con un nuevo id ó guardar un archivo existente

con su correspondiente id.

c. Lista de archivos (diagramas) almacenados y activados/desactivados

(cuadro Administrar Diagramas)

Requiere el acceso a una única tabla (files), los datos deben ser leídos,

serializados a XML por parte del mediador (archivo) entre la Base MySQL y

la interfaz web (Flex), la cual mostrará el listado en pantalla y cuáles se

encuentran activados y cuáles no.


130

d. Recuperar funciones domóticas disponibles, con sus parámetros y en qué

habitaciones pueden ejecutarse

En este caso, es necesario acceder a 5 tablas (rooms, functions,

parameters, rooms_functions y functions_parameters), los datos deben ser

leídos, serializados a XML por parte del mediador (archivo) entre la Base

MySQL y la interfaz web (Flex), la cual mostrará el listado en pantalla y

cuáles se encuentran activados y cuáles no.

A continuación, se evaluará si conviene desnormalizar para acelerar la

performance.

A.1.3.6.3. Optimización del Modelo Físico de los Datos

En esta tarea se decidirá si optimizar el diseño físico de datos, con el objetivo de

mejorar el tiempo de respuesta en el acceso a datos persistentes, hacer una

adecuada utilización de los recursos del sistema y, en consecuencia, garantizar que

el diseño satisface las necesidades de tratamiento establecidas para el sistema de

información en cuanto a que se ajusta a los requisitos de rendimiento exigidos.

Dados los caminos de accesos definidos en el 2.3.6.2, el único que puede ser

mejorado (aquel con una cantidad de accesos mayor a uno) es d. Teniendo en

cuenta la naturaleza del Trabajo Profesional, la arquitectura decidida para el

sistema, los requerimientos funcionales antes expresados y el hecho de que las

funciones domóticas son como mucho un par de decenas, se decidió mantener la

estructura normalizada descrita en 2.3.6.1. Además, no existirán gran cantidad de

accesos concurrentes (este sistema corre en el entorno de una vivienda y

automatiza las tareas para esa en particular, podrán existir accesos remotos pero

pocas personas –los habitantes de la misma‐ serán los interesados en utilizar el

Editor de Diagramas).


131

A.1.3.6.4. Especificación de la Distribución de Datos

El Gestor de Datos con las tablas antes mencionadas en la Actividad, estará

ubicado en el Servidor que puede verse en el Diagrama de Arquitectura, en la

actividad 2.3.1. Definición de la Arquitectura del Sistema.

A.1.3.7. Verificación y Aceptación de la Arquitectura del Sistema

El objetivo de esta actividad es garantizar la calidad de las especificaciones del diseño

del sistema de información y la viabilidad del mismo, como paso previo a la generación

de las especificaciones de construcción.

A.1.3.7.1. Verificación de las Especificaciones de Diseño

El grupo de trabajo verificó cada uno de los modelos generados y se comprobó

que éstos estaban de acuerdo a las técnicas seguidas para la elaboración de cada

producto.

A.1.3.7.2. Análisis de Consistencia de las Especificaciones de

Diseño

En esta tarea, el grupo de trabajo verificó que las especificaciones de diseño

fueran coherentes entre sí y que carezcan de ambigüedades o duplicación de

información. Pudo asegurarse, entonces, la consistencia entre las especificaciones

de diseño y los modelos del análisis.

A.1.3.7.3. Aceptación de la Arquitectura del Sistema

Los Directores del presente Trabajo Profesional aceptaron la arquitectura

presentada del sistema, y sus sugerencias fueron incorporadas en la descripción de

las anteriores tareas de Diseño de este informe.


132

A.1.3.8. Generación de las Especificaciones de Construcción

En esta actividad se generarán las especificaciones para la construcción del sistema de

información, a partir del diseño detallado.

Estas especificaciones definen la construcción del sistema de información a partir de

las unidades básicas de construcción (componentes), entendiendo como tales

unidades independientes y coherentes de construcción y ejecución, que se

corresponden con un empaquetamiento físico de los elementos del diseño de detalle,

como pueden ser módulos, clases o especificaciones de interfaz.

A.1.3.8.1. Especificación del Entorno de Construcción

En esta tarea se definirá el entorno necesario para la construcción de los

componentes del sistema de información, en cuanto a hardware, software,

comunicaciones y herramientas de construcción.

El entorno de construcción de este Trabajo Profesional está limitado a los recursos

disponibles por parte del alumno, pudiendo mencionar:

• Hardware

o Una PC (Intel Core Duo 1,6 GHz, 2GB RAM, Disco de 80 GB, Resolución 1280 x 800 píxeles)

• Software

o Windows XP SP2 Professional

o Microsoft Virtual PC 6.0

o Navegadores web (Internet Explorer 7, Mozilla Firefox 2.0, Google Chrome 1.0)

o EasyPHP 1.8 (Apache 1.3.x, Base de Datos MySQL 4.1.x, PHP 4.3.x)

o Adobe Flash Player 9


133

o Herramientas de construcción

Java 1.6 (JDK 1.6.0.11)

CLIPS (versión 6.3)

IDE Eclipse (3.3.0) con FlexBuilder 3 Plug‐in

Nullsoft Scriptable Install System versión 2.44 (Generador

de instaladores)

• Comunicaciones

o Conexión a Internet por Banda Ancha a 1 Mbps

A.1.3.8.2. Definición de Componentes y Subsistemas de

Construcción

En esta tarea, se definieron a los subsistemas de diseño como subsistemas de

construcción, es decir, existirán cinco subsistemas de construcción:

1. Editor de Diagramas

2. Generador de Código

3. Simulador y visualizador de eventos

4. Emulador de las variables del hogar, estado de la casa

5. Ejecutor de Código

Los subsistemas 1 y 3 serán construidos en Flex para ser utilizados a través del

navegador web, desde el lado Cliente del sistema.

El resto de los subsistemas serán construidos como programas independientes en

Java, formando el lado Servidor del sistema.

La comunicación para sincronización y notificación de eventos entre los

subsistemas del Servidor será vía el protocolo TCP/IP mediante el formato

apropiado mientras que la comunicación entre los subsistemas del lado Cliente

con los del lado Servidor será estrictamente vía el protocolo HTTP, desarrollándose

los archivos PHP necesarios para brindar los Web Services apropiados.


134

A.1.3.9. Diseño de la Migración

Esta actividad sólo se lleva a cabo cuando es necesaria una carga inicial de

información, o una migración de datos de otros sistemas, cuyo alcance y estrategia a

seguir se habrá establecido previamente.

Para ello, se toma como referencia el plan de migración y carga inicial de datos, que

recoge las estructuras físicas de datos del sistema o sistemas origen implicadas en la

conversión, la prioridad en las cargas y secuencia a seguir, las necesidades previas de

depuración de la información, así como los requisitos necesarios para garantizar la

correcta implementación de los procedimientos de migración sin comprometer el

funcionamiento de los sistemas actuales.

En este Trabajo, como no existe migración de datos de otros sistemas, sólo se

trabajará en esta actividad la carga inicial de datos.

A.1.3.9.1. Diseño de Procedimientos de Carga Inicial

En esta tarea se definirán los procedimientos necesarios para llevar a cabo la carga

inicial de datos del sistema.

Como punto de partida se tiene en cuenta, junto con los requisitos y

especificaciones de carga inicial, el modelo físico de datos optimizado y su

localización en los nodos, así como la definición del entorno tecnológico del


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.


135

• Deberá desarrollarse un programa que a partir del nombre de usuario y

contraseña (especificados por quien está instalando el sistema), se

encargue de generar las tablas correspondientes y cargar los datos

iniciales, sin mayor intervención que mantener el motor de la base de

datos activo.

• En caso de existir las tablas, deberán descartarse y crearse y llenarse desde

cero.

• Ante la eventual desinstalación del lado Servidor, las tablas y sus datos

deberán permanecer almacenadas.

• Las tablas deberán ser creadas y posteriormente llenadas en este orden:

rooms, functions, parameters, rooms_functions y functions_parameters. La

tabla files que contiene los diagramas deberá ser inicializada antes que

todas y sin registros.

A.1.3.10. Especificación Técnica del Plan de Pruebas

En esta actividad se realizará la especificación de detalle del plan de pruebas del

sistema de información para cada uno de los niveles de prueba establecidos en el

proceso Análisis del Sistema de Información:

• Pruebas unitarias

• Pruebas de integración

• Pruebas del sistema

• Pruebas de implantación

• Pruebas de aceptación

Para ello se toma como referencia el plan de pruebas, que recoge los objetivos de la

prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del

marco adecuado para planificar paso a paso las actividades de prueba.


136

A.1.3.10.1. Especificación del Entorno de Pruebas

En esta tarea se definirá el entorno necesario para la realización de las pruebas del

sistema: unitarias, de integración, de implantación y de aceptación.

El objetivo de esta tarea ya fue cubierto en la Etapa de Análisis, en el punto

2.2.10.2. Definición de Requisitos del Entorno de Pruebas.

A.1.3.10.2. Especificación Técnica de los Niveles de Prueba

En esta tarea se realizará la descripción de los principios técnicos que guiarán a

cada uno de los niveles de las pruebas:

• Pruebas Unitarias de las Clases

Las Pruebas Unitarias de las Clases o unit testing se limitará, como ya se

mencionó en la fase de análisis, a aquellas clases que provean servicios

fundamentales para que el sistema cumpla su objetivo en el lado Servidor,

esto significa que se probarán en particular las clases dedicadas a la

interpretación del diagrama, generación y ejecución del programa y las

funciones. Para ello se usará JUnit. El lado cliente de la aplicación, dado su

carácter netamente interactivo y visual, impide la automatización de las

pruebas, con lo cual las clases de los subsistemas que lo componen serán

probadas a través de pruebas de integración y de sistema.

• Pruebas de Integración

Las Pruebas de Integración tendrán como objetivo asegurar que los distintos

subsistemas reciban la información en el formato esperado y que su salida esté

acorde a la esperada por el subsistema que depende del primero. Se verificará

entonces, que al generar un diagrama, este puede ser interpretado

correctamente y que se genere un programa capaz de ser interpretado por el

motor de inferencias y que las funciones utilizadas se ejecuten correctamente.


137

• Pruebas de Sistema

Las pruebas de sistema tendrán como objetivo verificar todo el proceso, desde

la generación del diagrama, el guardado, una eventual reapertura, la

generación del programa, la puesta en espera para ejecución del mismo y la

activación correspondiente con su comprobación en el simulador de las

acciones tomadas.

• Pruebas de Aceptación del Sistema

Las pruebas de Aceptación del Sistema son similares a las Pruebas de Sistema

pero las primeras se realizan en presencia de los Directores del Trabajo

Profesional.

A.1.3.11. Establecimiento de Requisitos de Implantación

En esta actividad se completará el catálogo de requisitos con aquellos relacionados con

la documentación que el usuario requiere para operar con el nuevo sistema, y los

relativos a la propia implantación del sistema en el entorno de operación.

La incorporación de estos requisitos permite ir preparando, los medios y recursos

necesarios para que los usuarios, tanto finales como de operación, sean capaces de

utilizar el nueva sistema de forma satisfactoria.

A.1.3.11.1. Especificación de los Requisitos de Documentación

de Usuario

En esta tarea se recogerá toda la información necesaria para la especificación de la

documentación a entregar al usuario.

La documentación a entregar al Usuario consistirá en un archivo de ayuda por cada

uno de los subsistemas generado, en formato de Ayuda Compilada en HTML

(CHM), pudiéndose instalar del lado servidor desde el instalador. Adicionalmente,

podrá instalarse esta documentación de ayuda del lado Cliente en formato HTML

plano, y así ser accesible a través de la Web desde el Editor de Diagramas y/o

Simulador.


138

A.1.3.11.2. Especificación de Requisitos de Implantación

En esta tarea se especificarán de forma detallada los requisitos de implantación,

generalmente relacionados con la formación, infraestructura e instalación, con el

fin de preparar y organizar, con la antelación suficiente, todos los recursos

necesarios para la implantación e instalación del sistema de información.

Requisitos de Formación

Los requisitos de formación del usuario de este sistema (lado Cliente) son

conocimientos básicos de diagramas de flujo, manejo de PC e Internet. Del lado

servidor, para la instalación del sistema y puesta en marcha, es deseable que

posea conocimientos de instalación y configuración de un servidor Web y Base de

Datos así como experiencia en programación; sin embargo estas tareas pueden

ser llevadas adelante por un técnico que realice dicha configuración inicial.

Requisitos de Infraestructura e Instalación

El lado servidor de la aplicación deberá poder ejecutarse en una PC con un

procesador de 800 MHz o superior, con al menos 512 MB de RAM y 30 MB de

espacio libre en el disco para la instalación del sistema. Deberá tener instalado por

lo menos un browser (Internet Explorer 7, Mozilla Firefox 2.0, Google Chrome 1.0

ó superiores), un Web Server (Apache 1.3 recomendado), Base de Datos (MySQL

4.1 recomendado), PHP (4.3 recomendado), Adobe Flash plug‐in versión 9 o

superior y Java 1.6 o superior. Una conexión a internet de banda ancha es un

requisito deseable (en particular, si se desea acceder al sistema desde fuera del

hogar) pero no imprescindible (caso contrario, puede programarse desde el mismo

servidor).


139

A.1.3.12. Aprobación del Diseño del Sistema de Información

A.1.3.12.1. Presentación y Aprobación del Sistema de

Información

Los directores del Trabajo Profesional revisaron y aprobaron el Diseño del Sistema

de Información presentado en esta Etapa que figura en el presente informe.


140

A.1.4. Construcción del Sistema de Información

En este proceso se genera el código de los componentes del Sistema de Información, se

desarrollarán todos los procedimientos de operación y seguridad y se elaborarán todos los

manuales de usuario final y de explotación con el objetivo de asegurar el correcto

funcionamiento del Sistema para su posterior implantación.

A.1.4.1. Preparación del Entorno de Generación y Construcción

El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y

facilidades para que se pueda llevar a cabo la construcción del sistema de información.

Entre estos medios, cabe destacar la preparación de los puestos de trabajo, equipos

físicos y lógicos, gestores de bases de datos, bibliotecas de programas, herramientas

de generación de código, bases de datos o ficheros de prueba, entre otros.

A.1.4.1.1. Preparación del Entorno de Generación y

Construcción

En esta tarea se procederá a:

• Crear los elementos del sistema gestor de base de datos o sistema de

ficheros.

• Reservar el espacio de almacenamiento, definiendo, entre otros, los

dispositivos físicos a emplear, tamaño de los bloques, tipo de registro

físico, zona de desbordamiento, opciones de almacenamiento de datos,

etc.

• Inicializar la base de datos o ficheros, cargando los datos considerados

necesarios en el espacio de almacenamiento previamente definido.

Base de Datos

En la base de datos se almacenarán los diagramas creados por el usuario y se

recuperará la información de que funciones domóticas están disponibles en

cuál o cuáles habitaciones y que parámetros toman. A continuación se detalla

el script de creación de la base de datos.


141

CREATE DATABASE newport;

USE newport;

CREATE TABLE files( id INT NOT NULL AUTO_INCREMENT

PRIMARY KEY , nombre VARCHAR(50), content TEXT, active

INT NOT NULL) ENGINE=InnoDB;

CREATE TABLE rooms (id INT NOT NULL PRIMARY KEY , name

VARCHAR(50)) ENGINE=InnoDB;

CREATE TABLE functions (id INT NOT NULL PRIMARY KEY,

name VARCHAR(50), help VARCHAR(200), has_return INT NOT

NULL ) ENGINE=InnoDB;

CREATE TABLE parameters(id INT NOT NULL PRIMARY KEY,

name VARCHAR(50)) ENGINE=InnoDB;

CREATE TABLE rooms_functions (id_room INT NOT NULL

REFERENCES rooms(id) ON UPDATE CASCADE ON DELETE

CASCADE, id_function INT NOT NULL REFERENCES

functions(id) ON UPDATE CASCADE ON DELETE CASCADE,

PRIMARY KEY(id_room, id_function)) ENGINE=InnoDB;

CREATE TABLE functions_parameters (id_function INT NOT

NULL REFERENCES functions(id) ON UPDATE CASCADE ON

DELETE CASCADE, id_parameter INT NOT NULL REFERENCES

parameters(id) ON UPDATE CASCADE ON DELETE CASCADE,

PRIMARY KEY(id_function, id_parameter)) ENGINE=InnoDB;

En la tabla files figurarán un registro por cada diagrama salvado por el usuario,

el campo content representa el contenido del diagrama en formato XML (dicho

formato se explicará en detalle más adelante en este punto). Esta tabla se

inicializará vacía al momento de la carga de inicial de datos.

El resto de las tablas corresponden a las funciones domóticas con los

parámetros que toma cada una de ellas y en que habitaciones de la vivienda

están disponibles.


142

A continuación se detallarán cada una de estas funciones:

Nombre de la función

Descripción Parámetro(s) Disponible

en: Devuelve

luz Ajusta la intensidad de la luz de una habitación

Intensidad (entero 0..10)

Living Cocina

Comedor Baño

Dormitorio Garage

‐

fijarTemperatura

Fija la temperatura de la habitación seleccionada

Valor (entero 20..30)

Living Cocina

Comedor Baño

Dormitorio Garage

‐

enviarSMS Envía un mensaje de texto mensaje a un número de teléfono nro

• Nro (entero) • Mensaje (texto)

General ‐

regadores Activa los regadores con la intensidad especificada

Intensidad (entero 0..10)

Patio ‐

activarAlarma Dispara la alarma de la vivienda

‐ General ‐

incrementar Incrementa en 1 el valor del parámetro valor

Valor (entero) General Valor

incrementado en 1

suma Suma dos valores

• Sumando1 • Sumando2 (enteros)

General Sumando1

+ Sumando2

abrirPorton Abre el portón del Garage

‐ Garage ‐

cerrarPorton Cierra el portón del Garage

‐ Garage ‐

obtTemperatura Devuelve la temperatura en grados centígrados de la habitación seleccionada

‐

Living Cocina

Comedor Baño

Dormitorio Garage

Temperatura de la

habitación en °C

encenderMicroondas

Activa el horno a microondas con la intensidad y durante el tiempo determinado

• cantSegundos (entero): cantidad de segundos de cocción

• intensidad (entero 0..10): intensidad

Cocina ‐


143

de cocción debug Despliega un

mensaje (paramDebug1 concatenado con paramDebug2) en la consola de eventos del simulador

• paramDebug1 (texto)

• paramDebug2 (texto)

General ‐

resta

Resta dos valores

• Minuendo (entero)

• Sustraendo (entero)

General Minuendo

‐ Sustraendo

NOT

Niega a valor Valor (entero) General

• Cero si valor es

distinto de 0

• Uno si valor es igual a 0

grabarTV Graba el canal de TV especificado durante la cantidad de minutos solicitada

• Canal (entero)

• DuracionMin (duración de la grabación en minutos

Living ‐

Formatos de Archivo a Utilizar

La forma de intercambio de datos entre subsistemas será a partir de archivos

XML, con lo cual, a continuación se definirán las estructuras de los principales,

utilizando XSD Schema.

• Archivos generados por el editor de diagramas

Estos archivos son generados al guardar un diagrama en la base de

datos y son almacenados en el campo content de cada registro de la

tabla files. Para abrir un diagrama, se recupera a un archivo por id de

la tabla files, se interpreta el content y se regenera el diagrama

correspondiente. La definición formal con el XSD Schema es:


144

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="file"> <xs:complexType> <xs:sequence> <xs:element name="diagrama"> <xs:complexType> <xs:sequence> <xs:element name="figura" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="left" type="xs:integer"/> <xs:element name="top" type="xs:integer"/> <xs:element name="width" type="xs:integer"/> <xs:element name="height" type="xs:integer"/> <xs:element name="label" type="xs:string"/> <xs:element name="tooltip" type="xs:string" /> <xs:element name="siguiente" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="destino" type="xs:integer" use="required"/> </xs:complexType> </xs:element> <xs:element name="verdadero" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="destino" type="xs:integer" use="required"/> </xs:complexType> </xs:element> <xs:element name="falso" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="destino" type="xs:integer" use="required"/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="type" type="xs:string" use="required"/> <xs:attribute name="id" type="xs:integer" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="programa"> <xs:complexType> <xs:sequence> <xs:element name="start_id" type="xs:integer" minOccurs="0" maxOccurs="1"/> <xs:element name="block" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:any/> </xs:sequence> <xs:attribute name="type" type="xs:string" use="required"/> <xs:attribute name="id" type="xs:integer" use="required"/> <xs:attribute name="next" type="xs:integer"/> <xs:attribute name="verdadero" type="xs:integer"/> <xs:attribute name="falso" type="xs:integer"/> </xs:complexType>


145

</xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="mapper"> <xs:complexType> <xs:sequence> <xs:element name="item" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="figura" type="xs:string"/> <xs:element name="bloque" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

Gráficamente, usando el Visual Studio, se aprecia que la estructura del XML que se generará es

sencilla:

Cada elemento del XML está representado como un rectángulo, y cada uno a su vez puede

contener atributos o/y otros elementos. De la figura, puede deducirse que el elemento

principal del XML es file y contiene tres elementos: diagrama, programa y mapper. El primero

contiene 0 ó más figuras, una por cada figura de la Vista que forma el diagrama de flujo. Las

figuras pueden estar conectadas entre sí por medio de los elementos siguiente, verdadero y


146

falso y allí especificando como atributo el id de la figura destino. El elemento programa es al

Modelo del editor de diagramas lo que diagrama es a la Vista. Contiene 0 o más elementos

block con las características de un bloque de código (configuración establecida por el usuario).

Los bloques pueden unirse usando los atributos next, verdadero y falso con el id de la figura

destino.

Finalmente, el elemento mapper contiene a su vez elementos (0 ó más) item, que mantienen

la correspondencia entre cada figura de la vista y bloque del modelo.

• Archivos de intercambio entre Editor de Diagramas y Base de Datos

El editor de diagramas del lado cliente utiliza archivos XML para recibir

información proveniente del servidor. Esta información es la necesaria

para llenar los cuadros Abrir Diagrama, Guardar Diagrama, Administrar

Diagrama y el listado de funciones disponibles.

Abrir, Guardar y Administrar Diagrama, listan los archivos disponibles a

partir de un XML que sigue el siguiente Schema:

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="filesystem"> <xs:complexType> <xs:sequence> <xs:element name="files"> <xs:complexType> <xs:sequence> <xs:element name="file" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="id" type="xs:integer"/> <xs:element name="active" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>


147

Gráficamente,

El formato del XML consta de un elemento filesystem que tiene a su vez un elemento files que

tiene 0 ó más elementos file que contienen name (nombre), id (ID del archivo), active (indica si

un diagrama está activo –si/no‐).

Las funciones disponibles para ejecutar en un diagrama, se listan a partir

de un XML que sigue el siguiente Schema:

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="response"> <xs:complexType> <xs:sequence> <xs:element name="success"> <xs:complexType> <xs:attribute name="value" type="xs:integer" use="required" /> </xs:complexType> </xs:element> <xs:element name="data"> <xs:complexType> <xs:sequence> <xs:element name="room" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="func" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="help" type="xs:string" /> <xs:element name="param" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="id" type="xs:integer" use="required" /> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="id" type="xs:integer" use="required" /> <xs:attribute name="has_return" type="xs:integer" use="required" /> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> </xs:element> </xs:sequence>


148

<xs:attribute name="id" type="xs:integer" use="required" /> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

Gráficamente:

Como aparece en la figura, la estructura consta de un elemento response, que contiene un

elemento success y un elemento data y éste último contiene 0 ó más room (habitación) con 0

ó más func (función), la cual puede tener 0 ó más param (parámetro).

Respuestas de acciones en el servidor, recibidas por el lado cliente:

Ejemplos de estas respuestas son: notificación al editor de que el diagrama

fue correctamente almacenado, que el diagrama fue ejecutado

satisfactoriamente, entre otros. El Schema correspondiente es:

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="response"> <xs:complexType> <xs:sequence> <xs:element name="success"> <xs:complexType> <xs:attribute name="value" type="xs:integer" /> </xs:complexType> </xs:element> <xs:element name="error" minOccur="0" maxOccur="1"> <xs:complexType> <xs:sequence> <xs:element name="description" type="xs:string" /> </xs:sequence> <xs:attribute name="number" type="xs:integer" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>


149

Gráficamente,

En la figura, el elemento response contiene un elemento success (que posee un atributo

numérico que indica si la operación se efectuó con éxito ‐1‐ ó no ‐0‐) y opcionalmente un

elemento error (con description que describe el error en forma de texto y un atributo number

que representa el código de error asociado).

• Archivos de intercambio entre el Lado Servidor y Simulador

Los eventos en la vivienda son reportados del servidor hacia el cliente en

un XML que se ajusta al siguiente esquema:

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="response"> <xs:complexType> <xs:sequence> <xs:element name="success"> <xs:complexType> <xs:attribute name="value" type="xs:integer" use="required" /> </xs:complexType> </xs:element> <xs:element name="error" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="description" type="xs:string" /> </xs:sequence> <xs:attribute name="number" type="xs:integer" use="required" /> </xs:complexType> </xs:element> <xs:element name="log" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="entry" minOccurs="0" maxOccurs="unbounded"> <xs:complexType>


150

<xs:sequence> <xs:element name="date" type="xs:string" /> <xs:element name="message" type="xs:string" /> <xs:any /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="time" type="xs:integer" use="required" /> <xs:attribute name="timeLastEntry" type="xs:integer" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

Gráficamente,

En la imagen, se aprecia que el elemento principal del XML es response, el cual está

compuesto por un elemento success cuyo valor es 1 si no hubo errores, 0 en caso contrario. En

este último caso, response tiene otro elemento llamado error (con descripción y número de

error). En cualquier caso, response tiene un elemento log (donde figuran 0 ó más entry con la

descripción de cada evento generado) y dos atributos que marcan el tiempo en el que el

último entry fue generado al log (atributo timeLastEntry) y el tiempo en el que fue generado el

XML (atributo time).

• Archivos en el Lado Servidor necesarios para la ejecución de los

diagramas


151

Cuando el subsistema CodeGen toma el diagrama y genera el código

ejecutable, está armando en paralelo dos archivos: uno con el código

ejecutable en reglas del sistema experto (CLIPS) y el otro con las

condiciones de activación de dicho programa (hora, día de la semana,

activación de algún sensor externo). Se describirá primero el archivo

con las condiciones por su sencillez y posteriormente al archivo con las

reglas generadas a partir del diagrama.

Archivo de Condiciones de Ejecución (.cond)

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="start"> <xs:complexType> <xs:sequence> <xs:element name="options"> <xs:complexType> <xs:attribute name="days" type="xs:boolean" use="required" /> <xs:attribute name="time" type="xs:boolean" use="required" /> <xs:attribute name="triggers" type="xs:boolean" use="required" /> </xs:complexType> </xs:element> <xs:element name="days"> <xs:complexType> <xs:attribute name="sun" type="xs:boolean" use="required" /> <xs:attribute name="mon" type="xs:boolean" use="required" /> <xs:attribute name="tue" type="xs:boolean" use="required" /> <xs:attribute name="wed" type="xs:boolean" use="required" /> <xs:attribute name="thru" type="xs:boolean" use="required" /> <xs:attribute name="fri" type="xs:boolean" use="required" /> <xs:attribute name="sat" type="xs:boolean" use="required" /> </xs:complexType> </xs:element> <xs:element name="trigs"> <xs:complexType> <xs:attribute name="sunrise" type="xs:boolean" use="required" /> <xs:attribute name="sunset" type="xs:boolean" use="required" /> <xs:attribute name="door" type="xs:boolean" use="required" /> <xs:attribute name="alarm" type="xs:boolean" use="required" /> </xs:complexType> </xs:element> <xs:element name="time"> <xs:complexType> <xs:attribute name="hr" type="xs:integer" use="required" /> <xs:attribute name="min" type="xs:integer" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>


152

Gráficamente,

La estructura del XML, como puede verse, consta de un elemento start que contiene cuatro

elementos: options, days, trigs y time. El elemento options tiene tres atributos: days, time y

triggers. El primero (si es true) indica que el programa asociado deberá ejecutarse ciertos días

de la semana. El segundo (si es true) determina que el programa se ejecute a cierta hora del

día. El último (si es true) establece que el programa se ejecutará ante la activación de algún

sensor externo.

Los siguientes elementos están siempre presentes en el XML aunque su interpretación por

parte del subsistema Executer depende del valor de los atributos previamente mencionados.

El elemento days tiene siete atributos (uno por cada día de la semana) que toman el valor true

si el usuario definió que el programa se ejecute ese día.

El elemento time tiene dos atributos que indican la hora y minutos (formato 24 horas) en el

cual ejecutar el programa.

Finalmente, el elemento trigs tiene cuatro atributos uno por cada sensor externo (detección

de amanecer y de anochecer, alarma y timbre, respectivamente) que están en true si el

programa debe ejecutarse ante la activación del sensor correspondiente.


153

Archivos de Código Ejecutable como Reglas de Sistema Experto (.clp)

Como ya se mencionó en este informe, los diagramas generados en el

editor son almacenados como tales en la Base de Datos y,

paralelamente a esto, se genera el programa correspondiente a ese

diagrama. Dicho programa está formado por una serie de reglas de

sistema experto y una serie de hechos que son agregados

convenientemente a la base de conocimientos. Cada programa corre

con una base de conocimientos independiente del resto.

Para mayor información acerca de Programación de Sistemas Expertos,

se recomienda consultar la bibliografía que figura al final del presente

informe.

Dada la naturaleza de un diagrama de flujo, su conversión a un

programa estructurado es inmediata. Sin embargo, la conversión del

diagrama a un programa escrito en un lenguaje de sistema experto

como CLIPS es un poco más elaborada. A modo de ejemplo, se tomará

un diagrama de flujo sencillo, que puede ser generado con el Editor de

Diagramas y se explicarán las reglas básicas para la conversión a

código.


154

La idea básica es que se genera una regla Ri por cada bloque i del diagrama de arriba (es decir,

por cada Asignación y cada Condición, la figura Comienzo solo marca el punto de arranque de

ejecución y condiciones que se utilizan para generar el archivo .cond, las figuras Fin están

presentes sólo por claridad). Dicha regla tiene como precondición para ejecutarse la existencia

de un hecho Fi en la base de conocimientos. Para que la regla Rj (que corresponde al siguiente

bloque que debe ejecutarse) se dispare efectivamente, Ri tiene como una de sus

postcondiciones la inserción de un hecho Fj y la remoción de Fi.

Pseudocódigo:

Regla Ri: Precondiciones: Ri, … Poscondiciones: InsertarHecho(Rj), EliminarHecho(Ri), …

En el archivo, la regla R0 que inicia la ejecución no tiene ningún hecho asociado, de modo que

se dispare inmediatamente al iniciar la ejecución, luego inserta un hecho F1 para que R1 se

ejecute. La regla R1 y las siguientes operan como se mencionó previamente al pseudocódigo.

Los bloques de condición son representados como dos reglas: en este caso se genera una R2T (por true) y una R2F (por false) donde la condición de comparación de T y F son opuestas.

Pseudocódigo:

Regla R2T: Precondiciones: Ri,(a < 11), … Poscondiciones: InsertarHecho(Rj), EliminarHecho(Ri), …

Regla R2F: Precondiciones: Ri,(a >= 11), … Poscondiciones: InsertarHecho(Rk), EliminarHecho(Ri), …

Las constantes del diagrama son representadas como constantes en las reglas mientras que las

variables del diagrama son representadas como hechos que se insertan en la base de

conocimientos. Como primera regla, se inicializan todas las variables usadas en el diagrama

como vacías (“”).

Cuando se utiliza una función, la regla se divide en dos: en primera instancia una regla Ri1 se

insertan ciertos hechos a la base que corresponden a la identificación de la función a ejecutar

así como los valores de sus parámetros y se invoca el comando break que detiene la ejecución


155

de las reglas. El programa en Java encargado de la ejecución, determina en función de los

hechos la razón de la detención (se invoca la ejecución de una función como debug), ejecuta la

función, obtiene un resultado e inserta un hecho con el resultado de la función. Luego reanuda

la ejecución del programa la cual continúa en la regla Ri2.

En el programa en CLIPS además se agregan ciertas funciones macro definidas para simplificar

la escritura de las reglas. Cabe destacar que las sentencias (cada sentencia se encuentra

enmarcada entre paréntesis) en CLIPS no se ejecutan en orden de arriba hacia abajo, ya que la

ejecución depende de los hechos presentes en la base de conocimientos.

A continuación, se transcribe el programa de ejemplo ya procesado por CodeGen, en código CLIPS: (deftemplate var (slot name) (slot value)) (deftemplate func (slot value) (slot idRoom) (slot idFunc) (multislot params)) (deftemplate request (slot reason)) (deffunction var_assert (?name ?new_val) (do-for-all-facts( (?v var)) (eq ?v:name ?name) (retract ?v)) (assert (var (name ?name) (value ?new_val))) ) (deffunction toNum (?value) (if (integerp ?value) then ?value else 0 )) (deffunction func_assert_value (?idRoom ?idFunc ?new_val) (do-for-fact( (?f func)) (eq ?f:idRoom ?idRoom) (eq ?f:idFunc ?idFunc) (assert (func (value ?new_val) (idRoom ?f:idRoom) (idFunc ?f:idFunc) (params ?f:params) )) (retract ?f)) ) (defrule rule_init => (var_assert a "") (var_assert b "")


156

(assert (fact_rule0)) ) (defrule rule0 ?id <- (fact_rule0) => ;(printout t "ejecutando comienzo rule0" crlf) (retract ?id) (assert (fact_rule0_showFilename))) (defrule rule1 ?id <- (fact_rule1) => ;(printout t "ejecutando asignacion rule1" crlf) (retract ?id) (var_assert a 26) (assert (fact_rule2))) (defrule rule2T ?id <- (fact_rule2) (var (name a) (value ?valor_a)) (test ( < (toNum ?valor_a) (toNum 11))) => ;(printout t "ejecutando condicion TRUE rule2" crlf) (retract ?id) (assert (fact_rule3))) (defrule rule2F ?id <- (fact_rule2) (var (name a) (value ?valor_a)) (not (test ( < (toNum ?valor_a) (toNum 11))) ) => ;(printout t "ejecutando condicion FALSE rule2" crlf) (retract ?id) (assert (fact_rule4))) (defrule rule3 ?id <- (fact_rule3) => ;(printout t "ejecutando asignacion rule3" crlf) (retract ?id) (var_assert b 1) (assert (fact_rule6))) (defrule rule4 ?id <- (fact_rule4) => ;(printout t "ejecutando asignacion rule4" crlf) (retract ?id) (var_assert b 2) (assert (fact_rule6))) (defrule rule5 ?id <- (fact_rule5) => ;(printout t "ejecutando fin rule5" crlf) (retract ?id)) (defrule rule6 ?id <- (fact_rule6) (var (name b) (value ?par_b_1_12)) => ;(printout t "ejecutando asignacion - funcion rule6" crlf) (assert (request (reason func))) (assert (func (idRoom 1) (idFunc 12) (params "b vale" ?par_b_1_12 ) )) (retract ?id)


157

(assert (fact_rule6_1)) (set-break rule6_1)) (defrule rule6_1 ?id <- (fact_rule6_1) ?id_func_1_12<-(func (idRoom 1) (idFunc 12) (value ?valor_func_1_12)) => ;(printout t "ejecutando asignacion rule6_1" crlf) (retract ?id) (retract ?id_func_1_12) (assert (fact_rule5))) (defrule rule0_showFilename ?id <- (fact_rule0_showFilename) => ;(printout t "ejecutando asignacion - funcion rule0_showFilename" crlf) (assert (request (reason func))) (assert (func (idRoom 1) (idFunc 12) (params "Ejecutando el archivo: " "demo" ) )) (retract ?id) (assert (fact_rule0_showFilename_1)) (set-break rule0_showFilename_1)) (defrule rule0_showFilename_1 ?id <- (fact_rule0_showFilename_1) ?id_func_1_12<-(func (idRoom 1) (idFunc 12) (value ?valor_func_1_12)) => ;(printout t "ejecutando asignacion rule0_showFilename_1" crlf) (retract ?id) (retract ?id_func_1_12) (assert (fact_rule1))) Formato de Mensajes entre Subsistemas del Servidor

Los distintos subsistemas del servidor se comunican, como ya se dijo, vía TCP/IP. Esta

comunicación es mediante mensajes de texto, con campos separados por “;”. La respuesta a

estos mensajes es texto, donde primero figura un “0” si la operación fue exitosa seguido de un

“;” y luego “Éxito” ó “1” seguido de la descripción del error.

• Mensajes a y desde Executer: son tres: mensajes de actualización de

la lista de archivos a ejecutar, mensajes de estado de los sensores y

mensajes para la ejecución de funciones domóticas.

Actualización de lista de archivos: cuando se genera un nuevo

diagrama (y paralelamente programa) o cuando se elimina uno, debe

notificarse de los cambios a Executer para que sepa que archivos

ejecutar. Para ello, el formato de estos mensajes es:

<comando>;<nombre_archivo_clp> donde <comando> es add ó

remove (según se agregue un nuevo diagrama o se elimine uno


158

existente, respectivamente) y <nombre_archivo_clp> es el nombre del

archivo ejecutable (.clp) correspondiente al diagrama

agregado/eliminado.

Estado de sensores: cuando cambia el valor de un sensor de la casa,

HomeState (quien posee comunicación con los mismos) notifica a

Executer de dicho cambio para que éste determine si existe algún

diagrama que deba ser ejecutado como consecuencia de ese cambio.

El formato de estos mensajes es: <sensor>;<estado> donde <sensor>

puede ser alarm, sunrise, sunset o door según los sensores emulados

descritos anteriormente en el trabajo y <estado> es true ó false, según

ese sensor se haya activado o desactivado, respectivamente. Si el

mensaje enviado es getAllSensorsState, recibe como respuesta el

estado de cada sensor, con la siguiente estructura:

<sensor1>,<estado1>;<sensor2>,<estado2>;…<sensor4>,<estado4>

Ejecución de funciones domóticas: cuando se está ejecutando un

programa y se requiere la ejecución de una función, por ejemplo, abrir

portón, Executer notifica a HomeState del pedido usando mensajes

con el siguiente formato:

requestFunctionCall;<idRoom>;<idFunc>(;<valor_param_i>)*

Donde requestFunctionCall es una constante que determina el tipo de

mensaje, <idRoom> representa el ID de Habitación (coincidente al

otorgado en la tabla rooms de la Base de Datos), <valor_param_i>

representa el valor del i‐ésimo parámetro de la función (está entre

paréntesis y con un asterisco indicando que puede haber de 0 a n

parámetros, dependiendo del tipo de función.


159

A.1.4.1.2. Preparación del Entorno de Construcción

Se preparó el entorno de construcción, (con las librerías y bibliotecas utilizadas) el

cual consta de los medios informáticos provistos por el alumno y es el indicado en

2.3.8.1. Especificación del Entorno de Construcción.

A.1.4.2. Generación del Código de los Componentes y

Procedimientos

El objetivo de esta actividad es la codificación de los componentes del sistema de

información, a partir de las especificaciones de construcción obtenidas en el proceso

Diseño del Sistema de Información (DSI).

A.1.4.2.1. Generación del Código de Componentes

En esta tarea se genera el código correspondiente a cada uno de los componentes

del sistema de información, identificados en la tarea Definición de Componentes y

Subsistemas de Construcción (2.3.8.2).

Se generó el código de cada subsistema, en el lenguaje elegido, compilándolo,

verificando y corrigiendo los errores sintácticos, y el enlace del código objeto

obtenido con las correspondientes bibliotecas.

En el CD que acompaña a este informe, se incluye el código fuente del Sistema

generado.

A.1.4.3. Ejecución de las Pruebas Unitarias

En esta actividad se realizarán las pruebas unitarias de cada uno de los componentes

del sistema de información, una vez codificados, con el objeto de comprobar que su

estructura es correcta y que se ajustan a la funcionalidad establecida.


160

A.1.4.3.1. Preparación del Entorno de las Pruebas Unitarias

En esta tarea se prepararán todos los recursos necesarios para realizar las pruebas

unitarias de cada uno de los componentes del sistema de información.

El entorno utilizado para llevar a cabo las pruebas unitarias corresponde al mismo

entorno de desarrollo, con la adición del plug‐in JUnit (versión 3.8.2) para el IDE

Eclipse (en cada proyecto de cada subsistema), el cual permitirá automatizar las

tareas de las pruebas unitarias dentro de dicho IDE. Las pruebas unitarias

consisten en codificar clases que extienden las clases de JUnit y que hacen uso de

las clases que se pretenden probar. En el caso de clases complejas, que contienen

objetos de otras clases, estos últimos son reemplazados por Objetos mock o falsos

para restringir las pruebas a los comportamientos propios de la clase a analizar.

A.1.4.3.2. Realización y Evaluación de las Pruebas Unitarias

El objetivo de esta tarea es comprobar el correcto funcionamiento de los

componentes del sistema de información, codificados en la actividad Generación

del Código de los Componentes y Procedimientos (2.4.2), conforme a las

verificaciones establecidas en el plan de pruebas para el nivel de pruebas unitarias,

en la actividad Especificación Técnica del Plan de Pruebas (2.3.10).

Las pruebas unitarias fueron diseñadas y ejecutadas a medida que se codificaban

las clases, y hasta que no fueran superadas todas las pruebas para esa clase, no se

pasaba a la siguiente. Se adoptó la convención (si la clase a evaluar se llamaba por

ejemplo, Punto), llamar a la clase donde se hace su unit test como PuntoTest y de

agrupar todas las clases de unit test en un paquete llamado test. Se creó un test

suite por subsistema que engloba todos los unit test del mismo y permite acelerar

las pruebas.

Los test suites de cada subsistema fueron ejecutados en forma íntegra por última

vez antes de generar los JARs de Java correspondientes para asegurar que las

pruebas unitarias siguieran siendo satisfactorias.


161

De los cincos subsistemas de 2.2.3. Identificación de Subsistemas de Análisis,

como ya se justificó en 2.3.10.2. Especificación Técnica de los Niveles de Prueba,

sólo los tres subsistemas del lado servidor fueron objeto del unit testing, con los

siguientes resultados finales (justo antes de generar los JARs):

• HomeState (30 clases, 59 tests): 59/59 tests exitosos

• CodeGen (12 clases, 28 tests): 28/28 tests exitosos

• Executer (5 clases, 19 tests): 19/19 test exitosos.

A.1.4.4. Ejecución de las Pruebas de Integración

En las pruebas de integración se verificará si los componentes o subsistemas

interactúan correctamente a través de sus interfaces, tanto internas como externas,

cubren la funcionalidad establecida, y se ajustan a los requisitos especificados en las

verificaciones correspondientes.

Antes de comenzar a describir los resultados de las pruebas de integración, se sugiere

referirse a 2.2.3.2. Integración de Subsistemas de Análisis para tener presente el

diagrama con los subsistemas, sus dependencias y las interfaces que existen entre

ellos. Las pruebas de integración se desarrollarán según lo descrito en 2.2.10.

Especificación del Plan de Pruebas y 2.3.10. Especificación Técnica del Plan de

Pruebas.

A.1.4.4.1. Preparación del Entorno de las Pruebas de

Integración

La preparación del entorno de las pruebas de integración fue breve, debido a que

el mismo es coincidente con el entorno de construcción. Se utilizó el IDE Eclipse

para hacer la depuración necesaria, con sus correspondientes breakpoints y

watches tanto para los subsistemas Servidor (Java) como para los subsistemas

Cliente (Flex).


162

A.1.4.4.2. Realización de las Pruebas de Integración

En esta tarea se verificará el correcto funcionamiento de las interfaces existentes

entre los distintos componentes y subsistemas, conforme a las verificaciones

establecidas para el nivel de pruebas de integración.

Para llevar a cabo estas pruebas, se partirá de la construcción de varios diagramas,

con distintas configuraciones. Los datos generados serán utilizados en las distintas

pruebas de integración.

• Diagrama A: diagrama vacío, sin figuras.

• Diagrama B: diagrama únicamente con una figura comienzo.

• Diagrama C: diagrama con un comienzo, una asignación, una condición y

dos asignaciones consecuentes (una en caso verdadero y otra en caso

falso) y un fin. Ninguna de las figuras posee propiedades.

• Diagrama D: ídem C, pero cada figura tiene propiedades ajustadas

(llamadas a función, comparaciones, variables, etc.)

• Diagrama E: una figura comienzo, seguida de una asignación (con una

función dentro de ella) y una figura fin. La figura comienzo tiene

propiedades ajustadas para que el diagrama se dispare a una hora y día

específico.

• Diagrama F: diagrama que modela un bucle:

I <- 1 MIENTRAS I < 6{

I <- I + 1 DEBUG(“i vale “, I)

} DEBUG(“FIN i vale “, I) FIN

• Diagrama G: diagrama similar a E, pero con activación por un sensor en

lugar de condición temporal (fecha y hora).


163

a. Integración Editor de Diagramas (GraFlow) – Generador de Código

(CodeGen)

Para realizar esta verificación, se siguieron los siguientes pasos:

o Generar un diagrama en GraFlow y se guardó en la Base de Datos

o Recuperar el diagrama almacenado como XML en la Base de Datos

usando phpmyadmin y se generó un archivo de texto XML

(test.xml)

o Validar el XML del diagrama contra su schema correspondiente

(schema_graflow.xsd) con un validador web

(http://www.xmlme.com/Validator.aspx)

o Ejecutar CodeGen, pasando el archivo de diagrama XML como

parámetro, generándose así sus correspondientes archivos de

código CLIPS (test.clp) y de condiciones de disparo del programa

(test.cond)

o Validar el archivo test.cond con su schema (schema_cond.xsd)

o Abrir el archivo test.clp en la consola de CLIPS y verificar que se

pueda cargar satisfactoriamente (implicando que las reglas son

sintácticamente correctas)

b. Integración Generador de Código (CodeGen) y Ejecutor de Código

(Executer)

Para realizar esta verificación, se siguieron los siguientes pasos:

o Remover las marcas de comentarios (“;” en CLIPS) de test.clp de

las sentencias que permiten imprimir en consola que regla se

acaba de ejecutar.

o Cargar y ejecutar test.clp en Executer

o Verificar el orden en que las reglas fueron ejecutados a partir de la

impresión por consola.

c. Integración Ejecutor de Código (Executer) y Emulador de las variables del

hogar, estado de la casa (HomeState)


164

Se siguieron los siguientes pasos:

o Ejecutar test.clp

o Verificar el estado de la casa, conectándose a HomeState vía telnet

al puerto correspondiente y solicitando el registro de eventos

d. Integración HomeState y Simulador

Se siguieron los siguientes pasos:

o Ejecutar test.clp

o Abrir simulador y verificar que los eventos correspondientes

figuren en la lista de registro de eventos. Si el evento generado

tiene una representación visual, verificar que la misma se presente

correctamente.

A.1.4.4.3. Evaluación del Resultado de las Pruebas de

Integración

A continuación, se describirán las observaciones tras la ejecución de cada una de

las pruebas de integración para cada uno de los diagramas.

Diagrama A:

1° Corrida:

En la prueba de integración A (GraFlow‐CodeGen) se detectó que el archivo de

código no se generaba correctamente.

Reporte de Prueba Nro: 1.1 Fecha: 1/7/09

Objetivo: Verificar la integración entre GraFlow‐CodeGen para el caso del

Diagrama A (diagrama vacío)


ID Caso de Prueba Nivel Severidad Descripción DA.A Medio Al almacenarse un

diagrama vacío, el archivo de código (.clp) no se genera correctamente


165

El archivo de diagrama fue validado con el Schema y pasó la prueba.

DA.A Medio Al almacenarse un diagrama vacío, el archivo de condiciones(.cond) no se genera correctamente El archivo de diagrama fue validado con el Schema y pasó la prueba.

Se cree que el error radica dentro del subsistema CodeGen y que está relacionado

con que el mismo espera al menos un bloque de programa en el XML de diagrama.

Pruebas de integración B, C y D no se pudieron completar, debido a que sus

entradas dependían de la salida de la prueba A.

2° Corrida: una vez solucionados los problemas reportados en la primera, se

ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados

satisfactorios.

Diagrama B:

1° Corrida:

Se ejecutaron las pruebas de integración A, B, C y D obteniéndose resultados

satisfactorios.

Diagrama C:

1° Corrida:


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:


166

temp <- 23; SI (temp < 25) ENTONCES{ DEBUG(“temp es menor a 25 y vale “, temp); }SINO{ DEBUG(“temp es mayor o igual a 25 y vale “, temp); } FIN


satisfactorios.

1° Corrida (bis):



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


satisfactorios.

Diagrama E:

1° Corrida:



Ejecutar los: Martes A las: 17:03

DEBUG(“test “, “diag E”); FIN


satisfactorios.


167

1° Corrida (bis):



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:


Objetivo: Verificar la integración entre Executer‐HomeState para el caso del

Diagrama E


ID Caso de Prueba Nivel Severidad Descripción DE.C Medio Al almacenarse un

diagrama que debe ejecutarse más de una vez por semana, no se termina ejecutando nunca. Si se selecciona como propiedad de comienzo cero o un día a la semana, funciona correctamente



satisfactorios.


168

Diagrama F:

1° Corrida:


satisfactorios.

Diagrama G:

1° Corrida:



Ejecutar cuando: Alarma

DEBUG(“test “, “diag G”); FIN


satisfactorios.

1° Corrida (bis):



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:


Objetivo: Verificar la integración entre Executer‐HomeState para el caso del

Diagrama E


ID Caso de Prueba Nivel Severidad Descripción DG.C Medio Al almacenarse un

diagrama que debe


169

ejecutarse ante la llegada de la señal de 2 o más sensores, no se termina ejecutando nunca. Si se selecciona como propiedad de comienzo cero o un sensor, funciona correctamente



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:


170

1. 1° Corrida

Reporte de Prueba Nro: 8 Fecha: 14/7/09

Objetivo: Prueba de Sistema para Diagrama A


ID Caso de Prueba Nivel Severidad Descripción PS.A Bajo Al almacenarse un

diagrama vacío y luego reabrirse, produce un error

2° Corrida: Se verificó la correcta reparación de los inconvenientes

encontrados en la 1° Corrida.

2. 1° Corrida

Reporte de Prueba Nro: 9 Fecha: 15/7/09

Objetivo: Prueba de Sistema usando Administrar Diagramas


ID Caso de Prueba Nivel Severidad Descripción PS.X Medio Al eliminarse el

diagrama actualmente abierto desde “Administrar diagramas” de GraFlow, se produce un error que se registra en el log de Executer

2° Corrida: Se verificó la correcta reparación de los inconvenientes

encontrados en la 1° Corrida.


171

A.1.4.6. Elaboración de los Manuales de Usuario

A.1.4.6.1. Elaboración de los Manuales de Usuario

El objetivo de esta tarea es elaborar la documentación de usuario, tanto usuario

final como de explotación, de acuerdo a los requisitos establecidos en la tarea

Especificación de Requisitos de Documentación de Usuario (DSI 11.1), y recogidos

en el catálogo de requisitos.

Los manuales de usuario se distribuirán en forma electrónica en dos formatos:

como ayuda HTML, accesible desde un navegador web y como archivos de ayuda

compilada de Microsoft (CHM). Los archivos de ayuda en forma de HTML serán

armados sólo para las herramientas web, es decir, el Editor de Diagramas

(GraFlow) y el Simulador mientras que los cinco subsistemas/herramientas

tendrán sus correspondientes archivos CHM, los cuales el usuario podrá copiar a

su máquina desde el instalador del sistema. La estructura de los archivos de ayuda

será la típica de los archivos CHM, con una jerarquía de árbol, con capítulos y

artículos dentro de los mismos.

A.1.4.7. Definición de la Formación de los Usuarios Finales

En esta actividad se establecerán las necesidades de formación del usuario final, con el

objetivo de conseguir la explotación eficaz del nuevo sistema.

Para la definición de la formación se tendrán en cuenta las características funcionales y

técnicas propias del sistema de información, así como los requisitos relacionados con

la formación del usuario final, establecidos en la tarea Especificación de Requisitos de

Implantación (2.3.11.2).

El presente Trabajo Profesional no tiene como objetivo la puesta en producción del

sistema desarrollado por lo cual el plan de capacitación a los Usuarios Finales no aplica.

Sin embargo, se pueden enumerar una serie de conocimientos necesarios para la

operación del sistema, en el momento de la Defensa del Trabajo y ellos están descritos

en el apartado Requisitos de Formación de 2.3.11.2. Especificación de Requisitos de

Implantación.


172

A.1.4.8. Construcción de los Componentes y Procedimientos de

Migración y Carga Inicial de los Datos

En esta actividad se codificará y probará los componentes y procedimientos de

migración y carga inicial de datos, a partir de las especificaciones recogidas en el Plan

de Migración y Carga Inicial de Datos obtenida en el proceso Diseño del Sistema de

Información.

A.1.4.8.1. Preparación del Entorno de Migración y Carga

Inicial de Datos

A partir de la Base de Datos generada previamente, con las habitaciones,

funciones y parámetros correspondientes, se preparó un script en PHP que

recuperó los datos que fueron insertados cuidadosamente durante el proceso de

codificación y se generó un archivo de texto con los datos iniciales. Este archivo

(data.sql) se utilizará junto a un archivo con las sentencias para la creación de las

tablas (createDB.sql), armado según 2.3.6.1. Diseño del Modelo Físico de Datos.

A.1.4.8.2. Generación del Código de los Componentes y

Procedimientos de Migración y Carga Inicial de Datos

En esta tarea, se generó el código para la carga inicial de los datos. Se decidió que

la forma más eficiente era desarrollando un pequeño programa (InitDB) que leyera

los archivos createDB.sql y data.sql sentencia por sentencia de SQL y las ejecutara.

Este programa fue escrito en Java y se incluye dentro del instalador del sistema. En

el momento de la instalación, el instalador solicita nombre y contraseña para

acceder a la Base de Datos y esos valores son pasados como parámetros para que

el InitDB cargue los datos iniciales. Si InitDB no puede hacerlo, devuelve un código

de error al instalador quien notifica al usuario. La activación de InitDB es

totalmente transparente para el usuario que está intentando instalar el sistema.

Se adjunta en el CD el código fuente de InitDB.


173

A.1.4.8.3. Realización y Evaluación de las Pruebas de

Migración y Carga Inicial de Datos

Se probó a InitDB tanto en forma separada por línea de comandos como ya

integrado con el instalador, en una máquina virtual para hacer una instalación

limpia, y, se comprobó que los datos iniciales cargados eran válidos y completos.

A.1.4.9. Aprobación del Sistema de Información

A.1.4.9.1. Presentación y Aprobación del Sistema de

Información

Los directores del Trabajo Profesional revisaron y aprobaron la Construcción del

Sistema de Información presentado en esta Etapa que figura en el presente

informe.

programaciÓn domÓtica basada en sistemas expertos

Documents