Docu Kora2

Proyecto Fin de Carrera
Software accesible para control de entorno mediante dispositivos mviles
Ingeniera Informtica ETS de Ingenieras Informtica y de Telecomunicaciones Universidad de Granada Septiembre de 2010 Autor: Jos Alcal Correa Tutora: M Jos Rodrguez Frtiz
Kora
Jose Alcal Correa
Proyecto Fin de Carrera. Septiembre de 2010
Kora
NDICE
Captulo I: Introduccin
1. Objetivos del proyecto 1.1. Descripcin del problema 1.2. Propuesta de desarrollo 1.3. Descripcin detallada de los objetivos
5
6 6 8 9
Captulo II. Investigacin.

1. Estado del arte. 1.1. Soluciones similares 1.2. Plataformas mviles 1.3. Sistemas domticos comerciales 1.4. Plataformas para comunicacin distribuida 2. Contexto 2.1. Proyectos previos realizados en la UGR 2.2. Software libre 3. Tecnologas empleadas
12
13 13 16 19 22
Captulo III: Modelado de requisitos

1. Anlisis de requisitos 1.1. Descripcin informal 1.2. Requisitos funcionales 1.3. Requisitos no funcionales 1.4. Actores 2. Casos de uso 2.1. Diagrama de casos de uso 2.2. Diagrama de paquetes 2.3. Descripcin de los casos de uso
Captulo IV: Anlisis

1. Normas de accesibilidad
Jose Alcal Correa Proyecto Fin de Carrera. Septiembre de 2010
Kora
1.1. Accesibilidad web: WAI 1.2. GNOME Accesibility Guidelines 1.3. Conclusiones 2. Representacin genrica de dispositivos domticos 2.1. Direccionamiento y valores en sistemas comerciales 2.2. Conclusiones 3. Modelo esttico 3.1. Diagrama de clases 3.2. Descripcin de las clases: atributos y operaciones 3.3. Descripcin de las relaciones
Captulo V: Diseo
1. Objetivos del diseo 2. Arquitectura del sistema 3. Descomposicin en subsistemas 4. Diseo de la interfaz de usuario 5. Diseo de objetos
Captulo VI: Implementacin

1. Recursos empleados 4.1. Recursos hardware 4.2. Recursos software 2. Descripcin del entorno de desarrollo 3. Interfaz de usuario 4. Comunicacin con el servidor 5. Integracin con KNX 5.1. KNX en profundidad 5.2. Utilizacin de Calimero 5.3. Entrenador de pruebas KNX
Captulo VII: Uso de la aplicacin

1. Manual de instalacin 1.1. Instalacin de la aplicacin servidor
Kora
1.2. Instalacin de la aplicacin cliente 2. Manual de usuario 2.1. Aplicacin servidor 2.2. Aplicacin cliente
Captulo VIII: Conclusiones

1. Resumen del trabajo 2. Grado de consecucin de objetivos 3. Eventos durante el desarrollo 3.1. Hackathn de Software Libre en la UGR 3.2. IV Concurso Universitario de Software Libre 3.3. Artculos y asistencia a congresos 3.4. Problemas durante el desarrollo 4. Trabajo futuro 5. Conclusiones personales 6. Agradecimientos
Anexos Bibliografa y referencias Contenidos del CD
Jose Alcal Correa
Kora
CAPTULO I: INTRODUCCIN
Jose Alcal Correa
Kora
1. OBJETIVOS
DEL PROYECTO
DEL
1.1. DESCRIPCIN
PROBLEMA
El control de entorno es el conjunto de sistemas elctricos, electrnicos y mecnicos que permiten a una persona interactuar con objetos de su vivienda de forma remota, es decir, sin accionar manualmente sus mecanismos. Esto suele hacerse mediante un mando a distancia o un panel de control empotrado en la pared. La domtica (de domus, casa en latn y automtica, que funciona por s sola en griego) es el conjunto de sistemas elctricos y electrnicos que son capaces de automatizar ciertas acciones en una vivienda. Cada da es ms comn la presencia de la domtica y de sistemas de control de entorno tanto en los hogares como en los edificios pblicos. Estos dispositivos permiten realizar acciones dentro del hogar de una forma ms cmoda y protegida, al no tener que activar directamente ningn mecanismo. Tambin son tiles para mejorar la seguridad en edificios, pues pueden combinarse sensores y actuadores para programar avisos o acciones de proteccin. El desarrollo de los sistemas de control de entorno puede mejorar enormemente la calidad de vida y facilitar los quehaceres diarios de todos. Paralelo al auge de la domtica se est produciendo el auge de los telfonos inteligentes (smartphones) que permiten una gran variedad de interacciones distintas, son cada vez ms potentes y tambin ms asequibles. Disponen, adems, de una gran variedad de soluciones de conectividad, son ms ligeros y su autonoma es mayor. No obstante, estos desarrollos tecnolgicos, junto con otros no menos importantes (como el entretenimiento digital, los electrodomsticos inteligentes o las telecomunicaciones) pueden suponer una barrera que aumente la distancia social entre las personas que sufren alguna discapacidad y las que no. Sin embargo, si este desarrollo tecnolgico se realiza siguiendo criterios de accesibilidad y diseo universal, estas nuevas tecnologas pueden ofrecer grandes oportunidades para personas con discapacidades tanto fsicas como intelectuales. Por ejemplo, las interfaces de control de los sistemas domticos y de control de entorno no son todo lo simples y accesibles que estos usuarios necesitan. Normalmente el control de los dispositivos se realiza mediante paneles en la pared o mandos que estn configurados para una instalacin
Kora
concreta. Las personas con discapacidad no pueden acceder a estos sistemas de control por no estar adaptados a ellos (pues los botones son pequeos o no se ven, son complejos de usar o simplemente son inalcanzables). En cambio, los dispositivos mviles de ltima generacin si estn preparados para permitir formas de interaccin no convencionales y que permiten el acceso a los mismos a las personas discapacitadas. Suelen incluir lectores de pantalla, ofrecen mltiples modos de interaccin, personalizaciones en el modo de visualizacin y varias combinaciones posibles de realimentacin ante las acciones del usuario. En muchos casos es necesario que sean ellos mismos quienes manejen los dispositivos domticos en lugar de automatizar el comportamiento de la vivienda. Esto les permitira tener un mayor grado de independencia, lo cual dara como resultado una menor necesidad asistencial, la mejora de su desarrollo e integracin social y profesional, una mayor autoestima (lo cual podra permitir en ciertos casos una recuperacin ms rpida) y una disminucin de la presin que sienten los familiares del individuo. As, sera deseable contar con una interfaz de control para los dispositivos domticos especficamente adaptada a ellos, y para tal labor los dispositivos mviles ofrecen unas caractersticas muy interesantes, como se ha comentado anteriormente.
Jose Alcal Correa
Kora
1.2. PROPUESTA
DE
DESARROLLO
El proyecto Kora pretende desarrollar una aplicacin para dispositivos mviles que permita el control de dispositivos domticos en el hogar o el centro educativo. Est especialmente enfocado a personas con necesidades especiales, ya sean de tipo fsico o cognitivo. Estas podran ser parlisis cerebral, problemas de movilidad, esclerosis lateral amiotrfica (ELA), autismo, etctera. Una de las premisas bsicas del proyecto es que se facilite al mximo la interaccin del usuario con el entorno manteniendo la autonoma del mismo, de forma que sea l quien toma las decisiones y las acciones a realizar sobre lo que desea hacer en todo momento. No obstante, tambin sera deseable permitir cierto nivel de automatizacin, principalmente con el propsito de aumentar la seguridad del usuario. La otra premisa es que pueda llegar al mximo nmero de personas posible, sea cual sea la dificultad que presenten. Para conseguir dicha capacidad de adaptacin, debe contar con una interfaz totalmente configurable y lo ms simple y sencilla de usar que sea posible, tanto para el tutor de la persona discapacitada (que se encargar de configurar la aplicacin al gusto de esta) como para el propio usuario final. La aplicacin estar diseada para dispositivos mviles que acompaen al usuario, para que pueda realizar acciones de control de entorno en cualquier momento y lugar. Estos dispositivos nos ofrecen, adems de la ubicuidad, una gran variedad de formas de interaccin mediante pantallas tctiles, gestos, acelermetros o control por voz, que los mandos tradicionales no pueden aportar. Esta caracterstica debe ser la mayor cualidad que presente la aplicacin. Por una parte contar con una interfaz simple pero totalmente configurable tanto en aspecto como en contenido que la haga accesible a una gran cantidad de personas, y por otra presente un gestor de usuarios y perfiles para los que pueda configurarse la aplicacin. Este gestor permitir que varias personas puedan utilizar el mismo dispositivo para controlar la instalacin domtica, aun no teniendo el mismo conjunto de requisitos de personalizacin. La aplicacin ser Software Libre, con el propsito de que pueda revisarse, ampliarse y mejorarse por parte de terceros, y de esta forma llegar al mayor nmero posible de personas. Adems de en la calidad del software, el hecho de que sea libre redunda tambin en la reduccin de costes.
Kora
1.3. DESCRIPCIN DETALLADA
DE LOS
OBJETIVOS
El proyecto Kora tiene el propsito de desarrollar una aplicacin para dispositivos mviles que ejecutan el Sistema Operativo Android para el control de dispositivos domticos, con especial nfasis en su adaptabilidad a un rango lo ms amplio posible de discapacidades, ya sean fsicas o cognitivas. Dadas estas premisas, la aplicacin desarrollada debe cumplir los siguientes requisitos. Facilidad y simplicidad de uso. Debido al pblico al que va dirigida la aplicacin, es importante que su uso sea lo ms directo y sencillo posible, de forma que las acciones se ejecuten siempre de la misma manera y directamente. El apartado de configuracin debe ser tambin atractivo y sencillo de usar para los tutores, ya que la mayora tendrn poca experiencia con este tipo de dispositivos. Completa modificacin del comportamiento de la aplicacin. Debido a que la aplicacin debe ser capaz de adaptarse al mayor nmero de caractersticas de los usuarios, todos y cada uno de los aspectos de la aplicacin deben de ser personalizables. Este punto est muy relacionado con el anterior, puesto que la gran cantidad de opciones no debe ser un obstculo para la configuracin de la aplicacin, mantenindose esta sencilla. Debe poderse modificar la forma en la que se interacta con la aplicacin, aprovechando las posibilidades de los dispositivos sobre los que se va a implementar. Tambin debe poderse modificar la interfaz de la misma, permitiendo su adaptacin a problemas con dificultades visuales o problemas cognitivos. Asimismo, la realimentacin sobre las acciones que realice el usuario debe presentarse de distintas maneras: mediante vibracin, sonidos (que a su vez sean configurables), dilogos de confirmacin, etctera. Robustez, eficiencia y estabilidad. Es importante que la aplicacin sea estable y tenga un comportamiento predecible, pues para ciertas personas (como aquellas que tienen sndrome
Jose Alcal Correa
Kora
de Asperger o autismo) es importante que la aplicacin se comporte siempre de la misma manera. Asimismo, la aplicacin debe ser eficiente puesto que se va a ejecutar en dispositivos mviles con una potencia reducida, y el consumo excesivo de recursos dispara tambin el de batera. Escalabilidad. La aplicacin debe ser fcilmente ampliable, tanto en el soporte a nuevos dispositivos como a nuevas personalizaciones y representaciones de acciones y dispositivos, de forma que pueda utilizarse en lugares con distintas caractersticas y por parte de usuarios con distintas necesidades (por ejemplo, puede haber usuarios que prefieran o necesiten unas imgenes y sonidos concretos). Soporte para el mayor nmero de dispositivos domticos. La aplicacin debe ser independiente de la tecnologa domtica subyacente, es decir, es el servidor domtico quien debe encargarse de adaptarse al estndar utilizado (KNX, X-10, ZigBee, etctera). La interfaz de comunicacin entre la aplicacin mvil y la del servidor debe abstraerse sobre los protocolos de bajo nivel. Soporte para un gran nmero de dispositivos mviles. Es importante que la aplicacin pueda utilizarse en el mayor nmero posible de dispositivos, con caractersticas distintas (como el tamao de la pantalla o los accesorios que se le puedan conectar) y con un coste reducido. Utilizacin de formatos estndar y abiertos. La aplicacin trabajar con datos almacenados que sigan especificaciones estndar y/o abiertas, como XML, SQLite y bibliotecas estndar como la biblioteca de clases de Java. Configuracin de la aplicacin sin necesidad de herramientas externas. La aplicacin debe permitir la gestin de usuarios y sus perfiles asociados sin necesidad de herramientas externas. Esto no tiene por qu conllevar necesariamente que no se puedan utilizar herramientas tales como generadores que hagan la edicin ms rpida. Soporte para varios usuarios en un mismo dispositivo. La consecucin de este ojetivo redundar en una notable reduccin de costes y una puesta en marcha ms rpida del sistema, pues para que otro usuario utilice el mismo terminal que otro solamente tendr que cambiarse el perfil en uso de la aplicacin.
Jose Alcal Correa
10
Kora
Acceso concurrente de varios usuarios a los mismos dispositivos domticos. Debe permitirse que varios usuarios puedan interactuar a la vez con los dispositivos, de forma que todos observen a la vez los cambios que se produzcan en el entorno, y puedan modificar su estado de forma segura.
Jose Alcal Correa
11
Kora
CAPTULO II: INVESTIGACIN
Jose Alcal Correa
12
Kora
1. ESTADO
DEL ARTE
1.1. SOLUCIONES SIMILARES

Sistemas de control de Entorno de BJ Adaptaciones
La empresa BJ Adaptaciones es una empresa dedicada a comercializar y producir software y dispositivos de soporte a la autonoma de personas con discapacidad. Es una empresa fundada en 2002 por dos hermanos, uno de los cuales tiene esclerosis mltiple, y su primer proyecto consisti en ofrecer soluciones a personas en situaciones similares. En su catlogo (que puede consultarse en su pgina web [BJ]) ofrecen mltiples dispositivos, y entre ellos se encuentran mandos para control de entorno. Estos mandos estn especficamente adaptados para una instalacin concreta que tienen que hacer los tcnicos de la empresa y si se hacen cambios en la instalacin domtica hay que reprogramar el mando completo, modificando la funcionalidad de los botones. Estos mandos utilizan un protocolo propio para comunicarse con los receptores y ncamente son tiles a personas que, pese a tener problemas de movilidad, siguen pudiendo mover los dedos de la mano.
Proyecto InterAct
El proyecto Interact (Interfaces de Usuario Multimodales: Entornos Activos), del Departamento de Ingeniera Informtica de la Universidad Autnoma de Madrid tiene como objetivo el desarrollo de tecnologa relativa a la implementacin de Entornos Activos o Entornos Inteligentes. El prototipo de entorno inteligente que han desarrollado est dividido en tres capas: de contexto, de interaccin con el entorno fsico y de interaccin en lenguaje natural [refAct]. Est diseado para que la casa se adapte automticamente en la medida de lo posible al contexto actual y las preferencias del usuario detectado. Este sistema utiliza el estndar domtico europeo EIB para la capa de entorno fsico, que est activado mediante una red de sensores y un sistema de micrfono y altavoces que posibilitan la interaccin del usuario. Esta propuesta se diferencia de la nuestra en que est ms orientado a la automatizacin de acciones y la inteligencia adaptativa del entorno,
13
Kora
mientras que lo que nosotros proponemos es que se refuerce la intervencin directa, consciente y autnoma del usuario.
AmILab
El proyecto AmILab (Ambient Intelligence Laboratory), tambin de la UAM, est igualmente enfocado a la Inteligencia Ambiental. La principal diferencia con el proyecto anterior es que en lugar de centralizar el proceso de las seales y acciones en una centralita domtica, aplican conceptos de computacin ubicua a los elementos que conforman el sistema domtico. En este proyecto est an ms marcada la automatizacin de los sistemas de control de entorno, de forma que el propio sistema tome decisiones sobre los dispositivos de la vivienda, aunque tambin se proponen nuevas formas de interaccin con el sistema como el uso de lenguaje natural hablado, o realidad aumentada.
Remote and mobile control in domotics

Este paper propone un sistema de control remoto para instalaciones domticas. Pretende integrar sistemas de monitorizacin para Edificios Inteligentes (Intelligent Buildings). Es decir, est ms orientado al control monitorizado de la instalacin ms que a la manipulacin y el manejo de los dispositivos que la integran. El sistema est basado en un servidor web que se conecta con los dispositivos mviles mediante tecnologas estndar como Bluetooth o WiFi. Los dispositivos mviles son PDAs con Windows Mobile 6 (Pocket PCs). El artculo est escrito por el departamento de Electrnica y Computadores de la Universidad de Transilvania, y puede consultase en [Remote].
OpenRemote
Es un proyecto de cdigo abierto que pretende desarrollar una distribucin GNU/Linux especialmente enfocada al control de dispositivos domticos en el hogar, ofreciendo una capa intermedia que provea acceso uniforme a alto nivel a los dispositivos domticos de distintos fabricantes y estndares. La organizacin desarrolla software bajo licencia libre para el acceso a dispositivos domticos y de automatizacin. Tambin comercializan soluciones hardware con el software preinstalado y configurado para utilizar en multitud de mbitos.
14
Kora
El proyecto tiene el objetivo de integrar todos los posibles dispositivos y sistemas domticos que puedan existir en una instalacin mediante un servidor central (que puede ser un ordenador convencional con OpenRemote instalado o el sistema ORB que viene preparado de fbrica). A este servidor se puede acceder mediante acceso directo al ordenador, mediante un sistema web (llamado The Panel) o mediante dispositivos mviles como el iPhone o mviles Android (mediante la aplicacin OpenRemote Controller). Como puede deducirse, la capacidad de este proyecto es inmensa y es muy potente y verstil, y adems es libre. No obstante, la instalacin manual puede ser muy compleja, el sistema no se considera estable todava, no hay apenas documentacin para el cdigo, y apenas hay manuales para configurar el sistema. Las aplicaciones para acceder al servidor domtico mediante dispositivos mviles que proveen estn diseadas para usuarios con grandes conocimientos de domtica, pues requieren configuracin desde el propio dispositivo. Hay aplicaciones para Android y iPhone, ambas gratuitas y libres, y su cdigo fuente puede encontrarse en la forja de cdigo del proyecto.
Jose Alcal Correa
15
Kora
1.2. PLATAFORMAS MVILES

Hoy da existen varias plataformas mviles que podramos considerar suficientemente potentes, es decir, que cuentan con posibilidades de conectividad inalmbrica como Bluetooth o Wi-Fi, una ms que suficiente velocidad de proceso (capaz incluso de procesar el habla en tiempo real), interaccin tctil y un conjunto de herramientas de desarrollo al mismo nivel que el de las aplicaciones de escritorio. Estas plataformas mviles se distinguen principalmente por el Sistema Operativo que tienen preinstalado.
Apple iPod Touch, iPhone y iPad

Estos dispositivos estn gobernados por el sistema operativo iOS, propiedad de Apple. Cuando se present, el iPhone revolucion el concepto de telfono inteligente y la forma de interactuar con el mismo: ausencia de botones fsicos, uso de gestos lo largo de la interfaz de usuario, utilizacin de acelermetros para detectar movimiento y multitouch. Estos dispositivos solo pueden programarse desde ordenadores con MacOS X, y el lenguaje de programacin que suele usarse es Objective C. Tiene la ventaja de ser una plataforma muy probada y eficiente, muy agradable estticamente y con gran reconocimiento social. Como contrapartida, estn la limitacin a unos dispositivos concretos que pueden ser bastante caros, las limitadas opciones de interconexin con otros dispositivos que no sean de Apple y el pago de las cuotas anuales para desarrollo de aplicaciones. Esto hace que, a pesar del gran atractivo de la plataforma, est lejos de los objetivos de bajo coste y apertura de la plataforma. Asimismo, para nuestro objetivo nos limita el hecho de la nula extensibilidad del dispositivo: no es posible conectarle perifricos externos ms all de los oficiales, y ninguno de ellos ofrece mejoras de accesibilidad.
Symbian
Es un Sistema Operativo para mviles y dispositivos empotrados desarrollado por un consorcio de empresas que lideraba Nokia, aunque ahora es la nica propietaria del sistema y recientemente lo liber bajo licencia GPL. Est presente en prcticamente todos los mviles de gama media-baja de Nokia, Sony Ericsson, Samsung o Siemens. Est especialmente optimizado
16
Kora
para dispositivos con pocos recursos hardware y destaca por tener una gran estabilidad. El principal problema de los dispositivos que utilizan este Sistema Operativo es la limitacin de recursos de la gran mayora de ellos y lo bsicas que son sus herramientas de desarrollo, a pesar de ser una plataforma abierta que contina evolucionando. Normalmente, al ser bastante bsicos los dispositivos que llevan este sistema operativo, no suelen permitir accesorios ms all de los manos libres y los auriculares. Adems, la implementacin de los protocolos de comunicacin (como Bluetooth o WiFi) suele estar muy limitada.
BlackBerry
Son un conjunto de PDAs comercializadas por la empresa canadiense Research In Motion. Estos mviles son muy conocidos en el mundo empresarial, sobre todo por la gestin del correo y el teclado que suelen incluir. A pesar de esto, su sistema operativo no es todo lo estable que pudiera desearse, no son dispositivos especialmente potentes y presentan ciertas limitaciones a la hora de interactuar con ellos, como la baja calidad de sus pantallas tctiles. La presencia de un teclado QUERTY completo (que ocupa casi la mitad del mvil) es en nuestro caso un inconveniente, pues se pretende crear una interfaz sencilla en la que el uso del teclado sea nulo o mnimo.
Windows Mobile
Esta plataforma est descartada desde el principio por estar prcticamente desfasada, tanto en caractersticas como en variedad de dispositivos. No obstante, Microsoft est desarrollando una nueva versin desde cero llamada Windows Phone que todava no ha aparecido en el mercado.
WebOS
Es el Sistema Operativo de los dispositivos de Palm, recientemente comprada por HP. Sus mayores inconvenientes son la poca variedad de dispositivos que lo soportan y el futuro incierto de la plataforma, a pesar de ser muy verstil y presentar un conjunto de herramientas de desarrollo y unas posibilidades de interaccin bastante buenas.
Jose Alcal Correa
17
Kora
Maemo / MeeGo
Maemo es el Sistema Operativo de Nokia para sus mviles y tablets de gama alta, basado en Debian GNU/Linux. Este sistema ha sido abandonado y nunca lleg a estar desarrollado por completo. MeeGo es la evolucin de Maemo tras su fusin con la plataforma mvil Moblin, de Intel. Sus principales ventajas son la apertura del sistema (es libre y est siendo desarrollado en un repositorio pblico), la eficiencia y estabilidad del Sistema Operativo basado en Linux, las posibilidades de interaccin y el kit de desarrollo, basado en Qt. Adems, se prev que sea completamente personalizable y extensible, lo cual elevara notablemente las posibilidades de interaccin pues se permitir la creacin de drivers para nuevos mtodos de entrada de datos. El principal inconveniente que presenta este sistema es que an no ha aparecido en el mercado, adems de que se prev su salida solo para mviles de gama alta.
Android
Es un Sistema Operativo y plataforma de desarrollo mvil creado por Google a partir del kernel Linux. Al igual que este es libre (aunque con ciertas limitaciones que han provocado controversia) y es el principal competidor de iOS. Una de sus principales caractersticas es que aparece en una gran cantidad de terminales de fabricantes distintos con caractersticas muy heterogneas, y en un amplio rango de precios. Este punto es a la vez una ventaja y un gran inconveniente, pues se tiene acceso a una gran variedad de dispositivos distintos con la misma aplicacin, aunque soportarlos puede llegar a ser complicado. Android ofrece ms posibilidades de interaccin que cualquier otra plataforma mvil, como el reconocimiento de frases habladas complejas, un buen lector de textos y soporte para conexin de dispositivos auxiliares va bluetooth [refIME], como mandos de Wii [WiiIME], controladores especiales para personas discapacitadas [TTM] o incluso otros telfonos mviles. El entorno de desarrollo de la plataforma est basado en Java, lo cual lo dota de bastante fiabilidad y facilidad para el desarrollo, a pesar de un ligero descenso de rendimiento respecto a otras plataformas debido a la sobrecarga de la mquina virtual.
Jose Alcal Correa
18
Kora
1.3. SISTEMAS DOMTICOS COMERCIALES

La domtica es el conjunto de sistemas capaces de automatizar un edificio, aportando una mejor gestin de la energa y mayor seguridad y bienestar para sus habitantes. Mediante la programacin y adaptacin al contexto del consumo elctrico de los aparatos, se consigue una gestin energtica ms eficiente que proporciona un menor gasto energtico. Esto tambin permite que ciertas actuaciones comunes en una vivienda se hagan automticamente o de forma ms sencilla, redundando en una mayor comodidad para los usuarios. Adems, los sistemas domticos suelen ser capaces de proteger tanto los bienes como las personas presentes en el edificio, ya sea simulando presencia durante largos periodos de ausencia de los habitantes, como dando alertas ante intrusiones, accidentes que puedan producirse o problemas mdicos. Si el sistema dispone de comunicacin externa va Internet, puede incluso gestionarse la instalacin de forma remota. El control de entorno podra considerarse un subconjunto del campo de la domtica, pero con la diferencia de que est ms enfocado a que sea el propio usuario quien tome las decisiones sobre qu hacen los dispositivos de la vivienda. Es un concepto muy relacionado con la accesibilidad, pues el objetivo de esta tecnologa es reforzar la autonoma del usuario. Un sistema domtico comn est compuesto por una red de sensores y actuadores conectados a una centralita que se encarga de procesar las entradas de los sensores y provocar acciones en los actuadores. Los sensores son elementos que continuamente captan informacin (como humedad, presencia, luz, estado de un dispositivo, etctera). Los actuadores son sistemas que ejecutan alguna accin. Pueden ser motores que suban persianas o abran puertas, interruptores de bombillas, mandos de televisin y minicadenas, o mecanismos para ayudar a levantar a una persona. A pesar de que el proyecto se centrar ms en la parte de interfaz de usuario y gestin de perfiles, es interesante conocer qu estndares comerciales de domtica existen actualmente, ya que sera deseable que la aplicacin pudiera interactuar con ellos indistintamente, gracias a las similaridades que pueda haber entre ellos.
Jose Alcal Correa
19
Kora
X-10
Es un protocolo de comunicaciones abierto para controlar dispositivos elctricos. Fue la primera tecnologa domtica que lleg al mercado. Es capaz de transmitir datos por la lnea elctrica a muy baja velocidad (tan solo 50bps en Europa) y tan solo soporta 256 dispositivos en la misma instalacin. El modo de operacin que utiliza es muy sencillo: primero se indica la direccin de un dispositivo y posteriormente la orden a ejecutar. Pueden encadenarse varias direcciones de dispositivo y dar una orden comn a todos ellos. Su principal ventaja es que ahorra el tener que tender nuevos cables para hacer una instalacin domtica, a pesar de sus limitaciones. Est ms presente en Estados Unidos y Sudamrica que en Europa, y en Espaa su uso no es muy comn.
ZigBee
Es un conjunto de protocolos de comunicacin inalmbrica de bajo consumo de energa. Prioriza el consumo de energa a la tasa de envo de datos. Es especialmente interesante para la domtica por su bajo consumo energtico, su topologa de red en malla, su bajo coste (apenas tres dlares una placa con transmisor, memoria y microprocesador) y la gran cantidad de circuitos con especificaciones abiertas que existen. Sus principales inconvenientes son el rango de transmisin, la baja velocidad de las transmisiones (aunque es mayor que la de X-10) y la dependencia de las bateras de los dispositivos. Inicialmente la baja seguridad de las transmisiones constitua un grave problema, pero en las ltimas revisiones del protocolo ha mejorado bastante.
Jose Alcal Correa
20
Kora
LonWorks
Es un protocolo creado por la empresa norteamericana Echelon en 1992. Est orientado tanto a domtica como a sistemas de control industrial (por ejemplo, para transporte, fbricas u oficinas). Se basa en una arquitectura descentralizada y destaca por su fiabilidad y robustez. De hecho, suele utilizarse en plataformas petrolferas y varias industrias donde la seguridad es crtica. Su principal inconveniente es su elevado precio, debido principalmente a las elevadas regalas (royalties) y a que solo tres fabricantes tienen licencia para fabricar chips que implementen el protocolo.
EIB / KNX
European Installation Bus es un sistema domtico basado en un bus de datos que utiliza su propio cableado, lo cual obliga a aadir conducciones aparte de las elctricas. KNX es un protocolo desarrollado por la KNX Association, (un consorcio de empresas europeas en su mayora alemanas) en 1999, ampliando la especificacin anterior del EIB. Este consorcio pretende implantar un estndar de origen europeo a nivel internacional que ha demostrado ser muy robusto y fiable. La comunicacin puede alcanzar velocidades de 9600bps y direccionar hasta 65 536 dispositivos, organizados hasta en 8 grupos con 32 subgrupos que a su vez pueden contener 256 dispositivos. La topologa del sistema es matricial y los dispositivos pueden comunicarse entre s de forma centralizada o descentralizada. Este sistema tiene cada vez mayor penetracin en el mercado europeo, de hecho, es actualmente el sistema ms utilizado en Europa. No obstante, los dispositivos que implementan el estndar son caros (aunque menos que los de LonWorks) y tienen la necesidad de tender cableado extra y de ser muy costoso.
Jose Alcal Correa
21
Kora
1.4. PLATAFORMAS
PARA
COMUNICACIN DISTRIBUIDA
Segn los requisitos de la aplicacin, es necesario que varios usuarios puedan acceder de forma concurrente al mismo sistema domtico. Adems, cuando se produzca un cambio en el estado de alguno de los componentes del sistema, todos los clientes que haya conectados al mismo (en forma de dispositivos mviles) debern ser notificados de forma instantnea. Por tanto, es necesario contar con una plataforma de computacin y comunicacin distribuida que d soporte a todas estas caractersticas. Una plataforma de desarrollo de sistemas distribuidos es una capa intermedia de software (middleware) que permite la ejecucin de cdigo en otro sistema con el que se est interconectado. De este modo, en una peticin de ejecucin de un mtodo remoto se transmiten por la red el cdigo y los parmetros necesarios para ejecutar dicho mtodo, y se devuelve el resultado al emisor de la peticin.
CORBA
Common Object Request Broker Architecture es un estndar que permite, entre otras funcionalidades, la ejecucin de mtodos remotos bajo un paradigma orientado a objetos. Se lo considera el middleware de comunicacin de facto y tiene implementaciones para varios lenguajes de programacin. Sus principales ventajas son su soporte para varios lenguajes y que est muy extendido, pero puede llegar a tener una configuracin bastante compleja y tiene una elevada exigencia de recursos que lo hace poco recomendable para dispositivos mviles. Adems, tiene una gran cantidad de posibilidades que apenas se van a explotar y que an as seguirn consumiendo memoria en los terminales.
ICE
Internet Communications Engine est considerado el sucesor de CORBA. A diferencia de este, ICE tiene una implementacin oficial asociada a la especificacin. Se defini e implement por parte de miembros del comit de OMG que se encarg de definir CORBA que estaban descontentos con la lentitud del proceso de definicin de CORBA. Tiene varias diferencias con CORBA, como la sustitucin del protocolo de intercambio de mensajes (el protocolo de CORBA, GIOP, est considerado como un protocolo muy ineficiente). ICE provee una funcionalidad muy similar a la de CORBA, ampliada en algunos casos y simplificada en otros. Al igual que CORBA, ICE
22
Kora
presenta implementaciones para mltiples lenguajes de programacin.
DCOM
Distributed Component Object Model es un modelo distribuido propiedad de Microsoft. Su principal inconveniente es que ya no est soportada, adems de que no se encuentra disponible en dispositivos mviles, ni siquiera en aquellos gobernados por Windows Mobile.
Java RMI
Java Remote Method Invocation es el mecanismo propio de Java para invocar mtodos remotos. Forma parte del lenguaje desde la versin 1.1 del SDK y es similar a CORBA. Sus principales ventajas son que es ms simple que CORBA y que es ms sencillo de utilizar. Sus inconvenientes son que solo soporta Java como lenguaje de programacin y la sobrecarga que supone no utilizar gran parte de toda la funcionalidad que ofrece. Adems, no cumple completamente el estndar que define CORBA.
BlueRose
Es un middleware de comunicacin distribuida desarrollado en la Universidad de Granada, que se encuentra en un estado de desarrollo bastante avanzado. Sus principales ventajas son el soporte para mltiples lenguajes de programacin, su alto rendimiento, su bajo consumo de memoria y lo sencillo de utilizar que es. Adems, al estar siendo desarrollado en la Universidad de Granada es ms sencillo resolver problemas que puedan surgir utilizndolo. Este middleware destaca por su soporte a mltiples paradigmas de comunicacin (RPC, DCM y PubSub), su alto grado de portabilidad (soporta mltiples plataformas y lenguajes de programacin) y una alta eficiencia (de memoria, CPU y ancho de banda). Adems, soporta varias tecnologas para establecer las comunicaciones, como Ethernet, WiFi o Bluetooth.
Jose Alcal Correa
23
Kora
2. CONTEXTO
2.1. PROYECTOS PREVIOS REALIZADOS
EN LA
UNIVERSIDAD DE GRANADA
A lo largo de los ltimos aos se han desarrollado varios proyectos en la UGR que pretenden crear aplicaciones para ofrecer apoyo a personas con necesidades especiales utilzando la tecnologa, especialmente dispositivos mviles. Todos estos proyectos tienen la adaptacin a los usuarios como caracterstica comn, y el ofrecer facilidad de configuracin de las aplicaciones por parte de los los tutores. El proyecto Kora tambin se enmarca dentro de este tipo de proyectos y al igual que estos, ha estado tutelado por integrantes del grupo GEDES, de Departamento de Lenguajes y Sistemas Informticos.
Proyecto Sc@ut
El proyecto Sc@ut [Scaut] es un proyecto de investigacin del Departamento de Lenguages y Sistemas Informticos de la Universidad de Granada, con el objetivo de mejorar la capacidad comunictiva del colectivo de personas con necesidades especiales. Estos objetivos se traducen en un sistema adaptativo de comunicacin alternativa que busca: Mejorar la autonoma de los usuarios. Crear un sistema de bajo coste. Ser fcil de aprender y utilizar. Facilitar la labor pedaggica de profesores y padres. Ofrecer datos que permitan analizar el rendimiento de los alumnos.
Dentro del proyecto se han creado sistemas de comunicacin (considerados sistemas de comunicacin aumentativa) para PC, PDAs con Windows Mobile y para Nintendo DS. Tambin se ha desarrollado un editor de plantillas para PC con el objetivo de facilitar la labor de los tutores. Estas herramientas se estn utilizando para ayudar a personas con autismo, con trastornos del desarrollo o adultos que han perdido la facultad de hablar por cualquier otro motivo. En la actualidad se estn utilizando las herramientas creadas en varios centros educativos con un xito notable, y el proyecto ha contado (y sigue contando) con la colaboracin y la financiacin de la Junta de Andaluca y el CICODE, as como varios organismos y entidades a nivel nacional.
Jose Alcal Correa
24
Kora
Proyecto Picaa
Dentro del mismo grupo que Sc@ut se est desarrollando la aplicacin Picaa [Picaa], una plataforma de apoyo al aprendizaje para dispositivos mviles basados en iOS (iPod Touch, iPhone y iPad de Apple), especialmente diseada para alumnos con necesidades educativas especiales. Esta herramienta incluye tanto la vista del alumno como un completo editor de actividades para los profesores. Las actividades pueden ser actualmente del tipo asociacin, de ordenacin, exploracin y puzzles. Todas ellas son configurables mediante un editor diseado para los tutores, que personalizan su presentacin y forma de interaccin segn las necesidades de los usuarios finales. Asimismo, otra de las caractersticas ms destacadas de la aplicacin es la posibilidad de realizar las actividades colaborativamente, para ayudar en la sociabilizacin del alumno. Esta aplicacin se encuentra disponible en la App Store de Apple en [appStore].
Jose Alcal Correa
25
Kora
BlueRose
BlueRose [BlueRoseWeb] es un middleware que ha sido desarrollado por el grupo de investigacion GEDES del departamento de lenguajes y sistemas informaticos de la Universidad de Granada para satisfacer los requisitos especficos de los sistemas ubicuos y/o sensibles al contexto, y que otros middlewares ms extendidos no pueden satisfacer. Entre estos requisitos se encuentran la necesidad de dar soporte a varios paradigmas de comunicacin (por separado o de manera combinada), hacer un uso reducido de recursos, como consumo de memoria, CPU o ancho de banda, y ofrecer soporte para diversas tecnologas de comunicacin inalmbricas, como BlueTooth y Wi-Fi. BlueRose es, por tanto, un middleware ligero que permite trabajar con varios paradigmas de comunicacin distintos, de forma que el desarrollador pueda elegir el ms conveniente para cada situacin. El paradigma Remote Procedure Call (RPC) permite hacer llamadas a procedimientos que se ejecutan en mquinas remotas de forma transparente, es decir, como si se estuvieran ejecutando de forma local. El paradigma Document Centric Messaging (DCM) est orientado al intercambio de documentos y los servicios no proveen una interfaz bien definida como en el caso de RPC. Los servicios reciben los documentos y los procesan de manera sncrona o asncrona. El paradigma Publish-Subscribe (PubSub) consiste en sistemas que se suscriben a una determinada informacin y cuando sta se produce, se reciben notificaciones de la ocurrencia de dicha informacin. Este paradigma est especialmente indicado para realizar comunicacin mediante eventos (notificaciones de informacin) de forma asncrona.
Finalmente, BlueRose ha sido implementado para los lenguajes de programacin Java, C++, Objective-C, Python y C#. A diferencia de otros middlewares como CORBA, la configuracin de BlueRose es muy sencilla y se realiza mediante ficheros XML.
Jose Alcal Correa
26
Kora
2.2. SOFTWARE LIBRE

El Software Libre, segn la definicin de la Free Software Foundation [refFSF] es aquel que da al usuario la libertad de ejecutarlo, compartirlo, copiarlo, estudiarlo y modificarlo. A pesar de que suele estar disponible gratuitamente junto con el cdigo fuente, la propia definicin no impide venderlo. El modelo tpico para obtener beneficios con la creacin de software libre consiste en distribuirlo gratuitamente y ofrecer servicios relacionados con el uso del mismo. Cuando en los aos 80 comenz a venderse el software como producto de valor aadido a los computadores, comenz tambin a no publicarse el cdigo fuente de dichos programas y a incluirse licencias de uso con los mismos. En el ao 1984 Richard Stallman comenz a trabajar en el proyecto GNU (GNU is Not Unix), que pretenda ser una reimplementacin libre de Unix, y posteriormente fund la Free Software Foundation y cre la definicin de Software Libre. Segn esta definicin, el software es libre si garantiza al usuario las siguientes libertades: 0. La libertad de usar el programa con cualquier propsito. 1. La libertad de estudiar cmo funciona el programa y de adaptarlo a sus necesidades. 2. La libertad de distribuir copias del programa. 3. La libertad de mejorar el programa y hacer pblicas dichas mejoras. Como puede comprobarse, uno de los requisitos bsicos para que un programa sea libre es que su cdigo fuente est disponible. La Free Software Foundation cre tambin la licencia GNU GPL, que est orientada a proteger estas libertades en el software, permitiendo la modificacin y redistribucin del software manteniendo los derechos de autor. Esta licencia est actualmente en su versin 3. Segn la FSF no deben confundirse los trminos cdigo abierto (open source) y software libre (free software o libre software para evitar confusiones), pues aunque ambos comparten muchas caractersticas similares como la apertura del cdigo fuente, los motivos para hacerlo no son los mismos. La perspectiva del movimiento del cdigo abierto (definido por la Open Source Initiative) busca darle mayor relevancia a los beneficios prcticos de compartir y revisar el cdigo fuente, mientras que la perspectiva del movimiento del software libre busca darle mayor relevancia a los beneficios para la comunidad y a los aspectos ticos de la distribucin del software junto con su cdigo fuente.
Jose Alcal Correa
27
Kora
Debido al carcter eminentemente social de la aplicacin que se pretende desarrollar, he considerado una obligacin moral que sea software libre, de forma que sea ms fcil que pueda llegar al mayor nmero posible de personas. Otro motivo para hacer libre la aplicacin es que pueda mejorar una vez que yo acabe mi trabajo, y si alguien quiere pueda retomarla, ya sea para mejorarla o solucionar posibles fallos que puedan aparecer. Este factor tambin ha influido en la eleccin de la plataforma de desarrollo. A pesar de que el proyecto iba a realizarse inicialmente para dispositivos mviles de Apple (principalmente en previsin de una posible interoperabilidad con Picaa), finalmente se decidi elegir Android por las siguientes razones: Android es una plataforma libre. De hecho, hacer software libre para iPhone puede estar en contradiccin con ciertas clusulas de la App Store. Android se programa utilizando Java, un lenguaje cuya especificacin y biblioteca de clases son GPL3. No es necesario pagar al distribuidor para probar las aplicaciones en un dispositivo real, algo imprescindible para esta aplicacin. Esto podra limitar las contribuciones externas a la aplicacin.
Aparte del cdigo fuente, tambin se va a publicar con licencia libre el resto de contenido relacionado con la aplicacin, como la documentacin y los recursos utilizados.
Jose Alcal Correa
28
Kora
3. TECNOLOGAS
EMPLEADAS
En esta seccin se listan las tecnologas que van a utilizar en el proyecto, basndonos en lo estudiado en apartados anteriores. En el captulo de implementacin se detallarn con mayor profundidad las caractersticas de cada una de ellas.
Android
Aunque inicialmente se iba a desarrollar el proyecto para iOS, la plataforma mvil que finalmente ha sido elegida es Android, por varias razones adems de las expuestas en el apartado anterior: Disponibilidad de dispositivos muy asequibles (incluso con precios inferiores a 200). Gran cantidad posibilidades de interaccin, gracias a la combinacin de Bluetooth + Driver IME. Tambin se incluyen acelermetros, interaccin mediante voz y vibracin. Gran variedad de dispositivos: mviles, reproductores de msica, tablets y hasta coches. Facilidad y comodidad de programacin: uso de Java como lenguaje de desarrollo, SDK completo. Sin restricciones ni costes extra para poder probar e instalar en dispositivo real. Plataforma en expansin, que cada vez tiene mayor cuota de mercado.
Java
Debido a que Java es el lenguaje de programacin oficial para la plataforma Android, contamos con la enorme biblioteca de clases de Java, adems de algunas bibliotecas extra como las Commons de Apache, OpenGL ES o las bibliotecas del W3C para trabajar con XML.
XML
El estndar ms utilizado para intercambio de informacin en el mundo se utiliza bastante en la plataforma Android: para definir layouts, las propiedades de la aplicacin, las cadenas de texto, para definir estados de elementos, etctera. Adems, se utilizar para intercambiar informacin
29
Kora
entre dispositivos que tengan instalada la aplicacin de forma estndar y legible.
SQLite
Este motor de bases de datos de dominio pblico tiene la cualidad de ser muy rpido, lo cual lo hace especialmente conveniente para dispositivos mviles. Adems, soporta el estndar SQL-92.
KNX
KNX va a ser el estndar domtico elegido para implementar la aplicacin por dos razones principales: ya se dispone de material KNX en la Facultad y adems es el que suele utilizarse en Europa, a pesar de su alto coste. Sus principales ventajas son el ser un estndar Europeo reconocido a nivel internacional, la disponibilidad de herramientas de programacin y la variedad de fabricantes que venden dispositivos KNX. Un punto importante a tener en cuenta es la existencia de una biblioteca libre llamada Calimero que provee acceso a dispositivos KNX y que soporta Java nativamente. No obstante, parece estar abandonada desde 2008 aunque funciona correctamente y est bastante probada.
BlueRose
Hemos elegido este middleware de comunicacin por varias razones que lo hacen especialmente interesante para nuestro propsito. Estas razones se detallan en el apartado 2.2 del captulo de investigacin. En resumen son: Presenta un menor consumo de CPU, memoria y ancho de banda que otras opciones. Permite utilizar varios paradigmas de comunicacin. Para nuestro propsito son especialmente interesantes el paradigma de suscripcin y publicacin y la llamada a procedimiento remoto. Es muy fcil de configurar, pues apenas hay que definir un fichero XML con los parmetros de conexin, configurar las IPs de los dispositivos y definir la serializacin de los objetos. Al ser un proyecto de la UGR, el soporte tcnico y la documentacin no pueden estar ms accesibles. De hecho, ha habido realimentacin entre ambos proyectos, que se han ayudado mutuamente.
Jose Alcal Correa
30
Kora
CAPTULO III: MODELADO DE REQUISITOS

31
Kora
1. ANLISIS
DE REQUISITOS
1.1. DESCRIPCIN INFORMAL

Se pretende implementar una herramienta de control de entorno para dispositivos mviles adaptable a todos los usuarios. Las adaptaciones a realizar comprendern aspectos visuales tales como la respresentacin grfica de las acciones, el uso de unos colores u otros, la realimentacin al usuario (mediante vibracin o confirmaciones), y emisin de sonidos. La adaptacin para un usuario estar determinada por su perfil de usuario, que contendr una serie de parmetros de configuracin. La misma aplicacin podr utilizarse tanto por el usuario final (que controle los dispositivos) como por su tutor, encargado de crear los perfiles para los usuarios que vayan a utilizar el dispositivo. La aplicacin permitir la carga dinmica de nuevas representaciones para dispositivos domticos y el intercambio de perfiles de usuario entre dispositivos mviles. Tambin se crear un programa para ordenador de escritorio que har las veces de capa servidor al que se conectarn los dispositivos mviles, y que a su vez estar conectado a la centralita domtica que se pretende controlar. Esta capa intermedia es necesaria para que el acceso de la aplicacin mvil a los dispositivos domticos sea transparente e independiente de la implementacin subuyacente.
Jose Alcal Correa
32
Kora
1.2. REQUISITOS FUNCIONALES

A raz de la descripcin informal puede deducirse que la aplicacin estar compuesta por tres partes diferentes aunque relacionadas entre s. Estas son la vista de usuario de la aplicacin, desde la que se controlan los dispositivos; la vista de tutor, desde la que se gestionan los usuarios que la usarn y sus perfiles correspondientes; y una tercera vista que es la del servidor encargado de hacer de puente entre la instalacin domtica y la aplicacin mvil. Debido a que varios requisitos son compartidos por diferentes apartados de la aplicacin, se indicar con las letras U (vista de usuario), T (vista de tutor) y S (aplicacin servidora). La aplicacin contar con las siguientes caractersticas bsicas: La aplicacin se utilizar para controlar un entorno domtico. Estar diseada para ser manejada mediante dispositivos mviles. Las posibilidades de control que permita la aplicacin sern: listado de dispositivos presentes en la instalacin domtica consulta del estado de los dispositivos alteracin del estado de los dispositivos (US) La aplicacin permitir su uso por parte de varios usuarios desde el mismo dispositivo. Para tal fin se definirn usuarios y perfiles asociados que modifiquen el comportamiento de la aplicacin para un usuario dado. (UT) Se podr utilizar la aplicacin para crear, modificar y eliminar usuarios, as como sus perfiles asociados. Este apartado de configuracin permitir cambiar todos y cada uno de los campos que incluya cada perfil. (T) El aspecto de la interfaz de usuario y el comportamiento general de la aplicacin dependern del usuario que est utilizando la aplicacin en el dispositivo, y del perfil de uso que tenga asociado. Se podrn modificar: La forma de interaccin con la aplicacin. El aspecto y la apariencia de la interfaz de usuario. Los cambios de la interfaz de usuario ante las acciones del usuario. Los sonidos a reproducir cuando se realice alguna accin.
Jose Alcal Correa
33
Kora
Otras realimentaciones que puedan ofrecerse al usuario ante sus acciones. (UT) Cada dispositivo presente en el sistema tendr una representacin asociada, que consta de texto y recursos multimedia que cambian segn la configuracin del perfil de usuario actual. Esta representacin vendr dada mediante ficheros XML y una estructura de carpetas simple que incluya los recursos multimedia especificados en dicho fichero (T). Se podrn importar y exportar ficheros con definicin de usuarios y perfiles como ficheros XML de forma sencilla, con el fin de que varios usuarios puedan usar varios dispositivos mviles indistintamente. (T) La aplicacin debe soportar de forma transparente distintos estndares domticos, siendo el servidor quien se encargue de abstraer la comunicacin con los dispositivos reales existentes. (S) Ser posible configurar desde la aplicacin a qu servidor conectarse, en el caso de que haya varios disponibles. (TS)
Jose Alcal Correa
34
Kora
1.3. REQUISITOS
NO
FUNCIONALES
Los requisitos no funcionales describen cualidades del sistema que no se relacionan directamente con su funcionamiento, aunque son importantes en el contexto de uso de la aplicacin. Para este apartado se utilizar tambin el sistema de siglas para indicar a qu vista de la aplicacin son aplicables los requisitos. A continuacin se muestran los aspectos funcionales del proyecto con los que se relacionan:
Facilidad de uso. Usabilidad.

Se tendrn en cuenta las 10 reglas de J.Nielsen [Nielsen] que adaptadas a este contexto son: Visibilidad del estado del sistema en cada momento. (UTS) Uso de un lenguaje lo ms sencillo posible, que sea cercano a los usuarios. Se evitarn tecnicismos y frases complejas. Es importante el uso de iconos para conseguir este requisito. (UT) Control y libertad para el usuario para acceder a funcionalidad de la aplicacin en diferentes lugares y poder salir de estados indeseados de forma limpia. No obstante, se evitarn este tipo de situaciones en todo momento, debido al perfil de los usuarios a los que est dirigida la aplicacin. (U) Consistencia y uso de estndares a la hora de utilizar y nombrar los trminos, los controles de las interfaces y la metodologa y procesos empleados. (UTS) Prevencin de errores ofreciendo formularios y mens con opciones cerradas. (UTS) Minimizar la carga de la memoria del usuario mostrando al usuario informacin de lo que est haciendo en cada momento, de lo que ha hecho, de cmo ha llegado a un lugar concreto de la aplicacin. Mostrar tambin dilogos con mensajes cortos y secuencias cortas de ventanas para llevar a cabo tareas, con un nivel de anidamiento mnimo. Usar asistentes para ayudar al usuario a la realizacin de tareas que supongan la secuenciacin de ms de una funcionalidad en diferentes lugares de la aplicacin. (UTS) Flexibilidad y eficiencia de uso: permitir la realizacin de las actividades de la forma ms rpida y fcil posible, especialmente las ms frecuentes (UT). Uso de dilogos estticos y diseo minimalista. (UT)
Jose Alcal Correa
35
Kora
Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores, mostrando mensajes en un lenguaje claro y permitiendo deshacer acciones del usuario. (UTS) Ayuda y documentacin: facilitar que el programa pueda usarse sin documentacin, proporcionando asistentes. De todos modos, proporcionar tambin ayuda on-line, realizar manuales de usuario y ofrecer cursos de formacin para los usuarios. (UTS)
Accesibilidad (U)
Control con un solo botn: Se puede realizar una interaccion tctil o usando perifrico. Tambin se debe incorporar interaccin por barrido. Kora proporcionar tres tipos de barrido para ayudar a seleccionar: Filas y celdas en la fila: barrido por filas Celda a celda: barrido por celdas Una imagen por pantalla: barrido 1x1
Control con una sola mano: la pantalla tctil de los dispositivos donde se puede ejecutar el comunicador (mviles, tablets, dispositivos de msica) permite la interaccin con una sola mano. Para algunos tambin es posible la interaccin mediante dispositivos externos conectados mediante Bluetooth. Control mediante movimiento: es posible con un perifrico adaptado y el modo de barrido, que trasforme el movimiento en una seleccin del componente resaltado. Velocidad configurable: puede elegirse el tiempo de barrido y el tiempo que tardar en mostrarse una nueva plantilla. Tambin es configurable, si se desea, el tiempo que debe mostrarse una imagen en pantalla, impidiendo cambiar a otra antes de tiempo. Informacin Sonora: se proporcionan al usuario sonidos, voces o frases grabados o sintetizados a partir del nombre de los dispositivos domticos o las acciones realizadas sobre los mismos. Informacin visual: Las imgenes que representan a los dispositivos pueden ser pictogramas, fotografas o dibujos para representar objetos y acciones. Es variable el nmero de imgenes, que se adaptan al tamao de la pantalla. Se presenta una imagen distinta segn el estado de un dispositivo. Puede elegirse si se muestra o no el nombre del dispositivo.
Fiabilidad. Robustez.
El sistema debe evitar en todo momento la frustracin del usuario o
Jose Alcal Correa
36
Kora
los eventos no previstos, como mensajes de error. (US) Es muy importante que el sistema funcione siempre correctamente, pues de l podra depender la seguridad e integridad fsica del usuario (US). No obstante, la aplicacin debe guardar informes de posibles excepciones o situaciones anmalas que puedan suceder, para su posterior revisin por parte de los tutores. (US) El sistema debe permitir acceso dispositivos al mismo tiempo. (S) concurrente desde varios
La modificacin de valores de los actuadores debe de ser fiable y reflejarse inmediatamente en todos los dispositivos mviles presentes en el sistema. (S)
Rendimiento
Al ser una aplicacin diseada para dispositivos mviles, este es un aspecto importante que juega un gran papel. Es importante que la aplicacin responda rpidamente para evitar la frustracin del usuario en la medida de lo posible. (U) El uso de un protocolo de comunicacin rpido y eficiente es importante para que la respuesta del sistema sea rpida. En el caso contrario podran producirse situaciones de riesgo para el usuario. (US) Un bajo consumo de recursos es importante para aumentar la duracin de la batera. (UT)
Soporte
El sistema debe ser extensible. Es decir, deben poderse aadir nuevos dispositivos y sus representaciones sin necesidad de recompilar la aplicacin. (UT) Adems, debe ser sencilla la adicin de nuevas representaciones. (T) La aplicacin para dispositivos mviles debe soportar correctamente todos aquellos que funcionen con Android, sean cuales sean sus caractersticas o tamao de pantalla. (UT) Al ser libre la aplicacin, la adicin de funcionalidad extra o arreglo de fallos siempre ser posible. Se proporcionaran tanto cdigo como documentacin para que esto sea posible. (UTS)
Jose Alcal Correa
37
Kora
Interfaz de comunicacin (S)

La interfaz de comunicacin del servidor debe de ser sencilla para que otras aplicaciones puedan conectarse al mismo. Debe ser ampliable pero manteniendo la compatibilidad hacia atrs en el caso de que se le quieran aadir nuevas caractersticas. El tamao de los paquetes debe ser pequeo para utilizar los mnimos recursos de red. Esto proporciona ventajas de rendimiento, reduccin del uso de batera de los dispositivos mviles y mejor soporte de concurrencia. La interfaz de comunicacin debe de ser capaz de notificar a todos los dispositivos conectados al servidor de los cambios que se produzcan en el sistema.
Jose Alcal Correa
38
Kora
1.4 ACTORES
DEL SISTEMA
Cada una de las tres vistas del sistema tiene un conjunto de actores distinto que realizar operaciones distintas sobre dicha vista. Las dos primeras vistas estn implementadas en la aplicacin para dispositivo mvil, mientras que la vista de servidor es una capa intermedia que se sita entre los dispositivos mviles y los dispositivos domticos.
Actor Descripcin
Usuario final
A01
Usuario que utiliza la aplicacin para dispositivo mvil con el fin de obtener informacin del entorno domtico y realizar acciones sobre el mismo. Actor principal.
Tipo Comentarios
Actor Descripcin Tipo Comentarios
Tutor del usuario final
A02
Usuario que utiliza el gestor de perfiles de la aplicacin para adaptarla a un usuario final concreto. Actor de apoyo.
Actor Descripcin
Dispositivo de la instalacin domtica
A03
Dispositivo que proporciona uno o varios valores con informacin sobre el entorno y que (opcionalmente) permite que uno o varios de ellos sean modificados. La modificacin de uno o varios valores suele conllevar un cambio en el entorno. Actor de apoyo. No tiene por qu corresponderse exactamente con un dispositivo fsico de la instalacin, pues podra ser la composicin de un sensor y un actuador (por ejemplo, una bombilla y un sensor de presencia).
Tipo Comentarios
Jose Alcal Correa
39
Kora
2. CASOS
DIAGRAMAS
DE
DE
USO
DE
CASOS
USO
Desde el punto de vista del usuario final:
Jose Alcal Correa
40
Kora
Desde el punto de vista del tutor:
Jose Alcal Correa
41
Kora
DIAGRAMA
DE
PAQUETES
El diagrama de paquetes facilita la comprensin del sistema, mostrando la descomposicin del mismo en subsistemas ms sencillos.
Jose Alcal Correa
42
Kora
Gracias al diagrama de paquetes, se han distinguido tres subsistemas en la aplicacin, que estn estrechamente relacionados con el actor principal que interacta con cada uno de ellos: Subsistema de control de dispositivos: es la actividad principal de la aplicacin, donde se mostrarn al usuario los dispositivos, el estado de los mismos y las operaciones a realizar con ellos. Subsistema de configuracin de la aplicacin y gestin de usuarios: Subsistema de gestin de representaciones: actividad en la que el tutor consulta, aade o modifica las representaciones de dispositivos que el sistema soporta. Subsistema de gestin de usuarios: donde se agrupan las operaciones para crear, modificar o borrar usuarios. Subsistema de gestin de perfiles de usuario: en este subsistema, el tutor crea, copia, modifica o borra perfiles de usuario que pueden asignarse a los usuarios definidos en el sistema. Subsistema de gestin de perfiles de dispositivo: en este subsistema, el tutor crea, copia, modifica o borra perfiles de dispositivos que pueden asignarse a los usuarios definidos en el sistema. Subsistema de configuracin de la aplicacin: actividad donde se puedne modificar los parmetros de configuracin global de la aplicacin. Subsistema de manejo de eventos y gestin de dispositivos: subsistema en el que participan tanto el servidor como la aplicacin. El servidor se encarga de mantener la lista de dispositivos conectados a l, de ejecutar las acciones que solicitan los usuarios, y de notificar a todos los usuarios de cambios que se produzcan en el sistema.
Jose Alcal Correa
43
Kora
DESCRIPCIN
DE LOS
CASOS
DE
USO
Paquete control de dispositivos

Caso de uso Actores Resumen Listar dispositivos Usuario Se muestra al usuario una lista con los dispositivos activos en el momento de utilizar la aplicacin. CD01
Dependencias Es una generalizacin del caso de uso CD02. Incluye el caso de uso CD06. Precondicin Postcondicin Curso normal 1. Se inicia la actividad de control de dispositivos. 2. El sistema muestra un listado con todos los dispositivos a los que se puede acceder. Cursos alternativos 1. Se ha terminado de interactuar con un dispositivo y se desea volver a mostrar el listado. Debe haberse iniciado la aplicacin en el modo control de dispositivos.
Requisitos no - Para mostrar la lista de dispositivos se seguirn las reglas de usabilidad y accesibilidad indicadas en los requisitos no funcionales funcionales. Comentarios La relacin de este caso de uso con CD02 y CD06 viene dada porque en el listado de dispositivos tambin se muestra el estado de los mismos.
Caso de uso Actores Resumen
Consultar el estado de los dispositivos Usuario
CD02
Se consulta el estado actual de los dispositivos activos en el momento de utilizar la aplicacin.
Dependencias Incluye el caso de uso CD05. Antes de mostrar los dispositivos, debe conocerse cules hay, y el estado en que se encuentran.
44
Kora
Precondicin
La aplicacin se ha iniciado en modo control dispositivos. La aplicacin debe estar conectada al servidor.
de
Postcondicin Curso normal 1. Cuando el usuario desea mostrar la lista de dispositivos, se muestra tambin su estado actual. Cursos alternativos Requisitos no funcionales Comentarios Caso de uso Actores Resumen Elegir dispositivo Usuario El usuario elige un dispositivo para consultar su estado o comenzar a interactuar con el mismo. CD03 1. Cuando el usuario elige un dispositivo, se muestra su estado actual.
Dependencias Incluye el caso de uso CD06. Precondicin Debe existir al menos un dispositivo en el sistema.
Postcondicin Se inicia la actividad de consulta y manejo de dispositivo. Curso normal 1. El usuario elige un dispositivo de entre la lista de dispositivos activos. 2. Se muestra el estado del dispositivo y una serie de controles para interactuar con el mismo. Cursos alternativos Requisitos no - El estado del dispositivo se mostrar al usuario en funcin de su representacin asociada (texto y recursos multimedia). funcionales - Para mostrar el estado y los controles se seguirn las reglas de usabilidad y accesibilidad indicadas en los requisitos no funcionales. Comentarios
Jose Alcal Correa
45
Kora Caso de uso Actores Resumen
Interactuar con dispositivo Usuario El usuario interacta con el dispositivo elegido
CD04
Dependencias Incluye el caso de uso CD07. Precondicin Postcondicin Curso normal 1. El usuario elige uno de los controles para el dispositivo elegido. 2. El usuario interacta con dicho control. Cursos alternativos Requisitos no - La interaccin con los controles vendr dada por el perfil de usuario asociado al usuario actual. funcionales Comentarios Caso de uso Actores Resumen Dependencias Precondicin La aplicacin debe estar conectada al servidor. dispositivos interna a la aplicacin est Consultar estado al servidor Usuario Se consulta al servidor el estado de todos los dispositivos presentes en el sistema. CD05 Debe haberse elegido un dispositivo (CD03).
Postcondicin La lista de actualizada. Curso normal
1. Se enva al servidor una peticin para que devuelva la lista de dispositivos domticos. 2. El servidor responde con un listado que incluye los datos y el estado de todos los dispositivos domticos presentes en el sistema.
Cursos alternativos
Jose Alcal Correa
46
Kora
Requisitos no funcionales Comentarios Este caso de uso no est directamente iniciado por el usuario. Es la aplicacin la que consulta automticamente al servidor antes de mostrar la lista de dispositivos. Recibir cambio en valor de dispositivo Usuario, Servidor Evento que el servidor enva a todos los dispositivos mviles presentes en el sistema cuando se produce un cambio en el valor de un dispositivo domtico. CD06
Dependencias Precondicin El dispositivo debe existir en el sistema.
Postcondicin Se actualiza en la aplicacin para dispositivo mvil el estado del dispositivo domtico que indica el evento. Curso normal 1. La aplicacin recibe el evento de forma asncrona. 2. Se decodifica el contenido del evento. 3. Se asigna a la representacin interna del dispositivo que indica el evento, el nuevo valor que incluye el evento. Cursos alternativos Requisitos no funcionales Comentarios Este caso de uso no requiere intervencin del usuario, pues se produce en segundo plano y sin conocimiento del mismo. El refresco de los estados de dispositivos se hace de manera asncrona mediante un modelo de eventos.
Jose Alcal Correa
47
Kora
Modificar valor de dispositivo Usuario
CD07
Se modifica el valor que representa el estado de un dispositivo, en la representacin interna de la aplicacin.
Dependencias Incluye el caso de uso CD08. Precondicin El usuario ha interactuado con un control que le permite elegir el estado que quiere que tenga un dispositivo domtico. El dispositivo existe en el sistema.
Postcondicin Curso normal 1. Se modifica el estado de la representacin interna de un dispositivo. 2. Se inicia el caso de uso CD08. Cursos alternativos Requisitos no funcionales Comentarios Este caso de uso no requiere de la intervencin directa del usuario, sino que se inicia como parte del caso de uso CD04. Enviar valor al servidor Usuario, Servidor La aplicacin para dispositivo mvil enva un evento al servidor con el valor que representa un nuevo estado para un dispositivo domtico. CD08
Dependencias Precondicin La aplicacin est conectada al servidor. El dispositivo est presente en la instalacin domtica.
Postcondicin Se modifica efectivamente el estado del dispositivo elegido. Se notifica a todos los usuarios del nuevo valor que representa dicho estado.
Jose Alcal Correa
48
Kora
Curso normal 1. La aplicacin de usuario enva al servidor un evento que indica el dispositivo cuyo estado se desea modificar, y el valor que representa dicho estado. 2. El servidor recoge el evento y lo decodifica. 3. El servidor busca en la lista de dispositivos el que indica el evento y, dependiendo de su tipo, le asigna el nuevo valor. Cursos alternativos Requisitos no funcionales Comentarios Este caso de uso no requiere la intervencin directa del usuario y se inicia a partir del caso de uso CD07.
Jose Alcal Correa
49
Kora
Paquete gestin de representaciones

Caso de uso Actores Resumen Dependencias Precondicin Postcondicin Curso normal 1. Se muestra un listado con todas las representaciones de dispositivo. 2. El tutor navega por dicho listado. 1. El tutor elige una representacin concreta. 2. Se muestra el listado de ficheros de texto y multimedia que componen dicha representacin. Cursos alternativos Requisitos no funcionales Comentarios Caso de uso Actores Resumen Aadir representacin de dispositivo Tutor El tutor aade una nueva representacin de dispositivo al sistema, que podr ser utilizada para representar dispositivos de una clase concreta. GR02 Consultar representaciones de dispositivo Tutor El tutor consulta la lista de representaciones de dispositivo que tiene la aplicacin, as como el contenido de las mismas. GR01
Dependencias Incluye el caso de uso GR01. Precondicin Debe mostrarse previamente un listado con todas las representaciones ya existentes. La representacin a aadir no debe llamarse como otra ya existente.
Postcondicin Se ha aadido una nueva representacin de dispositivos.

50
Kora
Curso normal 1. Se inicia el caso de uso GR01. 2. El tutor elige los ficheros que incluir la representacin a aadir. 3. El tutor aade dichos ficheros a la nueva representacin. 4. El sistema detecta la nueva representacin y la aade a la lista de las existentes. Cursos alternativos Requisitos no funcionales Comentarios Caso de uso Actores Resumen Eliminar representacin de dispositivos Tutor El tutor elimina una de las representaciones de dispositivo presentes en el sistema. GR03
Dependencias Incluye el caso de uso GR01. Precondicin Debe mostrarse previamente un listado con todas las representaciones ya existentes. La representacin a eliminar existe en el sistema.
Postcondicin Se ha eliminado una representacin de dispositivos. Curso normal 1. Se inicia el caso de uso GR01. 2. El tutor elige los ficheros que componen la representacin a eliminar. 3. El sistema detecta dicha eliminacin y se quita dicha representacin de la lista. Cursos alternativos Requisitos no funcionales Comentarios
Jose Alcal Correa
51
Kora
Paquete gestin de usuarios

Caso de uso Actores Resumen Dependencias Precondicin Postcondicin Curso normal 1. El tutor solicita la lista de usuarios. 2. La aplicacin devuelve dicha lista. Cursos alternativos Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios Caso de uso Actores Resumen Dependencias Es una generalizacin del caso de uso GU03. Precondicin No puede existir un usuario con el mismo nombre en el sistema. Aadir usuario Tutor GU02 Debe existir al menos un usuario en el sistema. Listar usuarios Tutor El tutor solicita a la aplicacin una lista con todos los usuarios que existen en el sistema. GU01
Postcondicin El usuario creado se aade a la lista de usuarios de la aplicacin. Curso normal 1. 2. 3. 4. El tutor solicita aadir un usuario a la lista. Se crea un usuario temporal con los datos vacos. Se rellenan los datos del nuevo usuario. Se aade el usuario creado a la lista de usuarios.
Jose Alcal Correa
52
Kora Cursos alternativos
Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios Caso de uso Actores Resumen Dependencias Precondicin El usuario existe en el sistema y es modificable. Si se modifica el nombre del usuario, este no debe existir previamente en el sistema. Modificar usuario Tutor El tutor modifica un usuario presente en el sistema. GU03
Postcondicin Curso normal 1. El tutor solicita modificar un usuario de los presentes en el sistema. 2. El tutor modifica los datos previos de dicho usuario. 3. Se registra la modificacin en la lista de usuarios del sistema. Cursos alternativos Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios Caso de uso Actores Resumen Dependencias Precondicin El usuario existe en el sistema y es modificable. Eliminar usuario Tutor El tutor elimina un usuario presente en el sistema. GU04
Jose Alcal Correa
53
Kora
Postcondicin Curso normal 1. El tutor solicita eliminar un usuario de los presentes en el sistema. 2. Se quita el usuario de la lista de usuarios del sistema. Cursos alternativos Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios Caso de uso Actores Resumen Dependencias Precondicin Postcondicin Curso normal 1. El tutor solicita al sistema que el usuario elegido sea el que determine la configuracin de la actividad de control. 2. El sistema marca dicho usuario como el actual. Cursos alternativos Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios El usuario existe en el sistema. Seleccionar usuario actual Tutor El tutor indica el usuario para el que se adaptar la interfaz de control. GU05
Jose Alcal Correa
54
Kora
Paquete gestin de perfiles de uso

Caso de uso Actores Resumen Dependencias Precondicin Postcondicin Curso normal 1. El tutor solicita la lista de perfiles de usuario. 2. La aplicacin devuelve dicha lista. Cursos alternativos Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios Caso de uso Actores Resumen Dependencias Es una generalizacin del caso de uso GPU03. Precondicin No puede existir un perfil de uso con el mismo nombre en el sistema. Aadir perfil de uso Tutor GPU02 Debe existir al menos un perfil de uso en el sistema. Listar perfiles de uso Tutor El tutor solicita a la aplicacin una lista con todos los perfiles de uso que existen en el sistema. GPU01
Postcondicin El perfil de uso creado se aade a la lista de usuarios de la aplicacin. Curso normal 1. 2. 3. 4. El tutor solicita aadir un perfil de usuario a la lista. Se crea un perfil de uso temporal con los datos vacos. Se rellenan los datos del nuevo perfil de uso. Se aade el perfil de uso creado a la lista de usuarios.
Jose Alcal Correa
55
Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios Caso de uso Actores Resumen Modificar perfil de uso Tutor El tutor modifica un usuario presente en el sistema. GPU03
Dependencias Incluye los casos de uso GPU04, GPU05, GPU06 y GPU07. Precondicin El usuario existe en el sistema y es modificable. Si se modifica el nombre del usuario, este no debe existir previamente en el sistema.
Postcondicin Curso normal 1. El tutor solicita modificar un usuario de los presentes en el sistema. 2. El tutor modifica los datos previos de dicho usuario. 3. Se registra la modificacin en la lista de usuarios del sistema. Cursos alternativos Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios Caso de uso Actores Resumen Dependencias Precondicin
Jose Alcal Correa
Modificar opciones de interaccin Tutor
GPU04
El tutor modifica las opciones de interaccin para el perfil de uso elegido.
El perfil de uso cuyas opciones se quieren modificar existe

56
Kora
en el sistema o se est creando. Postcondicin Curso normal 1. El tutor solicita modificar las opciones de interaccin del perfil de uso que est modificando. 2. El tutor modifica los datos previos de dichas opciones. 3. Se registran los cambios en el perfil de uso que se est modificando. Cursos alternativos Requisitos no funcionales Comentarios Caso de uso Actores Resumen Dependencias Precondicin Postcondicin Curso normal 1. El tutor solicita modificar las opciones de visualizacin del perfil de uso que est modificando. 2. El tutor modifica los datos previos de dichas opciones. 3. Se registran los cambios en el perfil de uso que se est modificando. Cursos alternativos Requisitos no funcionales Comentarios El perfil de uso cuyas opciones se quieren modificar existe en el sistema o se est creando. Modificar opciones de visualizacin Tutor El tutor modifica las opciones de visualizacin para el perfil de uso elegido. GPU05
Jose Alcal Correa
57
Kora Caso de uso Actores Resumen
Modificar opciones de realimentacin Tutor
GPU06
El tutor modifica las opciones de realimentacin para el perfil de uso elegido.
Dependencias Precondicin Postcondicin Curso normal 1. El tutor solicita modificar las opciones de realimentacin del perfil de uso que est modificando. 2. El tutor modifica los datos previos de dichas opciones. 3. Se registran los cambios en el perfil de uso que se est modificando. Cursos alternativos Requisitos no funcionales Comentarios Caso de uso Actores Resumen Dependencias Precondicin Postcondicin Curso normal 1. El tutor solicita modificar las opciones de sonido del perfil de uso que est modificando. 2. El tutor modifica los datos previos de dichas opciones. 3. Se registran los cambios en el perfil de uso que se est modificando.
El perfil de uso cuyas opciones se quieren modificar existe en el sistema o se est creando.
Modificar opciones de sonido Tutor
GPU07
El tutor modifica las opciones de sonido para el perfil de uso elegido.
El perfil de uso cuyas opciones se quieren modificar existe en el sistema o se est creando.
58
Requisitos no funcionales Comentarios Caso de uso Actores Resumen Dependencias Precondicin Postcondicin Curso normal 1. El tutor solicita eliminar un perfil de uso de los presentes en el sistema. 2. Se quita el perfil de uso de la lista del sistema. Cursos alternativos Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios Caso de uso Actores Resumen Dependencias Precondicin Hay un usuario actual elegido, que existe en el sistema y es modificable. El perfil de uso que se le va a asignar tambin existe. Asignar perfil al usuario actual Tutor El tutor indica el perfil de uso que configurar la actividad de control de dispositivos para el usuario actual. GPU09 El perfil de uso existe en el sistema y es modificable. Eliminar perfil de uso Tutor El tutor elimina un perfil de uso presente en el sistema. GPU08
Postcondicin
59
Kora
Curso normal 1. El tutor solicita al sistema que el perfil de uso elegido sea utilizado por el usuario actual. 2. El sistema asigna el perfil de uso a dicho usuario. Cursos alternativos Requisitos no Se seguirn los requisitos de usabilidad listados en la lista de requisitos no funcionales. funcionales Comentarios
Jose Alcal Correa
60
Kora
Paquete configuracin de la aplicacin

Caso de uso Actores Resumen Dependencias Precondicin Postcondici n Curso normal 1. El tutor elige cambiar la configuracin de la aplicacin. 2. El tutor modifica los valores que representan dicha configuracin. 3. El sistema guarda dichos valores y los aplica inmediatamente. Cursos alternativos Requisitos no funcionales especficos Cambiar la configuracin de la aplicacin Tutor El tutor cambia las opciones globales de la aplicacin, que afectarn a todos los usuarios por igual. CA01
Jose Alcal Correa
61
Kora
CAPTULO IV: ANLISIS
Jose Alcal Correa
62
Kora
1. NORMAS
DE
ACCESIBILIDAD
Actualmente no existe ningn estndar universal de accesibilidad. No obstante, estudiaremos dos proyectos de accesibilidad que son utilizados ampliamente: El Web Access Initiative (WAI), que se considera el estndar de accesibilidad en la Web. El proyecto de accesibilidad de GNOME, uno de los escritorios libres ms importantes y el que tiene mejor soporte de accesibilidad.
1.1. ACCESIBILIDAD WEB: WAI

La Web Access Initiative [WAI] es un estndar del W3C [W3C] publicado en 1997 con el objetivo de hacer la web accesible a navegadores adaptados para usuarios con discapacidad, que pueden requerir de visualizaciones modificadas y mtodos de interaccin adaptados a sus necesidades [WAI2]. Este estndar tiene adems como efecto colateral una mejor adaptacin para todo tipo de dispositivos que acceden a la web, como PDAs o telfonos mviles. Dentro de la especificacin que provee este proyecto, nos interesan dos apartados especialmente: las directrices de accesibilidad para el contenido web (WCAG, [WCAG]) y la especificacin para las aplicaciones de Internet enriquecidas (Rich Internet Applications, que proveen funcionalidad similar a las aplicaciones de escritorio).
Directrices de accesibilidad para el contenido web (WCAG)

Estas pautas estn clasificadas en tres niveles de prioridad. Cuantos ms puntos cumpla una pgina web, mejor ser su nivel de conformidad. Los puntos ms importantes de cada nivel de prioridad son los siguientes [WCAGChecklist]: 1. Prioridad 1: se tiene que satisfacer los siguientes puntos. En caso contrario, uno o ms grupos de usuarios encontrarn imposible acceder a la informacin del documento. Satisfacer estos puntos es bsico para que algunos grupos puedan usar el documento. Proporcionar texto equivalente para todo elemento no textual (como imgenes, animaciones, vdeos o sonidos).
63
Kora
Toda la informacin transmitida a travs de colores debe estar disponible sin color. Dicha informacin debe transmitirse entonces mediante el contexto o por marcadores. Organizar el documento de forma que pueda leerse sin hoja de estilo. Los contenidos equivalentes de un contenido dinmico deben actualizarse cuando cambia el contenido dinmico. Evitar destellos en pantalla. Utilizar un lenguaje claro y simple. Indicar encabezados en tablas, tanto para filas como para columnas. Proporcionar lectura en voz alta del texto equivalente a un elemento multimedia. 2. Prioridad 2: se deben satisfacer estos puntos de verificacin. De otra forma, uno o ms grupos encontrarn dificultades en el acceso a la informacin del documento. Satisfacer este punto de verificacin eliminar importantes barreras de acceso a los documentos Web. Los colores de fondo y primer plano deben tener suficiente contraste para que sean percibidas por personas con problemas de percepcin de color o que usen pantallas en blanco y negro. Crear documentos que estn validados por las gramticas formales publicadas. Utilizar hojas de estilo para maquetar, y unidades relativas en vez de absolutas para especificar tamaos y posiciones. Utilizar encabezados documento. para transmitir la estructura del
Marcar las listas y los elementos que las componen. No crear pginas que se actualicen automticamente de forma peridica. No provocar apariciones repentinas de nuevas ventanas o dilogos. No cambiar la ventana actual sin informar al usuario. Identificar claramente el objetivo de cada vnculo. Utilizar mecanismos de navegacin de forma coherente. Asegurarse de que los manejadores independientes del dispositivo de entrada. de eventos sean
Jose Alcal Correa
64
Kora
3. Prioridad 3: se puede satisfacer este punto de verificacin. En caso contrario, usuarios concretos no podrn acceder a la informacin del documento. Este punto mejora la accesibilidad de los documentos web. Identificar el idioma del documento. Crear un orden lgico de navegacin entre elementos del documento. Indicar al usuario cul es la posicin actual del documento. Localizar la informacin destacada al principio de los prrafos o listas. Complementar las acciones realizadas con realimentaciones grficas (como resaltado de bordes o contenido) o auditivas para facilitar la comprensin de las acciones. Crear un estilo coherente para todas las pginas. Incluir sugerencias o valores por defecto en los campos vacos que deba rellenar el usuario.
Jose Alcal Correa
65
Kora
1.2. DIRECTRICES
DE
ACCESIBILIDAD
DE
GNOME
Las directrices de accesibilidad del entorno de escritorio GNOME (GNOME Accesibility Guidelines) son un conjunto de indicaciones que dicho entorno de escritorio sugiere seguir para hacer accesibles las aplicaciones que pertenecen a dicho proyecto. GNOME [GNOME] es el entorno de escritorio libre ms utilizado en el mundo. Dentro de este proyecto se incluye el GNOME Accesibility Project [GNOMEAccesibility], cuyo objetivo es crear aplicaciones y guas estndar que ayuden a las personas con accesibilidad a utilizar el entorno de escritorio. Provee soluciones como un teclado en pantalla, un lector de pantalla y diferentes adaptaciones para el ratn. Tambin se incluye la herramienta Accerciser [Accerciser], que permite evaluar la accesibilidad de una aplicacin. GNOME utiliza como toolkit bsico de desarrollo la biblioteca grfica GTK+, que incluye una API especfica para permitir que las aplicaciones desarrolladas con dicha biblioteca sean fcilmente interpretadas por herramientas como lectores de pantalla o mtodos de interaccin alternativos. Casi todas las distribuciones de GNU/Linux orientadas al usuario incluyen GNOME como entorno de escritorio por defecto. Entre ellas se encuentran Ubuntu [Ubuntu], Debian [Debian] o Guadalinex [Guadalinex]. Esta ltima distribucin ha sido desarrollada por la Junta de Andaluca y presta una especial atencin a su accesibilidad, pues su objetivo es ser utilizada en todos los ordenadores pblicos de la Comunidad Autnoma. Las directrices ms importantes son [GNOMEGuidelines]: 1. Navegacin mediante teclado Proveer acceso mediante teclado a todas las caractersticas de la aplicacin, pues algunos usuarios no pueden usar el ratn. Todos los elementos deben soportar interaccin mediante ambos dispositivos. Seguir un orden lgico de navegacin mediante teclado, que requiera el mnimo de pulsaciones posible. No sobreescribir las soluciones estndar de accesibilidad del sistema, como el control del ratn mediante teclado. Tampoco las acciones estndar de las teclas: por ejemplo, la tecla
Jose Alcal Correa
66
Kora
tabulador solo debera usarse para navegar por los elementos de la interfaz y la tecla F1 para mostrar ayuda. No requerir pulsaciones de teclas simultneas.
2. Interaccin mediante ratn No depender de los botones secundarios del ratn. Hay pulsadores adaptados que solo tienen el primero y sera una limitacin para ellos no poder acceder a dichos botones. Permitir cancelar todas las operaciones de ratn, como arrastrar y soltar. Dar realimentacin visual de todas las operaciones realizadas, incluyendo clicks y posicionamiento del ratn sobre objetivos vlidos. No restringir el movimiento del ratn, pues puede interferir con tecnologas de asistencia.
3. Elementos grficos No definir en cdigo atributos como borde, sombreado o fondo. Deberan leerse del tema de sistema. Dar nombres descriptivos a todos los elementos de la interfaz, para que lectores de pantalla puedan describirlos. Permitir que los elementos multicolor se muestren monocromo (que solo soporta primer plano y fondo). Delimitar claramente los funcionalidad. elementos y organizarlos en
segn
Permitir desactivar elementos que puedan distraer al usuario y que no sean bsicas, como imgenes o animaciones.
4. Tipografas y texto No establecer manualmente tamaos ni tipos de letra, deben leerse del tema de sistema. No usar la misma etiqueta varias veces en la misma pantalla. Posicionar las etiquetas lgicamente junto a los elementos que describen. Cuando se posicione un texto junto a un control, terminarlo con dos puntos. Por ejemplo, cuando se trata de la descripcin de una caja de texto.
Jose Alcal Correa
67
Kora
5. Color y contraste No establecer manualmente los colores de la interfaz. Permitir que sea el tema de sistema el que los configure. No usar el color como nico mtodo para distinguir elementos de informacin. Debe complementarse con otro mtodo como forma, posicin o descripcin textual. Soportar todos los temas de alto contraste de GNOME, de forma que el texto se siga mostrando correctamente y haga contraste con el fondo.
6. Ampliacin Permitir ampliar el rea de trabajo. Integrar dicha opcin de ampliacin en la aplicacin.
7. Sonido No asumir que el usuario tendr acceso a informacin auditiva. Podra suceder que no tuviera sonido en su sistema o que tuviese problemas auditivos. Permitir configurar frecuencia y volumen de los avisos del sistema.
8. Animaciones No utilizar elementos que aparezcan y desaparezcan con una frecuencia superior a 55Hz. Esta frecuencia debera ser configurable. Estos elementos deberan ser pequeos. Hacer las animaciones opcionales.
9. Foco 10. Iniciar el foco en el control ms usado, y si no hay ninguno que destaque, en el primero que se muestra. Mostrar la posicin del foco claramente mediante pequeos cambios en el fondo o el borde del elemento. Mostrar el foco solo en la ventana activa. Temporizacin No programar a mano cuentas atrs ni otras caractersticas temporales. Deberan personalizarse a nivel de aplicacin o de entorno.
Jose Alcal Correa
68
Kora 11.
Documentacin Proveer toda la documentacin en formato accesible. ASCII y HTML son formatos bien soportados por tecnologas de accesibilidad. Proveer descripciones textuales para todos los grficos de la documentacin. Documentar todas las caractersticas implementadas en la aplicacin. de accesibilidad
Jose Alcal Correa
69
Kora
1.3. CONCLUSIONES
Habiendo estudiado las caractersticas de estos dos estndares de accesibilidad, puede deducirse que son muy similares y tratan prcticamente los mismos puntos de la misma forma, aunque cada uno est ms enfocado al mbito para el que estn descritos. El WAI est orientado a la presentacin de informacin ms esttica que dinmica, mientras que las GAG estn ms orientadas a la interaccin del usuario con las aplicaciones. En resumen, los puntos ms destacables de ambas recomendaciones y que se deben implementar en Kora son: Interaccin simple y sencilla, pero que requiera pocos pasos para realizar acciones. As se evita sobrecargar la memoria del usuario. Mostrar texto e imgenes en la interfaz de usuario. La aplicacin debe soportar de forma nativa visualizacin en modo de alto contraste o monocromo. La organizacin de los elementos debe ser sencilla. La navegacin por las pantallas debe ser coherente, ordenada y lgica. Es decir, las distintas pantallas deben ser similares y mantener una estructura similar. Evitar destellos y cambios bruscos. Evitar informacin irrelevante o que pueda despistar al usuario. Hay que mantener la atencin del usuario en los elementos activos. Utilizar un lenguaje claro, conciso y cercano al usuario. Proporcionar lectura de pantalla para usuarios con problemas visuales. Identificar claramente los vnculos y los elementos que realizan acciones. Manejo de eventos independiente de la entrada. La aplicacin debe soportar distintas formas de interaccin. Indicar la ubicacin actual del usuario. Ofrecer distintas realimentaciones ante las posibles acciones a realizar. Tambin cuando se pase por encima de un elemento interactivo o cuando se haya elegido uno de ellos.
Jose Alcal Correa
70
Kora
2. REPRESENTACIN GENRICA DOMTICOS.
DE
DISPOSITIVOS
Uno de los puntos ms importantes que aparecen en el modelado de requisitos es que se pueda acceder a distintas instalaciones domticas mediante la misma aplicacin. Es posible que las instalaciones domticas estn organizadas de distinta manera, e incluso que cumplan estndares distintos. Por tanto, es importante plantear en la fase de anlisis cmo el sistema va a enfrentarse a este problema que consiste en soportar cualquier tipo de instalacin domtica disponible en el mercado.
2.1. ANLISIS DETALLADO DE SISTEMAS COMERCIALES. DIRECCIONAMIENTO Y VALORES.

X-10
La mayora de dispositivos que implementan el estndar X-10 incorporan controles individuales para establecer su direccin. Las direcciones estn compuestas por dos campos de 4 bits: el primero se llama House Code y tiene 16 posiciones desde la A a la P; el segundo se llama Unit Code, y tiene tambin 16 posiciones que van desde el 1 hasta el 16. As, en cada instalacin es posible tener un mximo de 256 dispositivos, desde el A1 hasta el P16, lo cual limita a este sistema al mbito domstico y de pequeas empresas. Este estndar tiene solo 16 cdigos de operacin distintos y no soporta tipos de dato como booleanos, enteros o cualquier otra representacin. Los cdigos son los siguientes:
Cdigo Funcin Cdigo 1 0 0 0 1 0 0 1 1 0 1 0 1 0 1 1 1 1 0 0 1 1 0 1 1 1 1 0 1 1 1 1 Respuesta: estado encendido Respuesta: estado apagado Solicitud de estado Funcin Solicitar respuesta Repuesta al comando anterior Seleccin de niveles predeterminados de intensidad 0 0 0 0 Apagar todas las unidades 0 0 0 1 Encencer todas las luces 0 0 1 0 Encender dispositivo 0 0 1 1 Apagar dispositivo 0 1 0 0 Reducir intensidad 0 1 0 1 Incrementar intensidad 0 1 1 0 0 1 1 1 Cdigo de extensin
Jose Alcal Correa
71
Kora
Lonworks
Todos los dispositivos LonWorks incluyen un chip llamado Neuron que contiene los circuitos necesarios para conectarlo a la red. Este chip incluye CPU, mdulo de E/S y memorias ROM y RAM. Asimismo, cada chip est unvocamente identificado por una cadena de 48 bits llamada Neuron ID, que tiene una funcionalidad similar a las MAC de los dispositivos que se conectan a redes Ethernet. El direccionamiento de dispositivos Lonworks puede hacerse utilizando directamente el Neuron ID (su direccin fsica), o mediante direcciones lgicas. Las direcciones lgicas se componen de campos de dominio, subred y nodo. Los dispositivos interactan entre s de forma descentralizada (extremo a extremo), y la inteligencia de la instalacin est distribuida en los propios dispositivos. El campo dominio puede existir o no y tener una longitud de entre 0 y 6 bits. Se usa para diferenciar redes distintas, y es interesante utilizarlo cuando dos redes utilizan un mismo canal de comunicacin. El campo subred es de 8 bits y permite direccionar hasta 255 subredes en cada red. El campo red es de 4 bits y permite que haya hasta 127 dispositivos en cada subred. LonWorks define tipos de variables estndar asociados a unidades. Hay cientos de tipos aunque los ms importantes son los tpicos: porcentajes, booleanos, enteros y flotantes (de distinto tamao), caracteres (en distintas codificaciones), etctera.
KNX
A diferencia de LonWorks, que requiere un chip especfico para cada dispositivo, KNX est diseado para ser independiente de la plataforma sobre la que se implemente. El tipo de conexin entre dispositivos y centralitas que con diferencia suele utilizarse es el cable trenzado, aunque tambin se permiten conexiones inalmbricas o a travs de la red elctrica. Los dispositivos pueden ser capaces de configurarse automticamente o tambin pueden necesitar instalacin y configuracin previa por parte de un especialista. El sistema KNX puede ser centralizado, donde todos los clculos se realizan en una centralita, o descentralizado, donde los dispositivos tienen circuitera extra programable. La comunicacin se realiza a travs del bus del sistema y los dispositivos inician las comunicaciones cuando se produce un evento. De esta forma, si un sensor es programable y detecta un suceso,
72
Kora
es capaz de enviar un telegrama al actuador adecuado de forma autnoma. Las direcciones en KNX se componen de tres campos: rea, lnea y dispositivo. Los dos primeros campos son de 4 bits y el tercero 8, lo que en teora permite direccionar 65536 dispositivos, aunque en realidad el mximo es de 57600. Las direcciones fsicas se indican separando los campos mediante puntos (.) o barras (/). La unidad de instalacin ms pequea es la lnea, que puede tener hasta 255 aparatos conectados (aunque depende de la potencia de la fuente de alimentacin). La primera posicin de la lnea est siempre ocupado por el repetidor de seal, que se encarga de repartir los telegramas dentro de la lnea. Una lnea no puede exceder los 1000 metros de bus, y debe configurarse sin crear ciclos. Los dispositivos en la lnea estn identificados por el tercer campo de la direccin. Cuando se necesitan varias lneas (ya sea por comodidad o por restricciones de la instalacin), KNX permite agruparlas en reas. Un rea puede contener hasta 15 lneas ms un acoplador de lneas. Las lneas se conectan entre s mediante un dispositivo llamado acoplador de lnea. El segundo campo de la direccin hace referencia al nmero de lnea. Si se necesitan varias reas (por ejemplo, para un edificio de varias plantas), KNX permite agruparlas todas en torno a la lnea principal del sistema. Se pueden agrupar hasta 15 reas, junto a un acoplador de rea. El primer dgito de la direccin es el que hace referencia al nmero de rea. Normalmente, el primer aparato de cada lnea o rea es el repetidor o amplificador de seal, as que las direcciones X/X/0 y X/0/0 estn reservadas para dichos dispositivos. Como puede comprobarse, KNX aporta una gran funcionalidad y flexibilidad para la configuracin de las redes domticas, pudiendo ser estas fcilmente escaladas y reconfiguradas. Los tipos de dato con los que trabaja KNX son:
Tipo bool 3_bits_controlled 8_bits_unsigned 2_bytes_unsigned 2_bytes_float 4_bytes_unsigned date Jose Alcal Correa Descripcin Valores binarios (1/0). Es el tipo ms usado Enteros entre 0 y 7 Enteros entre 0 y 255, valores porcentuales y ngulos. Enteros de 0 a 65535. Valores decimales de -671088,64 a +670760,96 Valores entre 0 y 4294967295. Da, mes y ao Proyecto Fin de Carrera. Septiembre de 2010
73
Kora
hour date_hour string
Software accesible para control de entorno mediante dispositivos mviles Hora, minuto y segundo Los dos anteriores combinados Cadena codificada en ASCII con hasta 14 caracteres.
Una de las caractersticas ms relevantes de KNX es el soporte para direcciones lgicas de grupo. Varios dispositivos pueden asociarse a un buzn de forma que si un sensor coloca un valor en dicho buzn, todos los actuadores suscritos a l tomarn el valor que se ha depositado. Esta caracterstica es muy til para crear grupos de sensores y actuadores. Por ejemplo, podran asociarse varios interruptores a la misma bombilla o varios sensores de humo al mismo sistema antiincendios, de una forma muy sencilla y adems escalable. Las direcciones de grupo se especifican mediante tres campos: grupo principal (4 bits), grupo intermedio (3 bits) y subgrupo (8 bits ). Los separadores pueden ser el punto (.) o la barra (/).
Jose Alcal Correa
74
Kora
2.2. CONCLUSIN
Por una parte tenemos varios estndares domticos que, aunque comparten filosofa de funcionamiento, son muy distintos entre s. Si queremos tener una capa de abstraccin que d soporte completo a todas sus caractersticas, el tamao y la complejidad de la misma seran muy grandes. Uno de los requisitos que se plantean es que el acceso a los dispositivos se haga de forma sencilla desde los dispositivos que van a acceder a la instalacin domtica. Adems, el mbito en el que va a utilizarse la aplicacin es el domstico o el escolar, y en ambos las instalaciones suelen ser pequeas. Con esta aplicacin no vamos a gestionar la configuracin ni el direccionamiento de los dispositivos domticos, sino que simplemente vamos a dar un acceso uniforme a entidades externas a la misma (dispositivos mviles). Por tanto, los atributos que necesitaramos para proveer un acceso sencillo y a la vez eficiente a los dispositivos de la instalacin seran entonces los siguientes: Nombre o identificador unvoco que represente al dispositivo en el sistema. Nombre legible para que el usuario pueda identificar ms fcilmente el dispositivo. Tipo de dispositivo, que tendr asociada una representacin determinada en el terminal de usuario. Ser necesario determinar un sistema estndar de tipos para los dispositivos ms comunes. Tipo de acceso al dispositivo: lectura, escritura o ambas. Tipo de valor que puede leerse o escribirse en el dispositivo. Rango de valores soportados por el dispositivo.
Con esta representacin evitamos que las aplicaciones tengan que tratar con valores de bajo nivel como direcciones fsicas o lgicas. Se facilita la asociacin entre tipo de dispositivo y representacin en el dispositivo del usuario y en general, se simplifica el protocolo, lo cual posibilita un mejor rendimiento de las comunicaciones.
Jose Alcal Correa
75
Kora
3. MODELO ESTTICO
3.1. DIAGRAMA
DE
CLASES
A continuacin se muestran los diagramas de clases para aplicacin cliente (en dispositivo mvil) y servidora (en PC conectado a red domtica). Ambos diagramas son completos y muestran las clases con sus atributos y operaciones, y las relaciones entre las mismas.
Jose Alcal Correa
76
Kora
Jose Alcal Correa
77
Kora
3.2. DESCRIPCIN
DE LAS
CLASES: ATRIBUTOS
OPERACIONES
Al igual que en el diagrama de clases, se omiten las operaciones triviales de cada clase, como los getters y los setters.
Aplicacin cliente
Clase Descripcin Atributos User Clase que representa un usuario que va a utilizar el sistema name Identificador y nombre del usuario. centre Centro al que pertenece el usuario photo Fotografa del usuario, que ayude a diferenciarlo en una lista. autoStart Indica si se iniciar la sesin para este usuario de forma automtica al arrancar la aplicacin. autoStartSeconds Segundos que transcurren entre el arranque de la aplicacin y el inicio automtico de la sesin para este usuario. Operaciones Para esta clase se muestran los atributos organizados por categoras, para que sea ms sencillo identificarlos. Clase Descripcin UseProfile Clase que representa un perfil de usuario. Los perfiles de usuario determinan cmo va a comportarse la aplicacin para el usuario que los tenga seleccionados. interactionMode Modo de interaccin con la aplicacin, que puede ser tctil directo o mediante barrido. Atributos Interaccin scanMillis Tiempo que pasa entre cambio automtico de opcin cuando est seleccionado el modo de barrido. paginationMode Inidca el modo de cambio de pgina en la aplicacin. Puede ser utilizando el ltimo botn de la rejilla o aadiendo botones en la parte inferior de la pantalla.
Jose Alcal Correa
78
Kora
viewMode Indica el modo de visualizacin de los elementos: color plano, colores alternados, alto contraste o blanco y negro. backgroundColor Indica el color del fondo de la aplicacin. rows Indica el nmero de filas de la rejilla en la que se muestran los dispositivos. columns Indica el nmero de columnas de la rejilla de dispositivos. margin Indica el margen entre los dispositivos de la rejilla. allowedOrientations Visuali- Indica las orientaciones de pantalla permitidas. zacin showText Indica si se mostrar o no texto typography Indica la tipografa a usar en caso de mostrar texto. textSize Indica el tamao del texto, si se muestra. textCaps Indica si el texto se pasar a maysculas en caso de ser mostrado. textColor Indica el color del texto, si se muestra iconMode Indica el modo de visualizacin de iconos: pictogramas, fotografas, alto contraste o blanco y negro. vibration Indica si se usar o no vibracin para responder a las acciones de usuario confirmation Realim Indica si se solicitar confirmacin mediante un endilogo ante una accin del usuario tacin confirmationMillis Indica el tiempo en milisegundos que la confirmacin estar disponible, si en ese tiempo no se pulsa, se cancela la accin
79
Kora
contentHighlight Indica si se resaltar el contenido del elemento seleccionado borderHighlight Indica si se resaltar seleccionado el borde del elemento
soundMode Indica el modo de sonido, que puede ser sin sonido, sonidos simples, voz sinttica o voz personalizada. soundOnSelection Sonido Reproducir un sonido dispositivo. cuando se selecciona un
soundOnAction Reproducir un sonido cuando se modifique el valor de un dispositivo. Operaciones
Jose Alcal Correa
80
Kora Clase Descripcin Atributos Operaciones Clase Descripcin
DeviceProfile Clase que representa los dispositivos que puede utilizar un usuario. Mode Indica el modo de permisos: permitir por defecto o denegar por defecto
Device Clase abstracta que representa un dispositivo presente en el sistema. systemName Identificador unvoco que lo identifica en el sistema. readableName Nombre legible para las personas. valueType Indica el tipo de datos con el que trabaja el dispositivo.
Atributos
currentValue Indica el valor actual del dispositivo. Este valor representa el estado del dispositivo. minValue Valor mnimo que puede tomar el dispositivo. maxValue Valor mximo que puede tomar el dispositivo.
Operaciones Clase Descripcin Atributos getValue() : Value Operaciones Devuelve el valor que representa el estado actual del dispositivo. ReadOnlyDevice Clase que especializa la clase abstracta Device y representa un dispositivo presente en el sistema cuyo estado solo puede consultarse.
Jose Alcal Correa
81
Kora
Clase Descripcin Atributos
ReadWriteDevice Clase que especializa la clase abstracta Device y que representa un dispositivo presente en el sistema cuyo estado puede consultarse y modificarse. getValue() : Value Devuelve el valor que representa el estado actual del dispositivo. setValue(value : Value) Establece un nuevo estado para el dispositivo mediante la asignacin de un nuevo valor. DeviceType Enumerado con los distintos tipos de dispositivo que soporta el sistema. DeviceRepresentation Clase que contiene los elementos multimedia y las descripciones que representan a un dispositivo. Name Nombre de la representacin.
Operaciones
Enumerado Descripcin Clase Descripcin Atributos Operaciones Clase Descripcin
State Clase que contiene la representacin multimedia para un estado concreto de un dispositivo. tag : String Texto que representa el estado.
Atributos
icon: Bitmap Icono que representa el estado de forma grfica. sound: Sound Sonido que representa el estado de forma audible.
Operaciones
Jose Alcal Correa
82
Kora
Clase Descripcin
Control Clase que representa un control de un dispositivo. Un dispositivo puede tener varios controles para alterar de distintas maneras su valor. name : String Nombre del control
Atributos
writable : boolean Indica si el control es de solo lectura o si tambin soporta que el usuario realice acciones sobre l.
Operaciones Clase Descripcin DeviceMap Coleccin que mantiene los dispositivos presentes en el sistema, indexados por su nombre de sistema. serverAddress : String Direccin IP del servidor domtico al que conectarse. port : String Puerto del servidor al que efectuar la conexin connect(address : String, port : String) Operacin para conectarse al servidor de domtica. Una vez efectuada la conexin se obtiene una lista de dispositivos del servidor, que no cambiar a lo largo del uso del usuario. Operaciones disconnect() Desconecta el dispositivo del servidor. getDevices() : Device [0..*] Devuelve una lista con todos los dispositivos presentes en el sistema. Clase Descripcin Event Clase que representa un evento de cambio en el valor de un dispositivo. Los eventos pueden transmitirse del servidor a los clientes, y de los clientes al servidor. value: Value Nuevo valor de evento para el dispositivo con el que est relacionado.
Atributos
Atributos Operaciones
Jose Alcal Correa
83
Kora
Aplicacin servidor
Clase Descripcin Device Clase abstracta que representa un dispositivo presente en el sistema. systemName Identificador unvoco que lo identifica en el sistema. readableName Nombre legible para las personas. valueType Indica el tipo de datos con el que trabaja el dispositivo. Atributos currentValue Indica el valor actual del dispositivo. Este valor representa el estado del dispositivo. minValue Valor mnimo que puede tomar el dispositivo. maxValue Valor mximo que puede tomar el dispositivo. init() Operacin abstracta de clase que las clases que especialicen a Operaciones esta deben implementar para establecer la conexin con sus respectivas centralitas. Clase Descripcin Atributos Operaciones Clase Descripcin Atributos Operaciones KNXDevice Clase que especializa la clase Device y representa un dispositivo KNX presente en el sistema. Los atributos de esta clase dependern de la especificacin del estndar KNX. Las operaciones de esta clase dependern de la especificacin del estndar KNX. LonworksDevice Clase que especializa la clase Device y representa un dispositivo Lonworks presente en el sistema. Los atributos de esta clase dependern de la especificacin del estndar Lonworks. Las operaciones de esta clase dependern de la especificacin del estndar Lonworks.
Jose Alcal Correa
84
Kora
Clase Descripcin Atributos Operaciones Enumerado Descripcin Enumerado Descripcin
X10Device Clase que especializa la clase Device y representa un dispositivo X10 presente en el sistema. Los atributos de esta clase dependern de la especificacin del estndar X10. Las operaciones de esta clase dependern de la especificacin del estndar X10. DeviceType Enumerado con los distintos tipos de dispositivo que soporta el sistema. AccessMode Enumerado que representa el tipo de acceso para un dispositivo presente en el sistema. Puede ser solo lectura, o lectura y escritura. DeviceMap Coleccin que mantiene los dispositivos presentes en el sistema, indexados por su nombre de sistema. Estos dispositivos pueden ser de cualquier tipo: KNX, X-10, Lonworks o ZigBee.
Clase Descripcin Atributos
getDevices() : Device [0..*] Operaciones Devuelve una lista con todos los dispositivos presentes en el sistema.
Jose Alcal Correa
85
Kora
3.3. DESCRIPCIN
Relacin Cardinalidad Tipo Descripcin Relacin Cardinalidad Tipo Descripcin Relacin Cardinalidad Tipo Descripcin Relacin Cardinalidad Tipo Descripcin
DE LAS
RELACIONES
owns (posee) User 1 UseProfile 1 Normal Establece la relacin entre un usuario y su perfil de usuario. owns (posee) User 1 DeviceProfile 1 Normal Establece la relacin entre un usuario y su perfil de dispositivos. controls (controla) User 1 Device 1..* Normal Establece la relacin entre el usuario que est utilizando la aplicacin y los dispositivos que controla. excepts (excepciones) DeviceProfile 0..1 Device 0..* Agregacin Indica las excepciones que habr en un perfil de dispositivo. Si el perfil tiene el modo por defecto permitir, las excepciones sern dispositivos a los que el usuario no podr acceder, y viceversa. is a (es un) Device * DeviceType 1 Normal Indica el tipo de dispositivo para un objeto Device dado. represented by (representado por) Device * DeviceRepresentation 1 Normal Establece la representacin para un Device dado.
Relacin Cardinalidad Tipo Descripcin Relacin Cardinalidad Tipo Descripcin
Jose Alcal Correa
86
Kora Relacin Cardinalidad Tipo Descripcin Relacin Cardinalidad Tipo Descripcin Relacin Cardinalidad Tipo Descripcin Relacin Cardinalidad Tipo Descripcin Relacin Cardinalidad Tipo Descripcin
contains (contiene) DeviceRepresentation 1 State 1..* Agregacin Establece el conjunto de representacin de dispositivo. contains (contiene) DeviceManager 1 Device * Agregacin Establece los dispositivos presentes en el sistema que estn registrados por el mapa de dispositivos. receives (recibe) DeviceManager 1 Event * Normal Indica que el gestor de dispostivos (DeviceManager) puede recibir eventos. sends (enva) DeviceManager 1 Event * Normal Indica que el gestor de dispostivos (DeviceManager) puede enviar eventos. related to (relativo a) Event 1 Device 1 Normal Establece la relacin entre un evento y el dispositivo al que afecta. estados que tiene una
Jose Alcal Correa
87
Kora
CAPTULO V: DISEO
Jose Alcal Correa
88
Kora
1. OBJETIVOS
DEL
DISEO
En este primer apartado del diseo definiremos las cualidades que la aplicacin debe tener, basndonos en los requisitos no funcionales que se especificaron en el tercer captulo. Hasta este momento hemos visto que el sistema que se quiere crear est dividido en dos partes claramente diferenciadas pero que comparten varias cualidades y que estn muy relacionadas entre s: la aplicacin cliente que se ejecuta en los dispositivos mviles de los usuarios y la aplicacin servidora que se ejecuta en un ordenador conectado a los dispositivos domticos que se pretenden controlar. Estas aplicaciones presentan requisitos no funcionales que pueden llegar a ser muy distintos. Por una parte, la aplicacin cliente debe satisfacer principalmente requisitos de accesibilidad, usabilidad y rendimiento. Esta aplicacin est tambin dividida en dos partes diferenciadas: las actividades de gestin y configuracin controladas por el tutor, y la actividad de manejo de dispositivos, controlada por el usuario final. Ambas actividades deben satisfacer varios requisitos de usabilidad pues los usuarios a los que estn dirigidas no tendrn apenas experiencia con el entorno en el que se enmarca la aplicacin. Adems, la actividad de control de dispositivos deber satisfacer una gran cantidad de requisitos de accesibilidad, pues los usuarios a los que est dirigida presentarn algn tipo de problema fsico o cognitivo, y es posible que utilicen mtodos de interaccin no estndar. En resumen, los objetivos del diseo de la aplicacin cliente son: Proporcionar una interfaz de usuario para el control de dispositivos lo ms sencilla posible, y completamente configurable para usuarios que pueden presentar una gran variedad de necesidades de interaccin especiales. Esta interfaz ser capaz de adaptar su aspecto y comportamiento en funcin de las necesidades del usuario. Crear una aplicacin rpida, que ofrezca al usuario una respuesta inmediata para evitar frustraciones. Este punto es especialmente importante para colectivos de personas con problemas psquicos. Crear una herramienta integrada en la aplicacin, para el tutor o persona responsable del usuario. Esta herramienta permitir configurar los usuarios que usarn el sistema y sus preferencias o personalizaciones asociadas. Esta herramienta deber estar pensada para personas con poca experiencia en el uso de
Jose Alcal Correa
89
Kora
herramientas informticas. Proporcionar un sistema sencillo de creacin de plantillas con representaciones multimedia para dispositivos domticos. Permitir que las configuraciones para los usuarios puedan intercambiarse de forma sencilla entre varios dispositivos mviles.
La aplicacin del servidor, por otra parte, tiene dos objetivos principales: abstraer los dispositivos domticos de distintos fabricantes y estndares a las aplicaciones cliente, y gestionar los eventos que se produzcan en el sistema. La abstraccin de los dispositivos domticos es necesaria por varias razones, como permitir que se desarrollen nuevas aplicaciones cliente que utilicen el mismo protocolo, liberar de una gran carga de procesamiento a los dispositivos mviles (que es importante para la fluidez de la aplicacin y el consumo de batera), o proporcionar un mecanismo estndar para implementar nuevos estndares domticos en el sistema. La funcionalidad de esta capa de abstraccin estar limitada a la lectura y escritura de datos en los dispositivos, y obtener un listado con los dispositivos conectados al sistema. No se proveern mtodos para conectarse o desconectarse a dispositivos concretos, aadirlos o quitarlos, pues aunque sean funcionalidades muy interesantes, esto requerira un proyecto aparte y se escapa al mbito de esta aplicacin. El segundo objetivo de la aplicacin del servidor es actuar como el sitio centralizado al que se conectan los clientes, y ser el despachador de eventos que se produzcan en el sistema. Los clientes mandarn al servidor eventos con cambios deseados en los dispositivos, y el servidor se encargar de difundir eventos de cambio de estado cuando un dispositivo cambie su estado. De esta forma, varios clientes podrn estar utilizando el sistema de forma simultnea. En resumen, los objetivos de diseo del servidor son: Proporcionar a los clientes un protocolo sencillo, eficiente y seguro para interactuar con una instalacin domtica (red de sensores y actuadores). Facilitar la integracin de varios estndares domticos que abstraigan a las aplicaciones cliente de las tecnologas domticas subyacentes. Que la integracin de varias tecnologas no suponga incrementos en el tiempo de acceso o respuesta. Proporcionar un marco comn para integrar nuevos estndares
Jose Alcal Correa
90
Kora
domticos en el sistema. Que el tamao de una instalacin no influya en el rendimiento de la aplicacin. No depender del hardware sobre el que se implemente: que pueda ejecutarse sobre un ordenador de escritorio con cualquier SO o incluso que pueda instalarse en un sistema empotrado.
Jose Alcal Correa
91
Kora
1. ARQUITECTURA
DEL
SISTEMA
A raz de lo descrito en el modelado de requisitos y el deiseo, puede deducirse que la arquitectura ms conveniente para el sistema es la clienteservidor.
Este tipo de arquitectura es tpica en sistema distribuidos (como pueden serlo las instalaciones domticas con sus sensores, actuadores y centralitas), en los que los datos y el procesamiento se distribuye en mdulos independientes pero interconectados. Los componentes de dicha arquitectura son: Servidores que ofrecen servicios a otros sistemas. Estos servidores, por lo general, no conocen a los sistemas que solicitan sus servicios. Un ejemplo tpico de este tipo de sistemas son los servidores web, que sirven una gran cantidad de datos a un cojunto de clientes muy variado (pueden ser navegadores de escritorio, clientes FTP, bots de buscadores, etctera). Clientes que utilizan los servicios ofrececidos por los servidores. Estas solicitudes e invocaciones pueden llegar a ejecutarse masivamente y de forma concurrente. Los clientes s tienen la responsabilidad de saber qu servidores ofrecen qu contenidos y
Jose Alcal Correa
92
Kora
cmo tienen que invocar a sus servicios. Por ejemplo, cuando usamos un navegador web tenemos que saber qu pgina queremos visitar. Una red de interconexin que permite a los clientes acceder a los servicios.
En el caso de Kora, el servidor tendr por una parte los dispositivos mviles que se comuniquen con l para interactuar con los dispositivos, y por otra, la red de dispositivos domticos. Es decir, el servidor har de puente entre dos redes distintas. La primera red ser la compuesta por los dispositivos mviles con los que los usuarios controlan el sistema. Estos dispositivos se conectan directamente con el servidor a travs de una red inalmbrica, siguiendo cualquiera de los protocolos estndar que soporten tanto el servidor como los propios dispositivos mviles: WiFi o Bluetooth. La informacin que se transporta por esta red es de dos clases: Peticin por parte de los dispositivos mviles del listado de dispositivos domticos al servidor, y respuesta correspondiente. Eventos de cambio de estado en un dispositivo domtico. Pueden ser de dos tipos: Si un evento va de un cliente al servidor, indica que el usuario que maneja dicho dispositivo domtico quiere cambiar el valor que representa el estado del mismo. Si un evento va desde el servidor al todos los clientes, indica que se ha producido un cambio en el estado de un dispositivo. Si este cambio de estado ha sido provocado por un cliente, la recepcin de este evento es la confirmacin de que ha cambiado el estado del dispositivo. La segunda red es la que conecta el servidor con los dispositivos domticos. Para modificar efectivamente o leer el estado de un dispositivo, el servidor debe mandar una trama con un formato especfico (segn el estndar domtico) a la centralita correspondient, si la red es centralizada. Si la red domtica es descentralizada, el servidor estar conectado directamente a los dispositivos de dicha red (por ejemplo, si es una red ZigBee, el servidor deber tener un emisor/receptor compatible).
Jose Alcal Correa
93
Kora
Diagrama con la arquitectura simplificada
Jose Alcal Correa
94
Kora
2. DESCOMPOSICIN
EN
SUBSISTEMAS
Debido a la naturaleza cliente-servidor del sistema a desarrollar, es importante realizar un diseo que consiga una alta cohesin y un bajo acoplamiento. Estas dos cualidades nos permiten reducir la complejidad de los subsistemas y por tanto, del sistema en general. Esta reduccin de complejidad es beneficiosa para el mantenimiento del sistema, su comprensin y su rendimiento. Habiendo comprendido cules son las vistas del sistema en el anlisis de requisitos y la arquitectura que tendr en el apartado anterior, podra dividirse en tres: Subsistema de gestin de dispositivos. Subsistema de control de dispositivos por parte del usuario. Subsistema de gestin de usuarios y perfiles.
El subsistema de gestin de dispositivos se encontrar en el servidor de domtica de la aplicacin y se encargar de recibir peticiones de los clientes y responderlas. Estas peticiones pueden ser la consulta de la lista de dispositivos, la consulta de estado de uno de ellos o la modificacin de algn valor de un dispositivo. Por otra parte, es posible que los dispositivos generen eventos (por ejemplo, se encienda una luz manualmente) y se necesite notificar a los dispositivos mviles de los usuarios. El subsistema de control de dispositivos presenta al usuario una interfaz de control adaptada a sus necesidades. Entre las responsabilidades de este subsistema se encuentran configurar el aspecto de la interfaz de usuario, la forma de interactuar con el sistema, o la realimentacin que se ofrecer ante las acciones del usuario. Por tanto, consideramos que este subsistema se encarga de modificar la capa de usuario. El subsistema de gestin de usuarios y perfiles consistir en una aplicacin de configuracin para los perfiles que configuran el aspecto y el comportamiento del subsistema anterior. A la vista de los dos primeros subsistemas, es evidente que la mayora del flujo de informacin del sistema estar determinado por los eventos que se produzcan en el mismo, ya sea por parte de los usuarios o por parte de los dispositivos. Por tanto, tanto el subsistema de gestin de dispositivos del servidor como el subsistema de control de dispositivos de los clientes deben contar con sendos subsistemas manejadores de eventos, adems de los propios de cada uno.
Jose Alcal Correa
95
Kora
Jose Alcal Correa
96
Kora
4. DISEO
DE LA
INTERFAZ
DE
USUARIO
La implementacin accesible de una interfaz de usuario completamente accesible y configurable es uno de los pilares bsicos de este proyecto. Es importante definir el modelo de interaccin de la aplicacin, as como los elementos que compondrn la interfaz de usuario y la disposicin de los mismos en pantalla. El primer paso para disear la interfaz de usuario es definir cmo se realizar la interaccin de los usuarios con el sistema. Teniendo el colectivo al que est dirigida la aplicacin, este modelo debe ser lo ms sencillo y claro posible, sin ofrecer ms informacin de la estrictamente necesaria. El modelo que proponemos es el siguiente: se diferencian dos actividades distintas en el control de dispositivos. En la primera actividad se muestra un listado de dispositivos presentes en el sistema y el estado actual de los mismos. Los dispositivos se mostrarn en una rejilla o una lista, segn especifique el perfil de uso del usuario. Para cada dispositivo se mostrar un botn que tendr la apariencia elegida en el perfil de uso del usuario, y al pulsar sobre l se activarn las acciones de realimentacin que tambin se especifican en el perfil de uso.
Boceto de la actividad de listado de dispositivos
Jose Alcal Correa
97
Kora
En el caso de que no entren todos los dispositivos en una sola pantalla, se proveern dos formas de cambiar de pgina: mediante controles especficos en la parte inferior o mediante un botn que se integre con el resto de botones de dispositivos. Esta ltima opcin es especialmente interesante para usuarios con ciertas patologas cognitivas.
Modelos de paginacin alternativos La segunda actividad es la de consulta y control del dispositivo y se inicia cuando se ha elegido un dispositivo en la rejilla de la primera actividad. Tiene el propsito de mostrar informacin ms detallada sobre el estado del dispositivo y dar la posibilidad de interactuar con l en el caso de que el dispositivo lo permita. En esta actividad se muestran el estado actual del dispositivo y los controles que permitan modificar su valor. Tambin se mostrar un botn para volver a la actividad de listado de dispositivos. Los controles que se muestren en ambas actividades sern del mismo tipo para mantener la coherencia de la interfaz de usuario. Los dispositivos que sean de solo lectura mostrarn su estado segn las representaciones de dispositivo asociadas, y no permitirn ningn otro tipo de interaccin. Para los dispositivos que permiten alterar su valor se distinguen dos tipos de interacciones: Interaccin binaria: activar o desactivar un dispositivo. Por ejemplo, encender y apagar una luz, o abrir y cerrar una puerta.
Jose Alcal Correa
98
Kora
Interaccin escalar: elegir un valor para un dispositivo dentro de un rango. Por ejemplo, subir y bajar una persiana, cambiar la temperatura de un radiador.
Ejemplo de interaccin binaria Ambos tipos de interacciones se consideran bsicos y pueden realizarse de varias formas posibles. La interaccin binaria la representaremos como la activacin o desactivacin de un botn en la interfaz de usuario. La interaccin escalar puede representarse como un deslizador (para usuarios que puedan realizar tal accin) o como un par de botones de incremento y decremento de valor.
Jose Alcal Correa
99
Kora
Ejemplo de interaccin escalar con ambos tipos de representacin
Jose Alcal Correa
100
Kora
5. DISEO
DE
OBJETOS
DE
5.1. SUBSISTEMA
DISPOSITIVOS
En este apartado se detallar cmo se ha realizado la abstraccin sobre los dispositivos domticos que se van a conectar al servidor. En primera instancia, lo que hay que determinar es qu atributos tendrn nuestros dispositivos virtuales (abstracciones sobre dispositivos reales) y qu operaciones soportarn. El objetivo de esta abstraccin sobre dispositivos domticos reales no es el de crear una biblioteca que ofrezca acceso de alto nivel a todas las operaciones que soporten los distintos sistemas domticos. Este propsito requerira un proyecto aparte completo y habra que dedicarle varios meses extra de trabajo. Nuestro objetivo es simplemente ofrecer una capa de abstraccin lo ms sencilla posible que permita un acceso transparente a las caractersticas y operaciones tpicas de todos los estndares domticos: listar dispositivos, obtener su estado y modificar su estado si lo permiten. El mecanismo indicado para abstraer los dispositivos de los distintos estndares y unificar el acceso a los mismos, utilizando un diseo orientado a objetos, es la herencia y el polimorfismo. Se propone una clase abstracta Device que las clases que representen dispositivos KNX, ZigBee, Lonworks o X-10 deben especializar. Estos objetos se corresponden con dispositivos con un solo control o valor del sistema domtico. Para ciertos estndares (como KNX) puede ser conveniente o necesario implementar clases auxiliares como gestores de conexin o mapeadores de eventos. Esta labor se deja a eleccin del programador de la implementacin correspondiente.
Jose Alcal Correa
101
Kora
Diagrama de clases. Dispositivos. Con este diseo se consigue abstraer los subsistemas domticos subyacentes, de forma que la aplicacin cliente no es consciente en ningn momento de cmo est montado el sistema domtico. Tan solo ve dispositivos con nombre identificativos cuyos distintos valores pueden leerse o escribirse dentro de un rango y con un tipo determinado.
Jose Alcal Correa
102
Kora
5.2. SUBSISTEMA
DE
EVENTOS
En este apartado se definir cundo se dispararn los eventos y se difundir su contenido, y qu informacin contendrn. Desde el punto de vista del servidor, los eventos pueden provenir desde dos fuentes distintas, y tienen efecto en el lado contrario. Todos los eventos contienen la misma informacin: el nuevo valor que representa cambio de estado en un dispositivo domtico. Estos eventos se pueden generar desde los terminales mviles de los usuarios, al querer modificar el valor que representa el estado de un dispositivo domtico, por ejemplo, mandar la orden de encender una bombilla. Tambin pueden producirse dentro de la misma instalacin domtica sin ser los usuarios de la aplicacin quienes lo han provocado mediante sus dispositivos mviles. Por ejemplo, alguien enciende la bombilla con un interruptor manual, o un sensor detecta un movimiento. En ambos casos es necesario notificar del evento a todos los dispositivos mviles de los usuarios que estn conectados al servidor. Los atributos y operaciones de los eventos de cambio de estado que se definen son las siguientes. Como son tan sencillos y las operaciones son bsicas, no es necesario definir sus contratos correspondientes. Clase Evento Atributos de DeviceChangeEvent - deviceName : String Nombre de sistema del dispositivo que ha generado el evento. - value : Value Nuevo valor que representa el estado del dispositivo domtico que ha generado el evento.
Operaciones +DeviceChangeEvent(String deviceName, Value newValue) Constructor del evento. +getDeviceName() : String Devuelve el nombre del dispositivo que ha generado el evento. +getDeviceValue() : Value Devuelve el nuevo valor que tiene asignado el dispositivo. Comentarios Estos eventos pueden dispararse en dos direcciones. Un cliente puede mandar un evento al servidor para modificar el valor de un dispositivo. Asimismo, el servidor genera eventos y los manda a todos los clientes conectados para indicarles que se
103
Kora
ha producido un cambio en un dispositivo domtico, ya sea generado por un usuario o por una entidad externa al sistema.
Jose Alcal Correa
104
Kora
Clase de Evento DeviceChangeEvent Atributos - deviceName : String Nombre de sistema del dispositivo que ha generado el evento. - value : Value Nuevo valor que representa el estado del dispositivo domtico que ha generado el evento. +DeviceChangeEvent(String deviceName, Value newValue ) Constructor del evento. +getDeviceName() : String Devuelve el nombre del dispositivo que ha generado el evento. +getDeviceValue() : Value Devuelve el nuevo valor que tiene asignado el dispositivo. Comentarios Estos eventos pueden dispararse en dos direcciones. Un cliente puede mandar un evento al servidor para modificar el valor de un dispositivo. Asimismo, el servidor genera eventos y los manda a todos los clientes conectados para indicarles que se ha producido un cambio en un dispositivo domtico, ya sea generado por un usuario o por una entidad externa al sistema.
Operaciones
Jose Alcal Correa
105
Kora
CAPTULO VI:
IMPLEMENTACIN
Jose Alcal Correa
106
Kora
1. RECURSOS EMPLEADOS
1.1. RECURSOS SOFTWARE
Plataforma de desarrollo: Eclipse IDE 3.5 (Galileo) y 3.6 (Helios) Eclipse es un entorno de desarrollo multiplataforma basado en Java y con una arquitectura extensible mediante plugins. Es el IDE oficial del proyecto Android y soporta la edicin de ficheros de Java, XML e incluso de recursos como imgenes y sonidos. Incluye autocompletado de cdigo, documentacin en lnea y otras caractersticas que facilitan bastante la labor de programacin. El plugin autoconfigurarse automticamente permite controlar para Android permite al entorno de desarrollo cada vez que se arranca, de forma que se detectan los dispositivos Android conectados al ordenador, se emuladores, visualizar los logs del programa, etctera.
La gran versatilidad de este entorno de desarrollo permitira crear un editor de perfiles para Kora, la pgina web para el proyecto e incluso la documentacin para el mismo (mediante el plugin de LaTeX). Lenguaje de programacin: Java Es el lenguaje de programacin oficial para desarrollar aplicaciones para Android (aparte de C y C++, soportados por el Native Development Toolkit o Android NDK). Es un lenguaje orientado a objetos desarrollado por Sun Microsystems en los aos 90. Este lenguaje tiene una sintaxis similar a la de C o C++, pero incluye caractersticas de ms alto nivel. Se suele compilar a bytecode que se ejecuta en una mquina virtual (Android no usa la JVM estndar, sino una propia llamada Dalvik). La caracterstica ms valorada del lenguaje es su amplio uso y la disponibilidad de una gran cantidad de bibliotecas muy probadas. Desde 2007, la mayor parte de las tecnologas del lenguaje son software libre y estn publicadas bajo licencia GNU GPL.
Jose Alcal Correa
107
Kora
Software de gestin de instalaciones KNX: ETS 3 Este software propiedad de la Asociacin KNX permite configurar una instalacin domtica conectando un ordenador a la interfaz Ethernet o USB del router de la instalacin. Con l se pueden configurar el agrupamiento de los dispositivos, las direcciones a utilizar y las reacciones de los actuadores ante los eventos que disparen los sensores. Incluye una base de datos con todos los dispositivos de los fabricantes de componentes que siguen el estndar KNX.
Jose Alcal Correa
108
Kora
1.2. RECURSOS HARDWARE

Ordenador de sobremesa: Microprocesador Intel Core 2 Duo (2'13GHz), 4GB de RAM DDR2 a 667MHz, con ArchLinux [Arch] como Sistema Operativo principal. Ordenador porttil: Microprocesador Intel Celeron a 2GHz, 2GB de RAM DDR2 a 667 MHz, con ArchLinux como SO principal y Windows 7 como secundario. Telfono mvil HTC Tattoo: propiedad de la Universidad de Granada, con Android 1.6. Telfono mvil HTC Desire: con Android 2.2. Panel entrenador con dispositivos KNX: con un router Ethernet, otro USB, una fuente de alimentacin, tres bombillas, varios interruptores, sensor de presencia de 180 y de 360, y sensor de humedad.
Jose Alcal Correa
109
Kora
1.3. OTROS RECURSOS

HERRAMIENTAS
Iconos del proyecto Oxygen, utilizados principalmente en la interfaz del tutor [Oxygen]. Inkscape, herramienta de dibujo vectorial utilizada para crear los iconos y las representaciones de dispositivo [Inkscape]. Gimp, herramienta de dibujo y retoque fotogrfico utilizada para retocar los iconos y representaciones de dispositivo. KDE, entorno de escritorio multiplataforma que adems de una gran comodidad y una esttica agradable, provee herramientas como Dolphin (gestor de archivos), Kwrite y Kate (editores de texto), Yakuake y Konsole (terminales virtuales) o KDESvn (gestin de versiones).
Jose Alcal Correa
110
Kora
2. DESCRIPCIN
2.1. ANDROID
DEL
ENTORNO
DE
DESARROLLO
Como ya se describi en el captulo de investigacin, Android es un Sistema Operativo y entorno de desarrollo para dispositivos mviles desarrollado por la Open Handset Alliance, un consorcio de empresas en el que destacan Google, T-Mobile, Motorola, HTC o Sony Ericsson. Est basado en el kernel Linux y las aplicaciones de usuario se ejecutan sobre una mquina virtual optimizada para dispositivos mviles llamada Dalvik. Las aplicaciones de usuario se programan mediante el SDK de Android y el lenguaje Java aunque pueden enlazarse partes escritas en C mediante el NDK (Native Development Kit). Todo el cdigo fuente de la plataforma est disponible bajo licencias de software libre y cdigo abierto, destacando la licencia GNU GPL versin 2 y la licencia Apache. Los diferentes fabricantes de dispositivos suelen incluir aplicaciones propietarias y los drivers de los componentes de los dispositivos mviles tambin suelen serlo. La plataforma soporta diversas tecnologas como el motor de renderizado de pginas web WebKit (creado por Apple a partir del motor KHTML, tambin libre), OpenGL ES, bases de datos SQLite, cdecs para mltiples formatos de audio y vdeo, telefona (para dispositivos que lo soporten), soluciones de conectividad como Bluetooth, Wifi o 3G y recientes mtodos de interaccin como brjula o acelermetro. Aunque no es requisito obligatorio, todos los dispositivos Android cuentan con pantalla tctil. Todas estas caractersticas, junto con las que ofrece el lenguaje de programacin Java mediante su biblioteca estndar de clases, dan una gran potencia y versatilidad a la plataforma, que pueden aprovecharse para construir aplicaciones con un potencial equivalente a las aplicaciones para sistemas de escritorio. Las aplicaciones que utilicen el NDK tambin podrn beneficiarse de las bibliotecas estndar de C y C++, junto con las que desee aadir el programador (siempre y cuando estn compiladas para microprocesadores ARM). El SDK de Android contiene una serie de herramientas para conectar el ordenador a los dispositivos mviles mediante un cable USB, un depurador, una utilidad para firmar paquetes de aplicaciones, una terminal para conectarse al mvil de forma remota y un plugin para el su entorno oficial de
111
Kora
desarrollo Eclipse. Este entorno de desarrollo ser el utilizado para desarrollar el proyecto. El plugin para Eclipse incluye un editor de interfaces, un generador de cdigo para las clases auxiliares, un conversor de ficheros JAR (generados por el compilador de Java) a los que utiliza la mquina virtual de Android y un visor de Logs, adems de la documentacin en lnea integrada. Tambin se incluyen mquinas virtuales para probar las aplicaciones en dispositios mviles virtualizados. Se dispone de un telfono mvil HTC Tattoo con Android 1.6 Cupcake (propiedad de la Universidad) para hacer las pruebas pertinentes.
2.2. ESTNDAR KNX: ETS 3, CALIMERO

En el captulo de investigacin tambin se concretaron las razones por las que se va a utilizar el estndar KNX para hacer una primera implementacin del sistema. En el captulo de anlisis, adems, se dio una descripcin detallada del direccionamiento de los dispositivos del sistema y los tipos de dato que soportan. La mayora de instalaciones KNX dispone de un enrutador IP al que se puede conectar un PC mediante un cable de red Ethernet, o bien un enrutador al que puede conectarse un PC mediante un cable USB. La programacin y organizacin de la instalacin se hace utilizando el software oficial de la KNX Association, ETS. La ltima versin de este programa es la 3, y es la que vamos a utilizar para nuestro proyecto. La KNX Association tambin proporciona una biblioteca llamada Falcon para que los desarrolladores creen aplicaciones que se comuniquen con las instalaciones KNX. No obstante, est disponible solo para Windows, es muy compleja de usar (se necesitan cerca de 200 lneas de cdigo para leer un valor de un sensor) y adems es muy cara (10000 la licencia ilimitada) [Falcon]. La Universidad de Viena cre una biblioteca llamada Calimero que se comunica con la centralita de la instalacin mediante tunelado sobre IP, es decir, que solo soporta la conexin a travs de cable Ethernet. Esta biblioteca est desarrollada para Java y tiene prcticamente la misma funcionalidad de Falcon. Adems, es ms sencilla de utilizar, es multiplataforma y es libre, as que puede utilizarse sin pagar regalas a ninguna entidad. En 2005 se presentaron la biblioteca y un Live CD de Linux con
112
Kora
aplicaciones de demostracin que mostraban la funcionalidad de la biblioteca. Desde 2008 se encuentra en su revisin 2.0 alpha 4, lo cual parece indicar que ha sido abandonada. A pesar de esto, presenta una gran estabilidad y es usada por distintos proyectos como OpenRemote, que s tienen un desarrollo continuado y subsanan errores que pueda presentar la biblioteca. En la seccin de integracin con Calimero profundamente la conexin con la centralita KNX. se detallar ms
2.3. JAVA. BIBLIOTECA GRFICA SWING

Como Android y Calimero utilizan el lenguaje de programacin Java, ser el elegido para implementar todas las aplicaciones del sistema. Para probar la conectividad entre los dispositivos mviles y el ordenador de escritorio, se desarrollar una pequea aplicacin que simule un entorno domtico. Esta aplicacin incluir una lista de dispositivos simulados (como luces, puertas o ventanas) con los que se interactuar desde la aplicacin para dispositivo mvil. Para implementar esta aplicacin se utilizar Java junto con la biblioteca para creacin de interfaces grficas Swing, que es multiplataforma y puede ejecutarse sobre cualquier sistema operativo de PC.
Jose Alcal Correa
113
Kora
3. INTERFAZ
DE
USUARIO
La interfaz de usuario ha sido uno de los puntos ms importantes del desarrollo. Desde que empec a experimentar con el SDK de Android tuve claro que los componentes (widgets) estndar que provee la plataforma no serviran para implementar la funcionalidad que exigen nuestros requisitos de personalizacin y accesibilidad. Todos los elementos grficos en Android pertenecen a clases que heredan de View, una clase abstracta que contiene toda la funcionalidad bsica que necesita una vista. Sobreescribiendo mtodos como onDraw(), onTouchEvent() u onFocusTouchEvent() es posible crear componentes grficos personalizados. En el captulo de diseo se especificaron dos tipos de componente grfico que la aplicacin iba a utilizar: un botn y un deslizador. Ambos componentes, aunque tengan funcionalidades distintas, comparten las mismas opciones de personalizacin. A continuacin se incluye un diagrama que muestra de forma simplificada cmo se han implementado estas vistas.
Jose Alcal Correa
114
Kora
La clase KoraView contiene todos los atributos necesarios para la implementacin de las personalizaciones que indica el perfil de usuario activo. El contenido y la funcionalidad del botn vendrn dadas segn si est asociado a un dispositivo de la lista o a un control de un dispositivo.
Jose Alcal Correa
115
Kora
4. COMUNICACIN
CON EL
SERVIDOR
La comunicacin de los dispositivos mviles con el servidor se ha realizado utilizando la funcionalidad que proporciona el middleware BlueRose. Se distinguen dos tipos de comunicaciones con el servidor que se detallan a continuacin.
Peticin de la lista de dispositivos presentes en el sistema

Cuando se inicia la actividad de control de dispositivos, la aplicacin cliente solicita al servidor una lista con todos los dispositivos. Este responde con una lista en la que cada elemento detalla el identificador de sistema del dispositivo, su nombre, los valores que admite y el tipo de dispositivo que es. La ejecucin de dicha consulta se realiza de manera sncrona utilizando la caracterstica de ejcucin remota de mtodos (RPC) que provee BlueRose.
Jose Alcal Correa
116
Kora
Eventos de cambio de valor entre clientes y servidor

Tambin al inicio de la actividad de control de dispositivos, la aplicacin cliente se registra como suscriptora de los contenidos de la aplicacin servidor. Esta funcionalidad se implementa mediante el mecanismo de publicacin-suscripcin (PubSub) que provee BlueRose. La implementacin en el lado del cliente de este sistema se hace mediante escuchadores de eventos o Listeners. Cuando un cliente se suscribe a los eventos que pueda generar el servidor, tiene que iniciar los escuchadores asociados a cada tipo de evento. De esta forma, se permite que el servidor pueda emitir distintos tipos de eventos y el cliente solo responda ante aquellos que son de un tipo determinado. En el inicio de la actividad, adems de registrarse como aplicacin suscriptora, se inician tambin los escuchadores para los tipos de eventos del servidor que van a escucharse. En nuestro caso solo ser necesario escuchar eventos que incluyan informacin sobre un cambio de estado en un dispositivo de la informacin domtica. La respuesta ante los eventos de cambio de estado consiste en cambiar la representacin interna del dispositivo asociado, de forma que se pueda cambiar la representacin de estado que se ofrece al usuario y este sea consciente del cambio que se ha producido en su contexto. La aplicacin cliente tambin se registra como emisora de eventos con respecto al servidor. De esta forma, cuando el usuario modifica el estado de un dispositivo desde la actividad de control, se lanza un evento con el nuevo valor para el dispositivo elegido. El servidor recoge este evento y se encarga de modificar internamente el valor del dispositivo domtico al que el evento hace referencia.
Jose Alcal Correa
117
Kora
5. INTEGRACIN
CON
KNX
ESTNDAR KNX
5.1. FUNCIONAMIENTO
DEL
En el captulo de anlisis se hizo una comparativa de los mtodos de direccionamiento de los sistemas domticos ms importantes. Tambin se compararon los distintos tipos de dato que utiliza cada uno. En este apartado vamos a complementar la informacin de direccionamiento y tipos de datos de KNX con detalles internos a su funcionamiento. KNX soporta tres medios de transmisin distintos: a travs de cable bus, a travs de la lnea elctrica (como X-10) o a travs de radiofrecuencia. Analizaremos el primer caso, pues es con diferencia el ms utilizado. El sistema KNX es un sistema de bus distribuido, lo que significa que no es necesario un aparato de control centralizado (aunque esto no significa que no pueda existir). Cada componente tiene un microcontrolador de comunicaciones, y los componentes estn unidos entre s mediante el bus. Esta arquitectura permite que todos los componentes puedan ser controlados y monitorizados mediante el bus, que adems les proporciona la alimentacin necesaria. La lectura y escritura de valores en los dispositivos estn controladas por eventos. Cuando un sensor detecta un cambio en su entorno (por ejemplo, un cambio de humedad, la deteccin de una presencia, el accionado de un interruptor), crear un telegrama con un receptor concreto y lo depositar en el bus al que estn conectados todos los dispositivos. El bus suele ser un cable trenzado con cuatro hilos en el que los datos se transmiten en serie. Cuando el receptor recoge el telegrama, enva un acuse de recibo al emisor. De esta forma se aseguran las transmisiones correctas en el sistema. La traduccin de los tipos de dato de KNX a los que vamos a usar en la biblioteca se describir en el siguiente apartado, pues dicha traduccin depende de la implementacin concreta de la biblioteca a utilizar.
Jose Alcal Correa
118
Kora
5.2. UTILIZACIN
DE
CALIMERO
Calimero es una biblioteca libre para Java que permite comunicarse con una instalacin KNX/EIB mediante redes IP. Es necesario que el sistema domtico con el que se pretende conectarse tenga un router que reciba los paquetes IP y reenve la informacin a los dispositivos mediante el protocolo propio de KNX. Los eventos que se produzcan en el sistema sern empaquetados en paquetes IP y se enviarn al ordenador conectado a la instalacin. En la imagen de la derecha puede verse cmo es un router KNXnetIP. Esta biblioteca permite crear aplicaciones de alto nivel que accedan a una instalacin domtica, ya sean de escritorio o remotas. Junto con la biblioteca se incluyen aplicaciones de ejemplo para probar su funcionalidad. Los creadores del proyecto tambin proporcionan un Live CD [KNXLive] con Linux para probar la biblioteca sin necesidad de descargar el cdigo fuente ni configurar el entorno de desarrollo. La biblioteca est en estado 2.0 Alpha 4 desde noviembre de 2008, lo que da a entender que podra estar abandonada. No obstante, junto con la biblioteca se incluye una gran cantidad de pruebas para el cdigo y hay varios proyectos activos como OpenRemote que siguen contribuyendo al desarrollo de la misma, as que solo se puede considerar abandonada por sus creadores originales, la Universidad de Viena. Esta biblioteca incluye una gran cantidad de mtodos para hacer prcticamente cualquier cosa con la instalacin domtica, y necesita bastante estudio y preparacin para poderse usar a alto nivel. A pesar de su elevada funcionalidad, para funcionar solo necesita el entorno de ejecucin J2ME, una versin reducida de la mquina virtual de Java que est diseada para funcionar en dispositivos con poca memoria o capacidad de proceso. La biblioteca incluye tambin herramientas para descubir dispositivos en la instalacin domtica, para comunicaciones bsicas, un monitor de red o un configurador automtico de la conexin con el router KNXnet/IP. Calimero usa un mecanismo llamado PDU translators para traducir entre tipos Java y tipos de dato especficos de KNX, que se vieron en el captulo de
119
Kora
anlisis. Los tipos de dato que vamos a definir para trabajar con los sistemas domticos que se conecten al sistema sern los bsicos de Java (y de casi cualquier lenguaje de programacin), con el objetivo de simplificar al mximo la representacin genrica de los mismos. Los tipos de dato y sus correspondencias con los tipos de dato de KNX que vamos a definir son: Tipo de dato del sistema boolean integer Tipos de dato KNX/Calimero boolean 3_bits_controlled 8_bits_unsigned 2_bytes_unsigned 4_bytes_unsigned long date hour date_hour float String 2_bytes_float string char
Adems, se implementa la clase KNXDevice como especializacin de la clase abstracta Device para dar soporte a este tipo de dispositivos, y la clase KNXManager que se encarga de controlar los dispositivos KNX presentes en el sistema. Contiene mtodos para conectarse al router KNX, hacer la consulta de los dispositivos presentes y transformar los eventos de Calimero en los eventos que definimos para la comunicacin.
Jose Alcal Correa
120
Kora
5.3. ENTRENADOR
DE
PRUEBAS KNX
Para hacer las pruebas con una instalacin domtica real hemos contado con un entrenador de pruebas KNX propiedad de la Universidad de Granada. Los componentes de este entrenador se compraron el ao pasado para el Proyecto Fin de Carrera de un alumno que dise una biblioteca para la integracin de varias tecnologas domticas. El entrenador tiene los siguientes componentes: Fuente de alimentacin Acoplador de bus KNX Detector de humedad Sensor de temperatura Detector de presencia de techo (360) Detector de presencia de pared (180) Dos bombillas normales y una regulable. Salida de 4 canales analgicos (para conectar las bombillas) Dos interruptores sencillos Teclado de dos botones programable Teclado de 4 botones programable Teclado de 8 botones programable Interfaz de comunicacin USB Interfaz de comunicacin Ethernet (para KNXNetIP)
Tambin se compr un actuador de persianas, pero no se ha instalado en el panel entrenador.
Jose Alcal Correa
121
Kora
CAPTULO VII:
USO DE LA APLICACIN
122
Kora
1. MANUAL
DE
INSTALACIN
USUARIOS FINALES
1.1. INSTALACIN
PARA
Instalacin de la aplicacin cliente

La aplicacin puede instalarse fcilmente en mviles Android siguiendo estas instrucciones: 1. Copiar el fichero Kora.apk incluido en el CD a la tarjeta SD del telfono, utilizando el explorador de ficheros del Sistema Operativo o entorno de escritorio que se est usando. 2. Activar la instalacin desde orgenes desconocidos en el telfono. Android bloquea por defecto la instalacin de aplicaciones desde fuera del Market por cuestiones de seguridad.
2.1. Abrir el men principal en el escritorio
Jose Alcal Correa
123
Kora
2.2. Ir a aplicaciones y activar Orgenes desconocidos
2.3. Mediante un gestor de ficheros como ES File Explorer (disponible en el Market), buscar el fichero apk e instalarlo. Ya est la aplicacin instalada y puede abrirse desde el men de aplicaciones.
Jose Alcal Correa
124
Kora
Instalacin de la aplicacin del servidor
Jose Alcal Correa
125
Kora
Conexin al entrenador de pruebas
Jose Alcal Correa
126
Kora
1.2. INSTALACIN
PARA
DESARROLLADORES
Esta gua de instalacin est escrita para personas que deseen estudiar o modificar el cdigo fuente de la aplicacin. De esta forma se pretende facilitar al mximo el acceso a las libertades que garantiza la licencia GPL v3.
Aplicacin cliente
En primer lugar hay que tener instalado el Java Development Kit 1.6 o superior en el ordenador. En caso de que no se tenga, puede instalarse mediante el gestor de paquetes (en distribuciones GNU/Linux) o puede descargarse un instalador desde la web oficial [JDKWeb]. En segundo lugar hay que tener instalado el entorno de desarrollo Eclipse, que puede instalarse mediante el gestor de paquetes de cualquier instalacin de GNU/Linux o puede descargarse desde su pgina web [EclipseWeb] para cualquier Sistema Operativo de escritorio. Una vez instalado Eclipse hay que descargar los paquetes del SDK de Android precompilados para el Sistema Operativo del usuario. Los paquetes pueden descargarse desde [AndroidSDKWeb]. En esa misma pgina se detallan todos los pasos para instalar el SDK e integrarlo con Eclipse. Una vez que est preparado Eclipse para el desarrollo con Android hay que descargar los paquetes necesarios para compilar las aplicaciones para la mquina virtual de Android. Hay que abrir Window Android SDK and AVD Manager, en el dilogo que se abre, elegir Installed Packages a la izquierda, y pulsar el botn Update all. En el dilogo que se abre, hay que elegir la(s) version(es) de Android para las que se quieren crear proyectos. Para Kora es necesario descargar una versin superior a la 1.6. Si el usuario est utilizando Windows, puede ser interesante instalar el driver USB para probar sobre dispositivos reales.
Jose Alcal Correa
127
Kora
Cuando se descarguen los paquetes, si no se tiene un dispositivo Android sobre el que probar la aplicacin hay que crear un dispositivo virtual. En la misma ventana de antes (Android SDK and AVD Manager), hay que elegir el apartado Virtual Devices y pulsar New para crear uno nuevo. Habiendo seguido estos pasos, el entorno est preparado para descargar el cdigo fuente de Kora. Para importar el proyecto en el entorno de desarrollo hay dos opciones: importar el cdigo que est incluido en el CD (para lo cual simplemente hay que usar la herramienta de importacin de Eclipse) o descargar el cdigo desde el repositorio pblico en el que se encuentra. Esta segunda opcin es ms interesante porque puede obtenerse cdigo actualizado y es ms fcil colaborar con el proyecto. Para descargar el cdigo fuente desde el repositorio pblico es necesario tener instalado el plugin Subclipse de Eclipse, que suele venir por defecto con las instalaciones tpicas. Para abrir la perspectiva de repositorios hay que ir a Window Open perspective Other... y en el dilogo que se abra, elegir SVN Repository Exploring. En la vista que se abre, hay que pinchar con el botn derecho en el campo de la izquierda y elegir New Repository Location. En el dilogo que se abre, introducir en el campo URL: https://forja.rediris.es/svn/cusl4-kora/trunk/Kora y pulsar Finish. Se crear una nueva entrada en la lista de repositorios, sobre la que hay que pulsar con el botn derecho y elegir Checkout para obtener el contenido del repositorio. Ahora hay que ir a la perspectiva Java, elegir el proyecto que se ha creado y pulsar el botn de ejecutar (con el smbolo Play). Si todo est bien configurado, se ejecutar la aplicacin en el dispositivo mvil que haya enchufado al ordenador, o se arrancar una mquina virtual con la aplicacin instalada.
Aplicacin servidor
Para descargar la aplicacin servidor, los pasos a seguir son muy similares a los anteriores. En este caso no es necesario instalar el SDK de Android y hay que cambiar la URL del repositorio por: https://forja.rediris.es/svn/cusl4-kora/trunk/KoraServer
Jose Alcal Correa
128
Kora
2. MANUAL
DE USUARIO
2.1. APLICACIN SERVIDOR
Jose Alcal Correa
129
Kora
2.2. APLICACIN CLIENTE

A continuacin se describe la funcionalidad de la aplicacin y qu significan cada una de las opciones que pueden configurarse en la misma. Las descripciones estn acompaadas de capturas de pantalla que facilitan la comprensin del funcionamiento de la aplicacin.
Pantalla inicial
Para iniciar la aplicacin una vez instalada en el dispositivo mvil simplemente hay que elegirla en el men de aplicaciones para que se abra la pantalla inicial.
Figura 1. Pantalla inicial de la aplicacin. La pantalla inicial muestra el usuario actual, el tiempo que queda para el inicio automtico (en caso de que est activado) y los botones para comenzar a usar actividad de control de dispositivos, o para configurar los perfiles de usuario y los ajustes de la aplicacin.
Jose Alcal Correa
130
Kora
Gestin de perfiles
Lo primero que se ve al iniciar la actividad de gestin de perfiles es la lista de usuarios que existen en el sistema. Antes de que los usuarios comiencen a utilizar la aplicacin es necesario que un tutor los registre en la misma. El tutor puede elegir qu usuario va a utilizar la aplicacin, crear otros nuevos y modificar o borrar los existentes.
Figura 2. Lista de usuarios registrados en el sistema. Adems de los usuarios creados por el tutor, se incluye un usuario por defecto que no puede borrarse ni modificarse, y que tiene todas las opciones de accesibilidad desactivadas. Para crear un usuario hay que pulsar el botn de aadir, y para realizar acciones sobre un usuario existente hay que pulsar su entrada correspondiente en la lista y elegir una de las opciones que se muestran. Las siguientes capturas (Figura 3) muestran el men contextual que aparece al elegir un usuario y las acciones que se pueden realizar con los usuarios ya existentes.
Jose Alcal Correa
131
Kora
Figura 3. Men contextual de usuario. Creacin/edicin de usuario. La aplicacin permite registrar datos personales de usuario, elegir su perfil de uso y perfil de dispositivo asociados y asignar una foto para identificar fcilmente al usuario. Tambin es posible definir una cuenta atrs que se iniciar al arrancar la aplicacin, si se desea un arranque rpido para el usuario elegido. El usuario activo se mostrar en todo momento en el panel inferior de la actividad. En la segunda pestaa se listan los perfiles de uso. El perfil de uso asociado a uno o varios usuarios determina cal ser la apariencia y y el comportamiento de la misma para los mismos. Puede crearse un nuevo perfil de uso utilizando el botn de aadir o editar uno existente (Figura 4). Mediante el men contextual tambin es posible asignar un perfil de uso al usuario activo.
Figura 4. Lista de perfiles de uso, men contextual y copia.
Jose Alcal Correa
132
Kora
Cuando se aade o se modifica un perfil de uso existente, se muestran las opciones que se pueden configurar para dicho perfil de uso y el nombre que se desea que tenga. Debido a la gran cantidad de opciones de los perfiles de usuario, estas estn organizadas en cuatro categoras: interaccin, visualizacin, realimentacin y sonido (Figura 5).
Figura 5. Men de edicin de perfiles de uso. El apartado de interaccin (Figura 6) permite definir cmo se relacionar el usuario con la aplicacin, en funcin de sus necesidades o preferencias.
Figura 6. Opciones de interaccin. Las opciones que pueden modificarse son: Tipo de interaccin con el sistema.
Jose Alcal Correa
133
Kora
Tctil directa. El usuario es capaz de presionar distintas zonas de la pantalla. Tambin puede configurarse si el usuario es capaz de arrastrar y soltar elementos en la pantalla (puede mover barras deslizantes, por ejemplo) o solamente hacer pulsaciones sencillas. Barrido. El usuario no puede pulsar con precisin en la pantalla o utiliza un dispositivo auxiliar para interactuar con la aplicacin (como un pulsador simple). El barrido puede realizarse elemento a elemento, de derecha a izquierda y de arriba a abajo, o alternando entre filas y columnas. El intervalo de cambio de elemento es configurable para ambos modos. Paginado. En el caso de que no cupieran todos los elementos en una sola pantalla, se pueden mostrar botones de paginado en la parte inferior de la pantalla. Si el usuario tiene la necesidad de que todos los elementos sean iguales y la distribucin de los mismos sea uniforme, puede establecerse que sea el ltimo botn de la rejilla el que sirva para cambiar de pgina.
Figura 7. Opciones de visualizacin.
Jose Alcal Correa
134
Kora
El apartado de visualizacin (figura 7) define el aspecto que tendr la aplicacin de cara al usuario. En esta pantalla pueden cambiarse los siguientes aspectos: Imgenes e iconos: indica el tipo de imgenes que se cargarn desde las representaciones de dispositivo para mostrarse en los controles de la interfaz de usuario. Puede elegirse entre pictogramas, pictogramas en alto contraste, pictogramas en blanco y negro, fotografas o animaciones. Texto: se puede elegir entre mostrar texto o no, elegir el tamao del mismo respecto al del icono que representa el dispositivo, la tipografa y el efecto de texto a utilizar y el color que tendr. Aspecto de los elementos grficos: para configurar la combinacin de colores que tendrn los elementos grficos de la interfaz (botones, deslizadores y etiquetas). Disposicin de los elementos: para modificar el tamao, nmero y organizacin de los elementos de la interfaz. Orientaciones permitidas: los dispositivos mviles con Android incluyen un acelermetro que les permite detectar cul es la orientacin de la pantalla (vertical o apaisada). Con esta opcin es posible bloquear una orientacin o permitir que la aplicacin se adapte automticamente a la posicin del dispositivo.
Figura 8. Opciones de realimentacin. El apartado de realimentacin (figura 8) permite configurar las reacciones que tendr el programa ante determinadas acciones del usuario. Pueden definirse los siguientes aspectos: Vibracin: si el dispositivo vibrar durante unas dcimas de segundo cuando el usuario pulse un elemento. Esta caracterstica es especialmente til para usuarios con problemas visuales.
Jose Alcal Correa
135
Kora
Confirmacin: permite elegir si se mostrar o no una confirmacin en forma de ventana emergente cuando el usuario realice una accin. Esta caracterstica es especialmente til para usuarios con problemas para controlar movimientos o que estn rehabilitando los movimientos de la mano. El tiempo durante el que se mostrar dicha ventana es configurable, y si en ese tiempo el usuario no ha confirmado la accin, esta se cancelar. Resaltado: se permite elegir el tipo de resaltado ante las acciones del usuario. El resaltado por defecto cambia el color del borde de los botones. Tambin puede elegirse ampliar ligeramente el componente o incrementar el brillo del componente entero.
Figura 9. Opciones de sonido y voz El ltimo apartado de los perfiles de uso permite configurar la realimentacin sonora ante las acciones del usuario. Las opciones que permite configurar son: Configuracin global de sonido: permite elegir entre no reprooducir ningn sonido, reproducir sonidos sencillos o describir las acciones del usuario mediante voz. Eventos que provocarn un sonido: es posible elegir bajo qu condiciones se producirn sonidos. Puede ser cuando un usuario elige un dispositivo de la lista, cuando solicita un cambio de estado en un dispositivo o cuando se produzca cualquiera de las conciciones. Configuracin de voz: si se elige el modo de voz, es posible elegir si la voz a usar ser la del sistema (Android incorpora un sistema de texto-a-voz) o la personalizada que incluya la representacin del dispositivo correspondiente.
Jose Alcal Correa
136
Kora
Configuracin de la aplicacin
Figura 10. Actividad de configuracin global. A la actividad de configuracin de la aplicacin se accede desde la pantalla inicial. Esta actividad sirve para configurar el comportamiento general de la aplicacin. La aplicacin incluye un modo de simulacin que puede activarse en el caso de que no est presente el servidor. Dicho modo tiene como objetivo permitir a los tutores probar la configuracin definida en los perfiles de uso antes de que los usuarios finales comiencen a utilizar la aplicacin. De esta forma pueden probarse las configuraciones de una forma segura y ahorrando el tiempo de conexin y el gasto de batera que supone estar conectado a una red inalmbrica.
Jose Alcal Correa
137
Kora
Uso del control de dispositivos

La actividad ms importante de la aplicacin es la de control de dispositivos. El funcionamiento de esta actividad es muy sencillo: inicialmente se muestra una rejilla con todos los dispositivos presentes en el sistema. Los elementos que los representan incluyen un icono que muestra el estado actual del dispositivo. Cuando se elige uno de ellos, se pasa a la actividad de consulta y control de dispositivos, donde el usuario puede consultar de forma ms detallada el estado de un dispositivo, y si este lo permite modificar su estado. Ambas actividades tienen un aspecto y un comportamiento que vienen determinados por el perfil de uso del usuario activo. A continuacin se muestran una serie de capturas con el aspecto de la interfaz segn la configuracin de visualizacin del usuario.
Figura 11. La aplicacin puede funcionar en modo normal o apaisado.
Jose Alcal Correa
138
Kora
Figura 12. Lista de dispositivos con distintas configuraciones En la figura 12 pueden apreciarse distintas configuraciones de la aplicacin. En la primera imagen se muestra una rejilla de 1x2 con los botones por defecto, utilizando fotografas y el mtodo de paginado ltimo elemento. En la segunda captura puede verse la aplicacin configurada en modo de colores alternos y pictogramas sencillos, con el mtodo de paginado ltimo elemento. En la tercera, tanto los elementos grficos como los pictogramas estn en modo de alto contraste. Se utiliza una tipografa especialmente diseada para nios y el mtodo de paginado es el estndar.
Figura 13. Aplicacin en modo monocromo.
Jose Alcal Correa
139
Kora
En la figura 13 se puede ver la aplicacin funcionando en modo de visualizacin monocromo y sin texto. En la primera captura se muestra cmo funciona la interaccin mediante barrido: se oscurecen todos los elementos excepto el que tiene el foco en el momento. Si se pulsa la pantalla del dispositivo (o un pulsador conectado al mismo) se elegir dicho elemento y la aplicacin pasar a la actividad de control de dispositivo. En la segunda captura de la figura 13 se muestra la interfaz de control para una persiana en monocromo, con una tipografa fcil de leer y con controles de arrastrar y soltar.
Jose Alcal Correa
140
Kora
CAPTULO VIII:
CONCLUSIONES
Jose Alcal Correa
141
Kora
1. RESUMEN
DEL
TRABAJO
La concepcin inicial del proyecto fue crear una aplicacin de control de entorno adaptable para dispositivos mviles. No se tena planeada la gestin de mltiples usuarios y perfiles y la intencin era desarrollarla para dispositivos iOS de Apple (como el iPhone o el iPod Touch). Tanto el campo de los dispositivos mviles inteligentes como el de la domtica eran totalmente desconocidos para m. Inmediatamente, comenc a instalar el entorno de desarrollo para iOS y a aprender a utilizar las herramientas que provea. No obstante, empezaron a surgir grandes dificultades que hacan muy difcil el desarrollo del proyecto. El entorno de desarrollo de iOS solo puede instalarse sobre el Sistema Operativo MacOS X, que solo est disponible para ordenadores de Apple. Intent instalar versiones extraoficiales en mi ordenador personal (siendo un PC normal y corriente) pero los problemas seguan yendo en aumento: el sistema funcionaba mal en el ordenador de sobremesa, pero en el porttil s funcionaba correctamente (aunque no poda usar el WiFi). Adems, no me senta cmodo utilizando OSX y me costaba siquiera iniciar el sistema. A mediados de octubre surgi la oportunidad de presentarme al IV Concurso Universitario de Software Libre, se lo consult a mi tutora y estuvo de acuerdo. No obstante, los organizadores no me permitieron presentar un proyecto para iOS debido a incompatibilidades entre el entorno de desarrollo de dichos dispositivos y las licencias libres. As que, evaluando el resto de propuestas que haba en el mercado, propuse cambiar la plataforma de desarrollo a Android [cambioAndroid], lo aceptaron y comenc a programar para la plataforma. Este cambio de plataforma fue decisivo para el desarrollo posterior del proyecto e influy en prcticamente todos los mbitos del proyecto. Puede considerarse que, a pesar de no estar completo, el proyecto incluye la gran mayora de la funcionalidad que se pretenda implementar, a pesar de la gran cantidad de problemas que ha habido durante el desarrollo (que se detallarn en una seccin posterior) y de la magnitud del mismo. La lista de caractersticas que finalmente se han implementado son las siguientes: Gestin de usuarios completa. Gestin de perfiles de uso completa. Implementacin de todas las opciones visualizacin de los perfiles de uso. de interaccin y
Jose Alcal Correa
142
Kora
Implementacin parcial de las opciones de realimentacin (vibracin, resaltados) y sonidos (sonidos sencillos ante todos los tipos de eventos). Se implement un simulador de la instalacin domtica para probar el protocolo de comunicacin dispositivo mvil servidor. Se ha implementado la conexin sencilla con el entrenador KNX, ampliable a otras instalaciones distintas. Se ha creado un sistema de representaciones de dispositivos domticos fcilmente extensible y que permite dar soporte a varios usuarios con necesidades muy distintas. Se han incluido con la aplicacin un conjunto de representaciones preestablecidas. Se ha desarrollado soporte especfico para dispositivos con varias resoluciones distintas.
Jose Alcal Correa
143
Kora
2. GRADO
DE
CONSECUCIN
DE
OBJETIVOS
Este poyecto ha estado en constante evolucin y ha experimentado grandes cambios desde el mismo momento en que se definieron sus objetivos. Los requisitos de la aplicacin para dispositivos mviles han ido creciendo segn se avanzaba en el desarrollo de la aplicacin y los eventos que han sucedido durante el mismo han contribuido tambin en los diversos cambios que hhan surgido. Gran parte de estos cambios han estado motivados por las sugerencias, las peticiones y en general la ayuda de los distintos miembros del grupo GEDES, autores del proyecto Sc@ut donde se enmarca Kora. Gracias a ellos han surgido ideas como la interaccin por barrido, la integracin con BlueRose o la copia rpida de perfiles. El nivel de consecucin de objetivos planteados cuando se comenz el proyecto es: 1. Facilidad y simplicidad de uso. Teniendo en cuenta la complicacin que supone configurar una instalacin domtica, puede considerarse que la instalacin y puesta en marcha de la aplicacin es bastante sencilla. Solo se necesita saber la direccin de cada uno de los dispositivos de la instalacin, indicrselos al programa servidor y arrancarlo. La aplicacin de control de dispositivos tiene un mecanismo de uso muy sencillo: elegir dispositivo modificar valores volver a la lista de dispositivos. Es un ciclo de tres pasos que solo requiere interacciones sencillas y que puede adaptarse de forma sencilla a varias representaciones y formas de interaccin. Por ltimo, la aplicacin de configuracin de perfiles tambin es muy sencilla de usar y apenas requiere entrenamiento a los tutores. 2. Modificacin de la forma en que se interacta con la aplicacin. Este es uno de los objetivos ms importantes y se ha conseguido. La implementacin de los mtodos de interaccin que se plantearon inicialmente (interaccin directa y barrido) se han implementado. 3. Modificacin de la interfaz grfica de la aplicacin, para
144
Kora
hacerla adaptable a personas con problemas visuales o de atencin. Este objetivo tambin se ha cumplido. Se han implementado todas las opciones de visualizacin que se propusieron inicialmente (normal, colores alternos, alto contraste, blanco y negro). 4. Asimismo, la realimentacin sobre las acciones que realice el usuario debe presentarse de distintas maneras. Este objetivo se ha cumplido parcialmente, pues no se han implementado los dilogos de confirmacin ni el texto-a-voz. 5. Robustez, eficiencia y estabilidad. Este objetivo est cumplido. En todas las pruebas que se han hecho de la aplicacin, no ha presentado errores como cuelgues, fallos de memoria o excepciones graves. Adems, el protocolo de comunicacin es rpido (los cambios en el sistema se notifican de forma prcticamente instantnea a todos los clientes) y la respuesta de la interfaz de usuario es rpida e inmediata. 6. Escalabilidad. Este objetivo se ha cumplido en su totalidad. La aplicacin cliente soporta varios usuarios en el mismo dispositivo y varias representaciones posibles para los dispositivos presentes en el sistema. El protocolo de comunicacin utilizado permite que otras aplicaciones no tan especficas como Kora puedan conectarse tambin al servidor y utilizar la misma instalacin domtica. 7. Soporte para el mayor nmero de dispositivos domticos. Conseguido. El diseo de la aplicacin del servidor permite que puedan disearse mdulos nuevos para dar soporte a otros estndares domticos de forma transparente. 8. Soporte para un gran nmero de dispositivos mviles. Conseguido. Android es un Sistema Operativo que se ejecuta en una gran variedad de dispositivos mviles. 9. Utilizacin de formatos estndar y abiertos. Conseguido. La aplicacin utiliza formatos como XML o SQLite para el almacenamiento y comparticin de datos. Al ser un proyecto libre, este objetivo era bsico.
145
Kora
10. Configuracin de herramientas externas.
la
aplicacin
sin
necesidad
de
Conseguido parcialmente. Se han implementado la gestin de usuarios y perfiles de uso, pero finalmente no se ha podido incluir la gestin de permisos o perfiles de dispositivo. La configuracin de la conexin al servidor tambin se ha implementado en el propio dispositivo mvil. 11. Acceso concurrente de varios usuarios a los mismos dispositivos domticos. Se ha conseguido gracias al diseo de un protocolo de comunicacin orientado a eventos y al uso de una plataforma de comunicacin distribuida para implementar dicho protocolo. Como puede comprobarse, a excepcin de algunas opciones de realimentacin y sonidos y los perfiles de dispositivo, se ha conseguido superar la gran mayora de los objetivos iniciales del sistema. De hecho, se han desarrollado caractersticas que no estaban pensadas desde un principio, como el simulador para la instalacin domtica y la representacin genrica de los dispositivos conectados al sistema. De hecho, se espera que los resultados de este proyecto se integren dentro del proyecto Sc@ut, contine el desarrollo del proyecto y sea finalmente utilizado en entornos reales.
Jose Alcal Correa
146
Kora
3. EVENTOS
DURANTE EL
DE
DESARROLLO
EN LA
3.1. I HACKATHN
SOFTWARE LIBRE
UGR
A principios del mes de marzo, la Oficina de Software Libre de la Universidad organiz el I Hackathn de Proyectos de Software Libre de la UGR [Hackathn]. Este evento tena como objetivos promover la liberacin de los Proyectos Fin de Carrera de los alumnos de la facultad. El evento consisti en la presentacin de una serie de proyectos (entre los que se encontraba Kora) el viernes de esa semana. Los asistentes a las exposiciones elegan uno de los proyetos y colaboraban con l durante el fin de semana. Antes del inicio del Hackathn Kora estaba en un estado de desarrollo bastante temprano y apenas tena funcionalidad implementada. Durante ese fin de semana tampoco avanz mucho debido a innumerables problemas que tuvimos los colaboradores y yo (idas de luz, ningn sitio para quedar, problemas con la conexin a Internet), aunque se consigui hacer una primera versin del apartado de configuracin y de las vistas personalizadas. A pesar de los problemas, el desarrollo del proyecto tom un gran impulso desde este evento y el ritmo no baj hasta el final del curso.
Jose Alcal Correa
147
Kora
3.2. IV CONCURSO UNIVERSITARIO
DE
SOFTWARE LIBRE
Como ya se indic en la seccin de resumen, el proyecto se inscribi en el IV Concurso Universitario de Software Libre. Fue aceptado con la condicin de cambiar el entorno de desarrollo de iOS a Android a principios de diciembre de 2009. La inscripcin en el concurso supuso hacer pblicos en un repositorio todo el cdigo, la documentacin y los recursos utilizados en el proyecto. Adems, se requera hacer un seguimiento detallado en el proyecto en un blog, ya fuera del autor o especialmente creado para el proyecto. El principal efecto que tuvo la inscripcin de Kora en el Concurso (CUSL abreviadamente) fue una mayor motivacin para seguir trabajando en el proyecto. Adems, la publicacin del cdigo y de los resultados que iba obteniendo me sirvieron para obtener realimentacin y ayuda por parte del resto de participantes. Tambin fue til para comenzar a escribir documentacin desde el principio y quitarme trabajo al final del proyecto. Paralelamente al concurso nacional, la Oficina de Software Libre de la Universidad de Granada organiz un concurso exclusivamente para proyectos granadinos. A dicho concurso se presentaron cuatro proyectos: ViSuSe [Visuse], de Jos Luis Lpez Pino: un metabuscador de imgenes basado en Django y extensible mediante plugins. Puede utilizarse visitando www.visuse.com. Tea [Tea], de Ricardo Cauelo: es un entorno de desarrollo para trabajar con dispositivos empotrados, especialmente la placa BeagleBoard. ReMa [ReMa], de Antonio Ares: una plataforma web para gestionar publicaciones cientficas. Kora.
En la final, celebrada el 26 de abril, Kora gan el primer premio al mejor proyecto libre de la UGR, y ViSuSe y Tea se llevaron los premios a la difusin y la innovacin, respectivamente. La final del CUSL a nivel nacional se celebr en Cdiz los das 13 y 14 de mayo. Se presentaron al concurso ms de 100 proyectos de toda Espaa y llegaron ocho a la fase final, entre los cuales estaban Kora y ViSuse. Durante estos dos das se celebraron una serie de charlas relacionadas con el Software Libre, se presentaron todos los proyectos finalistas y tambin hubo tiempo para conocer a mucha gente interesante.
148
Kora
Los premios se decidieron durante el medioda del 14 de mayo y Kora se llev el premio al mejor proyecto de accesibilidad. Este premio, adems de la parte econmica tambin supuso una gran experiencia para m y un fuerte impulso al desarrollo del programa. Tambin sirvi para darle difusin meditica y que muchas personas se interesaran por el mismo.
Jose Alcal Correa
149
Kora
3.3. ARTCULOS
ASISTENCIA
CONGRESOS
Durante este ao Kora tambin ha aparecido en varios artculos publicados por el grupo GEDES, debido a su relacin con otros proyectos del grupo y a los objetivos que persigue. Junto a <meter casita piaget aqu>
Jose Alcal Correa
150
Kora
3.4. PROBLEMAS
DURANTE EL
DESARROLLO
El desarrollo de Kora no ha estado exento de cambios bruscos y problemas que han afectado a su desarrollo de forma ms o menos importante. El primer problema con el que me encontr (aunque no tiene por qu considerarse como tal) fue mi nula experiencia en el desarrollo para dispositivos mviles y el total desconocimiento de los sistemas domticos. A pesar de esto, los integrantes del grupo me proporcionaron una gran cantidad de informacin, documentacin y ayuda que fueron vitales para comenzar de forma ms suave a desarrollar el proyecto. El segundo problema ha sido la falta de documentacin clara y sencilla sobre KNX y la biblioteca Calimero. Normalmente la formacin relacionada con instalaciones domticas se obtiene haciendo cursos certificados y es muy complicado encontrar documentacin libre y gratuita para aprender por propia cuanta. A pesar de esto hemos contado con la ayuda de Jos Manuel, que s tiene experiencia en el montaje y la configuracin de redes KNX y me ha enseado a utilizar el software ETS3. El principal problema de Calimero es que la nica documentacin que incluye solo consta de algunos ejemplos bastante complejos y la documentacin Javadoc del cdigo fuente. Por otra parte, la nomenclatura de las clases de la biblioteca y de sus mtodos es muy poco clarificadora y la biblioteca puede llegar a ser muy compleja de usar para segn qu fines. Finalmente aprend a usar la biblioteca mediante ensayo y error y rebuscando por los pocos foros que hay disponibles con informacin sobre la biblioteca. Al principio no estaba previsto utilizar Calimero directamente para acceder a los dispositivos de la instalacin domtica. El propsito inicial era utilizar una biblioteca desarrollada el ao pasado como PFC cuyo objetivo fue crear una capa de abstraccin que permitiera acceder a varios estndares domticos abstrayendo al programador de la aplicacin. Esta biblioteca, a priori, es mucho ms sencilla de usar que Calimero y se ajusta mejor a nuestras necesidades. El problema que nos encontramos es que no hubo manera de hacerla funcionar. Se perdieron ms de dos semanas de desarrollo intentando hacer funcionar la biblioteca hasta que se decidi buscar una alternativa. Fue entonces cuando encontramos el proyecto OpenRemote, que tiene una filosofa similar, pero tena unos requisitos demasiado altos (era complicada
151
Kora
de configurar y tendra que cambiar el sistema previo casi al completo) y haba muy poca documentacin para utilizar el sistema fuera de las soluciones integrales que comercializan los integrantes del proyecto. Por tanto, se decidi usar Calimero directamente a pesar de ser compleja de utilizar, pues al menos funcionaba.
Jose Alcal Correa
152
Kora
4. TRABAJO FUTURO
Creemos que esta aplicacin tiene un gran potencial y sobre todo, una utilidad real que puede ser de gran ayuda para un gran nmero de personas. Durante el proceso de desarrollo han surgido muchsimas ideas y caractersticas que por falta de tiempo y recursos no se han podido incluir en la aplicacin. Estas son mis sugerencias para trabajos futuros que podran desarrollarse basndose en el proyecto actual. Gestin de perfiles utilizando XML de forma nativa, en lugar de usarlo solo como formato de intercambio de informacin. Mejora y ampliacin de la gestin de usuarios y perfiles: permitir la creacin de grupos de usuarios o aadir nuevas opciones de accesibilidad. Integracin con Sc@ut para la creacin de usuarios y perfiles de uso mediante el ordenador, de forma ms rpida que con el mvil. Integracin con Sc@ut para la creacin de representaciones de dispositivos de forma sencilla. Mejoras en el protocolo de comunicacin para hacerlo ms seguro y robusto. Aadir soporte para dispositivos compuestos o virtuales. Por ejemplo, grupos de luces o conjuntos de automatismos en una habitacin. Integracin con otros estndares domticos, especialmente ZigBee. Desarrollo de un driver Bluetooth y un IME para Android para dar soporte a pulsadores u otro tipo de herramientas de interaccin interactivas. Integracin de la aplicacin servidora en sistemas empotrados. Creacin de una interfaz grfica desde cmodamente una instalacin domtica. la que gestionar
Integrar la aplicacin mvil caractersticas de realidad aumentada, que permitira una interaccin ms directa y comprensible a los usuarios. Desarrollo de una herramienta de monitorizacin para tutores. Esto puede ser especialmente til en centros de educacin especial que cuenten con instalaciones domticas. Esta herramienta podra ser una aplicacin para dispositivo mvil, para PC o incluso un servicio web. Portar la aplicacin mvil a otras plataformas como iOS o MeeGo.
Jose Alcal Correa
153
Kora
Crear un sistema adaptativo que aprenda de las acciones que ms realiza el usuario y les d mayor relevancia, por ejemplo, ponindolas al principio o en lugares ms a la vista. Creacin de un servicio centralizado de descarga de representaciones de dispositivos, para que los usuarios de la plataforma puedan compartirlas. Crear un sistema de temas intercambiables que permita personalizar el aspecto de la aplicacin de una forma ms potente y sencilla.
Jose Alcal Correa
154
Kora
5. CONCLUSIONES PERSONALES
Teniendo en cuenta el mbito para el que se ide el proyecto, desde el principio se busc que fuera til de verdad para el mayor nmero posible de personas. Por si fuera poco el aliciente que supone crear por primera vez una aplicacin que sirve para algo ms que para aprobar una asignatura, se dieron adems una serie de circunstancias que hicieron an ms provechoso el desarrollo de este proyecto. Antes de comenzar, las tecnologas que se han utilizado en este proyecto eran prcticamente desconocidas para m. Ha sido especialmente interesante aprender a desarrollar para dispositivos mviles, pues es un campo de la informtica que est actualmente en auge y adems he descubierto que me gusta de verdad. La participacin en los concursos de Software Libre, y los premios conseguidos en las fases finales han supuesto un gran aliciente para poner ms empeo en el proyecto. Tambin ha sido muy importante para m el hecho de en el grupo de investigacin hayan contado conmigo y con mi trabajo para escribir artculos y presentarlos a diferentes congresos. En definitiva, la realizacin de este proyecto ha supuesto la mejor experiencia de mi vida acadmica y me ha proporcionado conocimientos y habilidades que sern muy necesarios durante los prximos aos. Tambin espero que mi trabajo sirva para facilitar en la medida de lo posible la integracin en la sociedad de las personas con necesidades especiales, y adems facilite sus quehaceres diarios.
Jose Alcal Correa
155
Kora
6. AGRADECIMIENTOS
Me gustara agradecer a varias personas todo el apoyo, la ayuda y los nimos que me han transmitido durante el desarrollo del proyecto. En primer lugar me gustara agradecerle a mi tutora, Mara Jos, el haber confiado en m para desarrollar este proyecto tan interesante, ambicioso y con un propsito tan noble. Han sido muy importantes su ayuda a lo largo de todo el curso, las ideas y sugerencias que me ha ido aportando y sobre todo, la paciencia que ha tenido conmigo. Tambin me gustara agradecerle el darme la oportunidad de haber participado en la redaccin de artculos cientficos que se han presentado a congresos como el CEDI o el Tecnoneet 2010. Sin duda, es la mejor profesora que podra haber tutelado mi proyecto. A Jos Luis Garrido por haber sido mi tutor en la sombra. Tambin ha aportado ideas al proyecto, me ha ayudado en la parte de domtica de la aplicacin y me ha proporcionado abundante documentacin. A Carlos por su disposicin para ayudarme en todos los aspectos relacionados con BlueRose y entre otras cosas, por pasar tardes enteras conmigo intentando descifrar cmo funciona Calimero. A lvaro por sus sugerencias en el desarrollo para dispositivos mviles y en general por todos las ideas que me ha ido aportando. Al resto de becarios y profesores del grupo de investigacin por las mismas razones. A los organizadores de los Concursos de Software Libre, tanto a nivel nacional como granadino. A los chicos que eligieron Kora en el Hackathn para colaborar con el proyecto de forma desinteresada. A Kora, la mascota que dio nombre a este proyecto. Por supuesto, a mi familia, que me ha apoyado durante todo el curso y se han interesado en todo momento por cmo iba avanzando. Y por ltimo y muy especialmente, a Olga, por haber aguantado las charlas interminables sobre el proyecto y sobre todo por haber seguido ah pese a estar semanas enteras sin apenas hablar ni vernos porque estaba ocupado con el proyecto.
Jose Alcal Correa
156
Kora
ANEXOS
Jose Alcal Correa
157
Kora
Jose Alcal Correa
158
Kora
CONTENIDOS DEL CD
Jose Alcal Correa
159
Kora
En el CD que acompaa a este documento pueden encontrarse los siguientes contenidos: Este documento, en formatos OpenDocument (ODT) y Portable Document Format (PDF). Versin en HTML de este documento, para proporcionar una lectura accesible del mismo. Cdigo fuente de la aplicacin cliente. Cdigo fuente de la aplicacin simulador. Cdigo fuente de la aplicacin servidor. Recursos utilizados en la creacin de este documento. Recursos utilizados para la creacin de las aplicaciones. Fichero APK para la instalacin de la aplicacin en un dispositivo Android. Ficheros JAR con las aplicaciones servidor y cliente.
Jose Alcal Correa
160
Kora
BIBLIOGRAFA REFERENCIAS
Jose Alcal Correa
161
Kora
[Remote] http://ieeexplore.ieee.org/Xplore/login.jsp? url=http://ieeexplore.ieee.org/iel5/4594620/4602282/04602527.pdf %3Farnumber%3D4602527&authDecision=-203 [IME] http://android-developers.blogspot.com/2009/04/updatingapplications-for-on-screen.html [WiiIME] http://www.youtube.com/watch?v=-0yHTxoAVqc [TTM] http://www.youtube.com/watch?v=O2BAkD1v5rY http://www.droidapps.org/talk-to-me-android-translator/
[BJ] http://www.bj-adaptaciones.com/catalogo.html? page=shop.browse&category_id=49 [Act] http://www.ii.uam.es/~montoro/publications/ipo2001.pdf [Ami] http://amilab.ii.uam.es/ [Arch] http://www.archlinux.org [scaut] scaut.ugr.es [picaa] scaut.ugr.es/picaa [appStore] http://itunes.apple.com/es/app/picaa/id373334470?mt=8 [lonmark] http://types.lonmark.org/index.html [WAI] http://www.w3c.es/Traducciones/es/WAI/intro/accessibility [WAI2] http://www.w3.org/Talks/WAI-Intro/slide1-0 [WCAG] http://www.discapnet.es/web_accesible/tecnicas/WCAG10TECHS-20001106_es.html [WCAG-Checklist]
Jose Alcal Correa
http://www.discapnet.es/web_accesible/wcag10/full162
Kora checklist.html
[GNOME] http://www.gnome.org [GNOMEAccesibility] http://projects.gnome.org/accessibility/ [Ubuntu] http://www.ubuntu.org [Debian] http://www.debian.org [Guadalinex] http://www.guadalinex.org [Accerciser] http://live.gnome.org/Accerciser [GNOMEGuidelines] http://library.gnome.org/devel/accessibility-develguide/nightly/gad-ui-guidelines.html.en [Falcon] http://www.knxforum.com/content/knx-tools-online-shop [KNXLive] http://www.auto.tuwien.ac.at/projects/knx/knxlive.html [Hackathn] http://osl.ugr.es/cursos-y-eventos/i-hackathon-de-proyectosde-software-libre-de-la-ugr/ [ReMa] http://antaress.es/rema/ [ViSuSe] http://visuse.wordpress.com/ [Tea] http://proyectotea.wordpress.com/
Jose Alcal Correa
163

Docu Kora2

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Docu Kora2

Caricato da

Copyright:

Formati disponibili

Proyecto Fin de Carrera

Software accesible para control de entorno mediante dispositivos mviles

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

Captulo II. Investigacin.

Captulo III: Modelado de requisitos

Captulo IV: Anlisis

Software accesible para control de entorno mediante dispositivos mviles

Captulo VI: Implementacin

Captulo VII: Uso de la aplicacin

Software accesible para control de entorno mediante dispositivos mviles

Captulo VIII: Conclusiones

Anexos Bibliografa y referencias Contenidos del CD

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

Software accesible para control de entorno mediante dispositivos mviles

1.3. DESCRIPCIN DETALLADA

Jose Alcal Correa

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

CAPTULO II: INVESTIGACIN

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

1.1. SOLUCIONES SIMILARES

Software accesible para control de entorno mediante dispositivos mviles

Remote and mobile control in domotics

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

1.2. PLATAFORMAS MVILES

Apple iPod Touch, iPhone y iPad

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

1.3. SISTEMAS DOMTICOS COMERCIALES

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa

Proyecto Fin de Carrera. Septiembre de 2010

Software accesible para control de entorno mediante dispositivos mviles

Jose Alcal Correa