Índice - ujaen.estauja.ujaen.es/bitstream/10953.1/7996/1/Documentacion.pdf · Antonio Gómez...

Antonio Gómez Arjonilla Desarrollo de un sistema domótico para el control de elementos de un hogar a través de una Raspberry PI

1 Escuela Politécnica Superior de Jaén

Índice

1.- Introducción ..................................................................................................................... 6

1.1.- Motivación ................................................................................................................. 6

1.2.- Objetivos.................................................................................................................... 7

1.3.- Metodología ............................................................................................................... 8

1.4.- Estructura del documento .......................................................................................... 9

2.- Análisis ............................................................................................................................10

2.1.- Análisis preliminar .....................................................................................................11

2.1.1 - ¿Qué es la domótica? ........................................................................................11

2.1.2 - Utilidades de la domótica ...................................................................................12

2.1.3 - Historia ...............................................................................................................13

2.1.4 - Ventajas de un sistema domótico .......................................................................14

2.1.5 - Desventajas de un sistema domótico .................................................................15

2.1.6 - Tipos de arquitectura ..........................................................................................16

2.1.7 - Sistemas domóticos existentes ..........................................................................17

2.1.8 - Raspberry Pi 2 ...................................................................................................19

2.2 - Propuesta de solución ..............................................................................................21

2.3 - Requisitos del sistema ..............................................................................................21

2.3.1 - Requisitos funcionales........................................................................................22

2.3.2 - Requisitos no funcionales ...................................................................................22

2.4 - Planificación de tareas ..............................................................................................23

2.4.1 - Enumeración de las tareas y subtareas ..............................................................25

2.4.2 - Diagrama de Gantt .............................................................................................26

2.5 - Estudio de viabilidad .................................................................................................27

2.5.1 - Presupuesto .......................................................................................................28

2.6 - Modelo de dominio ...................................................................................................30

2.7 – Casos de uso ...........................................................................................................31

2.7.1 - Caso de Uso 1: Inicio de sesión .........................................................................35

2.7.2 - Caso de Uso 2: Modificar datos del usuario .......................................................36

2.7.3 - Caso de Uso 3: Subir mapa del hogar ................................................................37

2.7.4 - Caso de Uso 4: Añadir elemento al plano del hogar ...........................................38

2.7.5 - Caso de Uso 5: Visualizar cámara disponible .....................................................39

2.7.6 - Caso de Uso 6: Cambiar estado de un elemento ...............................................40

2.7.7 - Caso de Uso 7: Ver estado general del hogar ....................................................41

3 - Diseño .............................................................................................................................42



3.1 - Diagrama Entidad-Relación ......................................................................................42

3.1.1 - Normalización ....................................................................................................43

3.1.2 – Normalización de las tablas ...............................................................................44

3.2 - Diagrama de Clases .................................................................................................44

3.3 - Diagramas de secuencia ..........................................................................................47

3.3.1 - Diagramas de secuencia del sistema .................................................................47

3.4 - Diseño de la Interfaz .................................................................................................50

4.- Implementación ...............................................................................................................53

4.1 - Arquitectura ..............................................................................................................55

4.2 - Detalles sobre implementación .................................................................................56

4.2.1 - Detalle de implementación de recurso REST .....................................................61

4.2.2 – Ejemplo raspberry en funcionamiento ..........................................................63

4.3 - Pruebas ....................................................................................................................66

5.- Conclusiones...................................................................................................................69

Bibliografía ...........................................................................................................................70

Anexo A. Manual de instalación ...........................................................................................72

Instalación del servidor .....................................................................................................72

1. Instalación del sistema operativo............................................................................72

2. Instalación de SSH .................................................................................................75

3. Instalación de Java 1.8 ...........................................................................................76

4. Instalación de Apache y MySQL ............................................................................76

5. Instalación de FTP .................................................................................................78

6. Ejecutar la aplicación en la Raspberry ...................................................................78

Instalación del cliente........................................................................................................78

Anexo B. Manual de usuario ................................................................................................79

Identificación .....................................................................................................................79

Vista general del hogar .....................................................................................................80

Cambiar el estado de un elemento del plano ....................................................................81

Añadir un nuevo elemento al plano ...................................................................................83

Mover un elemento situado en el plano ............................................................................84

Eliminar un elemento del plano .........................................................................................86

Cambiar el puerto GPIO de un elemento ..........................................................................87

Ver los datos del usuario ..................................................................................................88

Modificar los datos del usuario ..........................................................................................89

Cerrar sesión ....................................................................................................................89



Anexo C. Descripción de contenido suministrado .................................................................90



Lista de figuras

Figura 1: Arquitectura centralizada .......................................................................................16

Figura 2: Arquitectura distribuida ..........................................................................................17

Figura 3: Interfaz de PiDome ................................................................................................18

Figura 4: Imagen de Raspberry PI 2 .....................................................................................19

Figura 5: Puertos GPIO de Raspberry PI 2 ...........................................................................20

Figura 6: Diagrama Gantt .....................................................................................................27

Figura 7: Diagrama de dominio del sistema ..........................................................................31

Figura 8: Diagrama frontera .................................................................................................33

Figura 9: Diagrama frontera servidor ....................................................................................33

Figura 11: Caso de uso de inicio de sesión ..........................................................................35

Figura 12: Caso de uso de modificar datos del usuario ........................................................36

Figura 13: Caso de uso de subir mapa del hogar .................................................................37

Figura 14: Caso de uso de añadir elemento al plano del hogar ............................................38

Figura 15: Caso de uso de visualizar cámara disponible ......................................................39

Figura 16: Caso de uso de cambiar estado de elemento ......................................................40

Figura 17: Caso de uso de ver estado general del hogar .....................................................41

Figura 18: Diagrama entidad-relación ...................................................................................42

Figura 19: Modelo relacional ................................................................................................43

Figura 20: Diagrama de clases .............................................................................................45

Figura 21: Diagrama de secuencia iniciar sesión..................................................................47

Figura 22: Diagrama de secuencia modificar datos del usuario ............................................48

Figura 23: Diagrama de secuencia subir mapa del hogar .....................................................48

Figura 24: Diagrama de secuencia añadir elemento al mapa ...............................................49

Figura 25: Diagrama de secuencia cambiar estado de un elemento.....................................49

Figura 26: Diagrama de secuencia visualizar estado general del hogar ...............................50

Figura 26: Interfaz ventana para iniciar sesión .....................................................................51

Figura 27: Interfaz ventana de administración ......................................................................51

Figura 28: Interfaz modificar elementos ................................................................................52

Figura 29: Interfaz preferencias ............................................................................................53

Figura 30: Arquitectura cliente-servidor ................................................................................54

Figura 31: Diagrama de componentes ..................................................................................55

Figura 32: Fragmento código de la vista ...............................................................................60

Figura 33: Función eliminarElemento de angularJS .............................................................60

Figura 34: Recurso REST implementado .............................................................................61

Figura 35: Uso puertos GPIO ...............................................................................................62

Figura 36: Raspberry PI 2 con elementos conectados .........................................................63

Figura 37: Aplicación cliente con elementos ejemplo ...........................................................64

Figura 38: Raspberry PI 2 con algunos elementos encendidos ............................................64

Figura 39: Aplicación cliente con elementos encendidos ......................................................65

Figura 40: Aplicación cliente cámara grabando ....................................................................65

Figura 41: Ventana inicio instalación del sistema operativo en raspberry PI 2 ......................73

Figura 42: Selección del sistema operativo a instalar ...........................................................73

Figura 43: Ventana de confirmación de instalación del sistema operativo ............................74

Figura 44: Ventana de proceso de instalación del sistema operativo ....................................74



Figura 45: Ventana confirmación sistema operativo instalado ..............................................75

Figura 46: Ventana para introducir la clave de root para MySQL ..........................................77

Figura 47: Ventana identificación .........................................................................................79

Figura 48: Ventana email incorrecto .....................................................................................80

Figura 49: Ventana contraseña incorrecta ............................................................................80

Figura 50: Ventana de administración ..................................................................................81

Figura 51: Ventana de administración ..................................................................................82

Figura 52: Menú añadir elemento .........................................................................................83

Figura 53: Nuevo elemento añadido .....................................................................................84

Figura 54: Mover elemento de posición ................................................................................85

Figura 55: Ventana modal para eliminar elemento ...............................................................86

Figura 56: Elemento eliminado .............................................................................................87

Figura 57: Ventana modal cambiar puerto GPIO ..................................................................88

Figura 57: Ventana preferencias ..........................................................................................89



1.- Introducción

1.1.- Motivación

Debido a la gran importancia que se está dando a la comodidad de las personas

y que su día a día sea más fácil y confortable se ha decidido realizar un sistema en el

que el usuario sea capaz de poder comprobar el estado de la mayoría de elementos

que se dispone normalmente en un hogar, además de poder cambiar el estado de

éstos de forma fácil e intuitiva cuando el usuario crea conveniente.

Si se aplica la tecnología al hogar, se encontrará un gran conjunto de

posibilidades y ventajas, una rama de la tecnología que se aplica a este caso es la

domótica. La domótica se introdujo en España a partir de los noventa a través de los

Pirineos, la palabra domótica procede del latín, domus (casa) y del griego automática

(autónomo).

Como aproximación y de forma simplificada, se puede afirmar que la domótica

consiste en introducir la tecnología para mejorar la calidad de vida de las personas y

ampliar la comunicación, es decir, se puede automatizar procesos domésticos

intercomunicando estos procesos con los habitantes del hogar y el exterior. Cuando

se habla de domótica, se habla de sistemas integrados por muchos componentes que

interaccionan entre sí y casi nunca de forma fácil (se puede imaginar un sistema que

accione una alarma, un sistema de prevención de incendios o un sistema de

prevención de inundaciones cuando sucede algún evento en el hogar y el habitante

de dicho hogar no está presente). [1]

La domótica aporta una serie de beneficios para el usuario, como puede ser la

seguridad, el control del hogar o el ahorro de energía, éstos beneficios son muy

importantes para el usuario. Uno de los puntos más importantes puede ser la

seguridad ya que se podría usar cámaras de seguridad y así persuadir y evitar actos

delictivos. Otro punto clave sería el control del hogar, ésta es la característica más

fundamental en la domótica porque es el punto en el cual un usuario puede cambiar

el estado de los elementos que dispone en su hogar. Por último, un aspecto relevante

es el ahorro energético debido a que actualmente las personas están más

concienciadas en la conservación del medio ambiente, además de su economía.



Por todo lo comentado anteriormente, se ha realizado este proyecto en el cual

un usuario podrá controlar por medio de internet todos los elementos disponibles en

el hogar así como ver su estado.

1.2.- Objetivos

Para el desarrollo del presente trabajo se han planteado los siguientes objetivos

que serán desarrollados a lo largo del presente documento.

1. Diseñar una aplicación web para el control y administración de los

elementos disponibles en el hogar. Con este objetivo se pretende que el

usuario del sistema pueda controlar todos los elementos que hay en su

hogar de forma remota.

2. Diseñar e implementar servicios REST para el manejo de estado de los

elementos disponibles en el hogar. Con este objetivo se pretende

realizar una separación entre el cliente y el servidor.

3. Controlar los puertos GPIO de la Raspberry PI para cambiar los estados

de los elementos. Este objetivo es muy importante, ya que sin él, este

trabajo no tendría sentido, controlando los puertos GPIO, se podrá

controlar el estado de los elementos conectados al sistema.



1.3.- Metodología

La metodología de trabajo para la elaboración del proyecto comprenderá las

siguientes tareas:

1. Estudio de los requisitos del sistema a desarrollar. Se estudiará los

requisitos para que el sistema funcione sin ningún tipo de improvisto.

2. Recopilación bibliográfica sobre la temática y tecnologías relacionadas.

Se buscará información sobre la temática del trabajo y las tecnologías

que están relacionadas con la domótica.

3. Estimación temporal y de costes del desarrollo. Se realizará una

estimación del tiempo necesario para realizar el trabajo y cuánto costará

el desarrollo del mismo.

4. Diseño del sistema utilizando una metodología de orientación a objetos

utilizando el patrón de diseño Modelo-Vista-Controlador.

5. Implementación del prototipo del sistema. Se realizará un prototipo del

sistema para comprobar su funcionamiento en una situación real.

Una vez que ya se tiene definida la metodología, se utilizará Scrum [2] como

medio para organizar el desarrollo del proyecto.

Una metodología ágil da un nuevo enfoque para la toma de decisiones en los

proyectos software, esta metodología se basa en desarrollos iterativos e

incrementales, donde los requisitos progresan con el paso del tiempo según la

exigencia del proyecto, todo el trabajo es realizado por un grupo de personas

organizadas entre sí, donde se tomarán diferentes decisiones. Como proceso de

metodología ágil se usará Scrum ya que a través de este proceso se podrá minimizar

los riesgos durante el desarrollo del proyecto.

Se va a definir brevemente lo que es Scrum para tener una ligera idea de lo

que se trata:

Scrum es una metodología ágil la cual se basa en la iteracción, es decir, se va

entregando incrementales de desarrollo del producto. El ciclo de trabajo de Scrum

sería el siguiente:



1) Elección de los requisitos. Cada requisito se crea en un bloque, a cada

bloque se le llamará historia.

2) Se ordenan los bloques en una pila del producto según su prioridad.

3) El equipo de desarrollo seleccionan un grupo de historias, el equipo

trabajarán con estas historias durante el sprint.

4) Una vez que el spring finaliza, se vuelve a empezar por el punto número

dos hasta finalizar la pila del producto.

Hay que aclarar que Scrum es una metodología de trabajo enfocada

principalmente a equipos de trabajo, por lo que habrá que hacer ligeras adaptaciones

para adaptarla a la dinámica de desarrollo del presente TFG realizado por una única

persona. En el apartado de planificación se darán más indicaciones al respecto.

La metodología que se usará para desarrollar este sistema será una

metodología ágil ya que dan un nuevo enfoque para la toma de decisiones en los

proyectos software, esta metodología se basa en desarrollos iterativos e

incrementales, donde los requisitos progresan con el paso del tiempo según la

exigencia del proyecto, todo el trabajo es realizado por un grupo de personas

organizados entre sí, donde se tomarán diferentes decisiones. Como proceso de

metodología ágil se usará Scrum ya que a través de este proceso se podrá minimizar

los riesgos durante el desarrollo del proyecto.

Más adelante, en el apartado 2.3 se especificarán todos los requisitos que

tendrá este proyecto.

1.4.- Estructura del documento

El presente documento se ha organizado en cinco apartados fundamentales,

en los que a continuación se realizará una breve introducción.

Como se ha visto anteriormente, el primer apartado se ha mostrado una

introducción sobre una visión globalizada e introductoria al proyecto que además se

puede apreciar la motivación, los objetivos y la metodología.



Poco después, se mostrará el segundo apartado, en el que trata el análisis del

proyecto, es decir, una descripción del sistema del que se parte. Se hablará de las

utilidades que tienen la domótica, su definición, la historia, características, ventajas,

desventajas y tipos de arquitectura. También se abordará ideas similares y cómo

podemos mejorarlas. Además, se especificarán los requisitos del sistema, tanto

funcionales como no funcionales, la planificación de tareas, estudio de viabilidad,

modelo de dominio y casos de uso.

Más tarde, se detallará el tercer apartado, el cual trata del diseño del sistema.

En el diseño se tratará diferentes diagramas como son el diagrama entidad-relación,

el diagrama de clases, el diagrama de secuencia y también se tratará el diseño de la

interfaz.

Luego, se determinará el cuarto apartado, en el que se estudiará la

implementación, en este punto se incluirá la arquitectura del sistema desarrollado y

los detalles sobre la implementación.

En el quinto apartado, se expondrán las conclusiones, en las que se podrá

comprobar si los objetivos propuestos se han cumplido y lo que se ha realizado para

que éstos se cumplan. También se podrán ver las ventajas e inconvenientes que se

han presentado durante el desarrollo del sistema así como los aspectos más

relevantes del sistema.

Por último, se mostrarán algunos anexos con información adicional. En el

primero se detallará el manual de instalación tanto para el servidor como para el

cliente. En el segundo se mostrará el manual de usuario. El tercero contendrá una

descripción de los contenidos suministrados junto a este TFG.

2.- Análisis

El análisis en ingeniería del software trata de extraer los requisitos más

importantes de un sistema software. El análisis es la primera fase que se debe de

realizar antes de continuar con el desarrollo de un sistema. En la etapa de análisis, el

cliente expone los requisitos que debe tener el sistema, es decir, el cliente explica lo



que desea que el sistema realice. El analista debe de ejercer como un interrogador e

intentar extraer todos los requisitos que el cliente le está relatando. [3]

El análisis de requisitos parece una tarea muy fácil, pero todo lo contrario, ya

que la mayoría de las veces, el cliente piensa que el analista sabe todo lo que el

sistema necesita tener para funcionar correctamente y no expone todas las

funcionalidades de manera clara, por ello, el analista debe de poseer una gran

habilidad a la hora de extraer los requisitos que el cliente no le expone de forma clara

o son contradictorios.

2.1.- Análisis preliminar

El objetivo del análisis preliminar es el de crear una hipótesis en la cual se tenga

en cuenta los factores de riesgos más importantes a la hora de tomar una decisión

para realizar una inversión del sistema, por lo cual, nos ayuda a reducir los riesgos

económicos que se pueda tener a la hora de desarrollar un sistema.

Un análisis preliminar siempre debe tener los siguientes elementos:

- Idea general del proyecto.

- Objetivos del proyecto.

- Evaluación de costes y beneficios.

- Análisis del riesgo.

Para realizar el análisis preliminar, en primer lugar se tratará de lo que es la

domótica y sus características. También se hablará de las utilidades y la historia de la

domótica. Para añadir más información sobre la domótica, se mostrará las ventajas y

desventajas que nos ofrece la domótica. Por último, se mostrará los tipos de

arquitectura que se puede usar en un sistema domótico y se indicarán la existencia

de otros sistemas domóticos.

2.1.1 - ¿Qué es la domótica?

Desde hace años la tecnología ha avanzado para poder hacer más fácil la vida

a las personas, por ello, se han creado numerosos sistemas en la que podemos



integrar dicha tecnología a las viviendas, ayudando así a las personas a poder

controlar su vivienda de manera sencilla y eficaz.

La domótica se puede definir como:

“La Domótica consiste en introducir infotecnología en los hogares para mejorar

la calidad de vida de sus habitantes y ampliar sus posibilidades de comunicación,

automatizando procesos domésticos e intercomunicando tanto estos procesos como

los residentes del hogar entre sí y con el exterior. La infotecnología es pues la

herramienta, las personas sus destinatarios, la satisfacción de determinadas

necesidades suyas su objetivo. Inocente en apariencia, la afirmación anterior encierra

una complejidad enorme.” [4]

2.1.2 - Utilidades de la domótica

Las utilidades de podemos encontrar con la domótica se pueden agrupar en

los siguientes aspectos:

1. Ahorro energético: En el hogar hay muchos aparatos o sistemas que

pueden hacerse consumir menos energía sin tener que cambiarlos

siempre que se tenga una gestión eficiente de dichos elementos.

2. Confort: Esta utilidad permite a las personas programar algunos de los

aparatos del hogar para que funcionen de forma automatizada. Como

en el caso de la iluminación, se puede programar para el apagado o

encendido de forma automática, todo esto no tiene por qué ser de ésta

manera, también es posible que sea controlado a través del usuario ya

sea de forma local o a través de internet.

3. Seguridad: Un sistema domótico nos proporciona más seguridad ya

que puede avisarnos a través de un sistema de alarmas cualquier

anomalía que ocurra dentro del hogar como puede ser una fuga de

gas, inundación, incendio, etc.

4. Accesibilidad: Un sistema domótico tiene que tener un diseño

accesible para todas las personas sin excluir ningún tipo de



discapacidad, de ésta manera, para las personas discapacitadas

podemos mejorar su nivel de vida.

2.1.3 - Historia

La inclusión de la tecnología en los inmuebles de uso no residencial apareció

mucho antes que en las viviendas residenciales, por ello, con la implantación de las

telecomunicaciones y en especial de la informática, las instalaciones en los inmuebles

eran administradas de manera individual.

En España [5], apareció la domótica a finales de los años 80 y principios de los

90 y aparecen las primeras iniciativas para instaurar en la vivienda aunque no tuvo

gran repercusión porque no cumplía las expectativas de los usuarios.

Los grandes problemas que tuvo la domótica en sus inicios fueron el

desconocimiento, un número minoritario de empresas especializadas en el sector,

oferta reducida en la que existían sistemas poco integrados, difíciles de instalar y de

utilizar por el usuario final y excesivamente caros, no existía una normativa sobre la

instalación de dichos sistemas, además, no había profesionales cualificados con

conocimientos específicos.

La domótica tuvo unos inicios muy precarios ya que las tecnologías utilizadas

al inicio dieron lugar a unos interfaces muy poco atractivos para el usuario y con un

elevado grado de especialización por parte de los profesionales que los instalaban,

por ejemplo la utilización de un ordenador que requería de sistemas hechos a medida

para la propia instalación. Además, también aparecieron otras alternativas propietarias

donde cada fabricante diseñó su propio sistema basado en una tecnología en la cual

no existía ninguna documentación y era incompatible con otros sistemas. En

consecuencia a todo lo anterior, existía una falta de motivación por parte de las áreas

demandantes del producto.

Si nos remontamos a otras épocas históricas de éstas tecnologías podemos

decir que en edificios grandes, los sistemas se ejecutaban con simples controladores

que se utilizaban para la climatización, la seguridad, las instalaciones eléctricas, etc.



que eran controlados a través de un ordenador. Sin embargo, en las viviendas

convencionales se usaban dichos elementos vendidos como de alta gama.

2.1.4 - Ventajas de un sistema domótico

De forma general, podríamos establecer las siguientes ventajas a la hora de implantar

sistemas domóticos:

1. Proteger el hogar

Un sistema domótico es capaz de simular la presencia del usuario aunque no

se encuentre en el hogar, el usuario también podrá comprobar el estado de su casa a

través de Internet como puede ser ver imágenes de una cámara o ver el estado de

algunos elementos del hogar. Existen elementos para proteger el hogar como alarmas

de robo, alarmas de incendio, alarmas de gas, etc.

2. Añade valor a la propiedad

Un hogar con un sistema domótico se puede vender de forma más fácil y con

un precio más elevado ya que actualmente hay pocos hogares que poseen estos

sistemas y sería una característica diferenciadora a la hora de vender el hogar.

3. Visión de futuro

Una de las cosas más importantes a la hora de invertir en un sistema domótico

es cuánto durará y la vida de un sistema domótico es bastante extensa, además de

que se podría modificar o añadir elementos en cualquier momento.

4. Ahorro de energía



Un hogar puede ahorrar energía sin tener que cambiar ningún elemento, sólo

es necesario un sistema domótico capaz de hacer que dichos elementos funcionen de

forma más eficaz para poder ahorrar energía.

5. Calidad de vida

Un sistema domótico aumenta bastante la calidad de vida en un hogar ya que

el usuario puede manejar todos los elementos del hogar a través de una manera muy

sencilla y rápida. También aumenta la calidad de vida de personas con algún tipo de

discapacidad porque puede hacer que en el hogar no existan tantas barreras

tecnológicas para ellos.

2.1.5 - Desventajas de un sistema domótico

De forma general podríamos establecer las siguientes desventajas a la hora de

implantar sistemas domóticos:

1. Cierto grado de complejidad

Aunque un sistema domótico está pensado para hacer la vida más fácil a las

personas, hay veces que para dichas personas se le complica la vida más aún porque

puede ser que haya demasiadas opciones en la pantalla para encender o apagar una

simple lámpara.

2. El servicio técnico es casi nulo

Cuando el sistema domótico falla o se avería es muy difícil encontrar a personal

cualificado para solucionar dichos problemas ya que es un sistema que no está

demasiado extendido en los hogares habituales y no existen muchas empresas

especializadas según el lugar geográfico donde se encuentre la vivienda.



2.1.6 - Tipos de arquitectura

Existen dos tipos de arquitectura en un sistema domótico, la arquitectura

centralizada y la arquitectura distribuida [6].

1. Arquitectura centralizada: Esta arquitectura es cuando los

distintos elementos que se van a conectar en el sistema como puede ser

sensores, lámparas, calefacción, etc. tienen que ser cableados hasta el sistema

que controla la vivienda, éste sistema puede ser un ordenador o una unidad de

control creada por una empresa determinada. El inconveniente de esta

arquitectura es que si el sistema que controla la vivienda falla, todo el sistema

dejará de funcionar.

Figura 1: Arquitectura centralizada

2. Arquitectura distribuida: Esta arquitectura es cuando existen más

de un controlador, los cuales están conectados entre sí y los elementos que

deseamos controlar se conectan a un controlador, el que más convenga según

la situación. En este tipo de arquitectura, si un controlador falla no falla todo el

sistema, si no que falla una parte del sistema ya que no existe un controlador

central que controle todo el sistema.



Figura 2: Arquitectura distribuida

2.1.7 - Sistemas domóticos existentes

En este apartado presentaremos algunos sistemas domóticos existentes y

estudiaremos sus principales características.

1. Freedomotic

Freedomotic es un código abierto, flexible, segura de Internet de las Cosas (IoT)

marco de desarrollo, útil para construir y administrar modernos espacios inteligentes.

Está dirigido a particulares (domótica), así como los usuarios de negocios (entornos

minoristas inteligentes, ambiente conscientes de marketing, seguimiento y análisis,

etc). [7]

Como podemos ver, este sistema tiene muchas ventajas para controlar un

edificio inteligente, sin embargo tiene una difícil configuración y no deja al usuario

elegir el puerto por el que están conectados los dispositivos, por el contrario, mi

propuesta permite que el usuario elija el puerto que desee usar para un dispositivo en

concreto, por ejemplo, si un usuario desea conectar una lámpara al puerto GPIO 14



de la raspberry, solamente tiene que añadir una lámpara en el sistema, configurarla

para que se controle en el puerto GPIO 14 y conectar dicha lámpara en el puerto 14.

Otro inconveniente que he encontrado en freedomotic es la difícil usabilidad del

sistema ya que no están demasiado claros los pasos a seguir visualmente.

2. PiDome

PiDome es un código abierto, por eventos y la solución domótica de fácil

acoplamiento activo centrado en la automatización del hogar. [8]

Este framework no tiene una interfaz gráfica muy conseguida, ya que no posee

de un mapa del edificio por el cual el usuario se oriente mejor y se haga una mejor

idea de lo que está activo o no. La interfaz de este framework es una simple tabla con

los elementos que tiene disponibles y el estado de ellos.

Figura 3: Interfaz de PiDome



Por el contrario, mi propuesta permite al usuario enviar al sistema un plano de

su edificio y poder colocar los dispositivos según en el lugar donde se encuentre,

permitiendo así, una mejor visualización de todos los dispositivos a simple vista.

2.1.8 - Raspberry Pi 2

En los últimos años han aparecido en el mercado varios ordenadores de bajo

costo y tamaño reducido que pueden aplicarse con éxito en sistemas domóticos. Uno

de los que más éxito han tenido es el Raspberry Pi 2 [9].

Raspberry Pi 2 es un ordenador integrado en una sola placa o SBC de bajo

costo. Este dispositivo ha sido desarrollado en el Reino Unido por la Fundación

Raspberry Pi.

Una raspberry Pi 2 contiene un procesador ARM Quad-Core 900 MHz, 1 Gb de

memoria RAM, 4 puertos USB, 1 puerto HDMI y un puerto RJ-45. El precio actual de

este dispositivo oscila entre los 30 y 40 euros. Un punto a favor de la Raspberry Pi 2

es que dispone de puertos que pueden ser controlador a través de software, por lo

que es un dispositivo candidato para sistemas domóticos por su bajo consumo

eléctrico y por las posibilidades que ofrece.

Figura 4: Imagen de Raspberry PI 2



Raspberry Pi 2 posee unos pines llamados puertos GPIO, estos puertos se

pueden utilizar para controlar elementos electrónicos como pueden ser led’s, sensores

de temperatura, etc. Los puertos GPIO trabajan con corriente continua a 5V, por lo

que para poder controlar dispositivos que funcionan con corriente alterna (como puede

ser un televisor) necesitaremos tener un relé entre la raspberry y el dispositivo para

poder controlarlo.

Los pines de los puertos GPIO de la raspberry PI 2 son los siguientes:

Figura 5: Puertos GPIO de Raspberry PI 2



2.2 - Propuesta de solución

Se pretende desarrollar un sistema domótico que sea capaz de controlar los

elementos más comunes de un hogar, para ello, se utilizará una Raspberry Pi que

actuará como servidor y controlador de dichos elementos, el sistema se controlará a

través de una página web, donde se podrán añadir elementos, configurarlos, ver el

estado actual o cambiarlo, además de que el usuario pueda ver una visión global de

su hogar.

Las tecnologías que se usarán para el desarrollo de este proyecto, será Spark

Framework el cual es un ligero framework web basado en Java para un rápido

desarrollo. Como cliente de la aplicación se usará una página web basada en HTML,

CSS y AngularJS para gestionar los servicios REST.

Todos los aspectos sobre el uso de Spark Framework se especificarán en el

apartado de implementación.

2.3 - Requisitos del sistema

En el proceso de Ingeniería del Software, se debe empezar con el propósito

final del proyecto, las propiedades y restricciones que deben cumplir. Este paso es

muy importante en el desarrollo de un proyecto software, ya que sin cumplir este paso

el futuro del desarrollo del proyecto se convierte en una tarea muy difícil de realizar.

Después de haber realizado el propósito final del proyecto, se pasa a

especificar los requisitos del proyecto. Estos requisitos que debe de cumplir el sistema

tienen que estar totalmente definidos de forma muy concreta para satisfacer el fin del

proyecto. Existen dos tipos de requisitos:

Requisitos funcionales: Es la característica que debe cumplir un

proyecto software asociado a un objetivo en concreto.

Requisitos no funcionales: Este tipo de requisito se refiere a los

requisitos que no se refieran al funcionamiento del sistema, es decir, a otras

causas externas.



2.3.1 - Requisitos funcionales

Como se ha visto anteriormente, los requisitos funcionales son aquellos que

debe cumplir un proyecto software asociado a un objetivo en concreto. Para conseguir

los requisitos funcionales de este proyecto, nos basamos en otros sistemas que

tengan un fin parecido al propuesto.

Los requisitos funcionales son:

1. El usuario tiene que poder iniciar sesión en el sistema a través

de un nombre de usuario y contraseña.

2. El usuario podrá modificar sus datos como nombre, apellidos, etc.

3. El usuario podrá subir al sistema un plano de su hogar.

4. El usuario podrá añadir elementos que desee controlar a través del

sistema.

5. El usuario podrá modificar un elemento ya añadido en el sistema.

6. El usuario podrá eliminar un elemento que ya esté añadido en el

sistema.

7. El usuario podrá ver en tiempo real imágenes de las cámaras que estén

añadidas en el sistema.

8. El usuario podrá cambiar el estado de un elemento en cualquier

momento.

9. El usuario podrá controlar el sistema desde cualquier lugar a través de

la red.

10. El usuario podrá ver un estado general del hogar de un simple vistazo.

2.3.2 - Requisitos no funcionales

Los requisitos no funcionales son aquellos que se refiere a los requisitos que

no se refieran al funcionamiento del sistema, es decir, a otras causas externas.

Aunque al inicio puede parecer que no son muy importantes, la mayoría de las

veces, pueden llegar a ser los requisitos más importantes para que el sistema funcione



correctamente. Este tipo de requisito determina propiedades del sistema (rendimiento,

disponibilidad, interfaz, etc.).

Estos requisitos se deben de obtener a través de las necesidades software y

hardware de los componentes de manera que el sistema funcione de forma eficaz.

Los requisitos no funcionales son:

1. El sistema será compatible con cualquier resolución y se podrá controlar

tanto desde un ordenador como desde dispositivos móviles.

2. El sistema siempre debe de estar disponible para poder gestionar el

estado de todos los elementos en cualquier momento.

3. El sistema debe ser capaz de procesar todas las solicitudes que el

usuario realice.

4. El controlador de los elementos del sistema no debe de exceder los 40€.

5. La interfaz del usuario debe ser accesible y usable.

2.4 - Planificación de tareas

Dada la naturaleza de este trabajo y de que en Scrum hay diferentes roles, en

realidad todos estos roles serán acometidos por la misma persona con las

implicaciones que eso tendrá en el desarrollo de las iteraciones programadas.

Los requisitos serán especificados en este documento en los puntos

posteriores, no obstante, realizaremos la planificación de las iteraciones que

tendremos que realizar, se supone que la duración del proyecto será de unas 480

horas aproximadamente. Se establece que un sprint tendrá una duración de dos

semanas, por lo que se dispondrá unas diez iteraciones para poder completar el

proyecto. En dichas iteraciones habrá requisitos tanto de la parte del servidor como

de la parte del cliente.

Se ha planificado las tareas de forma que el proyecto tenga una duración de

diecinueve semanas o lo que es lo mismo, una duración de cinco meses.



La planificación se ha organizado de la siguiente forma:

- Se trabajará de lunes a viernes.

- Cada día laboral tendrá 5 horas.

- Aunque en la planificación habrá tareas planificadas de forma paralela,

hay que tener en cuenta que en la ejecución el tiempo de realización

será compartido por la misma persona por la naturaleza de este trabajo.

Antes de desglosar la planificación de tareas de forma detallada, se realizará una

planificación general:

Tarea Tiempo Roles

Análisis preliminar del

sistema 30 horas Analista

Investigación de tecnologías 15 horas Analista

Investigación de frameworks

de desarrollo 15 horas Analista

Diseño e implementación de

la parte servidor 125 horas Analista y programador

Diseño e implementación de

la parte cliente 175 horas Analista y programador

Elaboración de la memoria 120 horas Analista y programador

Total 480 horas



2.4.1 - Enumeración de las tareas y subtareas

Tarea Subtarea Tiempo (horas)

Análisis preliminar del

sistema

Investigación de

tecnologías 15

Investigación de

frameworks de desarrollo 15

Estudio de sistemas

domóticos 30

Desarrollo e

implementación de la

parte servidor

Análisis y diseño de las

tablas 10

Diseño e implementación

la interfaz de control

REST

95


del modelo de datos 20

Desarrollo e

implementación de la

parte cliente


del DAO para acceso

remoto al dispositivo

10

Administración de usuario 165

Elaboración de la

memoria 120



2.4.2 - Diagrama de Gantt

El diagrama de Gantt fue la primera técnica de control y planificación de

proyectos que apareció durante la mitad del siglo XX ya que existía una necesidad de

gestionar proyectos complejos para una mejor organización. Este diagrama muestra

de forma sencilla las fechas en las que se debe de iniciar una tarea así como la fecha

de finalización de dicha tarea. Estas tareas se mostrarán mediante unas barras en

forma de gráfica en los que el tiempo aparecerá en el eje horizontal. También se podrá

observar las tareas que tienen un retraso sobre la fecha planificada o por el contrario,

las tareas adelantadas que aparecerán de forma sombreada.

El diagrama de Gantt hace que la persona encargada de administrar el proyecto

tenga un plan de antelación y suministra una visión general del avance del proyecto

en dicho momento.

Un inconveniente de este diagrama es que no muestra la interacción entre las

diferentes tareas de forma completa. [10]



A continuación, se muestra el diagrama de Gantt de éste proyecto:

Figura 6: Diagrama Gantt

2.5 - Estudio de viabilidad

En un estudio de viabilidad, hay que tener en cuenta los recursos que hay

disponibles como pueden ser recursos software, hardware, presupuesto, tiempo… etc.

Un estudio de viabilidad da como resultado si el proyecto es rentable y si se

puede acometer en los plazos previstos, para saber si el proyecto es rentable se va a

realizar un estudio de viabilidad teniendo en cuenta los costes de desarrollo, los gastos

de material de los que se va a hacer uso durante el desarrollo y nóminas del personal

que tenga que participar, por otro lado, en el apartado 2.4, se ha tratado los plazos

previstos.



2.5.1 - Presupuesto

En este apartado, se calculará los gastos necesarios para recursos humanos

tanto como los gastos en material que será necesario para realizar el proyecto, como

gasto de material se incluirá el coste de los equipos necesarios, acceso a internet y

licencias de software.

Comenzaremos con el cálculo de los gastos necesarios para recursos

humanos, necesitamos calcular el coste de las nóminas del personal necesario para

el desarrollo de este proyecto.

Para este proyecto será necesario contratar a un analista y a un programador,

según el convenio colectivo de Telefónica publicado en BOE [11], el sueldo de un

analista en un mes de trabajo será de 1497.48€ y en el caso del programador será de

1328.78€, en el caso del analista, será necesario contratarlo un mes para que realice

todo el diseño del sistema y en el caso del programador también será necesario

contratarlo un mes para que realice la implementación del sistema.

Personal

contratado

Tiempo

contratado

(horas)

Salario al mes Salario a

percibir

10% horas

adicionadas

por retrasos

Analista 330 1.497,48€ 4.941,68€ 494.17€

Programador 150 1.328,78€ 1.993.17€ 199.32€

Total 7628.34€

Por norma general, un equipo informático se amortiza en 5 años

aproximadamente, por lo que se va a calcular el coste por día que costaría el equipo

de desarrollo.

Se estima que para realizar este proyecto se necesitan 95 días de trabajo.

𝐶𝑜𝑠𝑡𝑒 𝐻𝑎𝑟𝑑𝑤𝑎𝑟𝑒 = 𝑃𝑟𝑒𝑐𝑖𝑜 𝑎𝑑𝑞𝑢𝑖𝑠𝑖𝑐𝑖ó𝑛

𝐴ñ𝑜𝑠 𝑑𝑒 𝑎𝑚𝑜𝑟𝑡𝑖𝑧𝑎𝑐𝑖ó𝑛 =

1440

5= 288 €/𝑎ñ𝑜



𝐶𝑜𝑠𝑡𝑒 𝑝𝑜𝑟 𝑑í𝑎 = 𝐶𝑜𝑠𝑡𝑒 𝑝𝑜𝑟 𝑎ñ𝑜

365=

288

365= 0.79 €/𝑑í𝑎

Seguidamente, se calculará los gastos de material necesarios para desarrollar

el sistema.

Material Recurso Coste Total con

impuestos

Software

Windows 10 Education 0 €

0.34 €

NetBeans 0 €

Spark Framework 0 €

Visual Paradigm Community

Edition 0 €

MySQL 0 €

Raspbian 0 €

AngularJS 0 €

Microsoft Office 2013 0,34€

Hardware

Ordenador dedicado para

desarrollo.

- CPU I7

- Asus X99-Pro

- 8GB de Ram

- 500GB de disco duro

- Ati HD7770

- Monitor de 22’’

74.95 € 127.95 €



RaspBerry PI 2,

transformador y cableado 45 €

Tarjeta microSD 8GB 5€

Sensores y actuadores 3€

Para finalizar, se calculará el coste total del proyecto:

Coste

Personal 7.228,34 €

Software 0,34 €

Hardware 127.95 €

5% contingencias 367,83 €

Proyecto completo 7.724,46 €

2.6 - Modelo de dominio

El modelo del dominio es una reproducción visual de las clases conceptuales del

mundo real en un dominio de interés. Al modelo del dominio también se le conoce

como modelo conceptual, modelo de objetos del dominio y modelos de objetos de

análisis. Empleando la notación UML, un modelo del dominio se muestra como un

conjunto de diagramas de clases en los que no se define ninguna operación.

- Clases conceptuales.

- Asociaciones entre las clases conceptuales.

- Atributos de las clases conceptuales.



A continuación, se muestra el diagrama de dominio del sistema:

Figura 7: Diagrama de dominio del sistema

Como puede observarse en el diagrama de dominio del sistema, la entidad

principal será el elemento. Un elemento representa a los elementos que hay

disponibles en un hogar, como puede ser una lámpara, un televisor, etc. Un usuario

representa a los usuarios que son permitidos por el sistema para identificarse y poder

manipular los distintos elementos que hayan disponibles. Por último, se dispone de un

elementoMapa, esta clase nos indica qué elemento está posicionado en el plano del

hogar y que propiedades tiene como puede ser la posición X e Y del plano en el cual

está situado así como su estado.

2.7 – Casos de uso

Un caso de uso es un conjunto de pasos de interacciones que se realizará entre

un sistema y los actores en contestación a un evento que comienza un actor principal

sobre el sistema. Los diagramas de casos de uso se encargan de especificar la

comunicación y la conducta del sistema, es decir, los casos de uso se representan

mediante un diagrama que expone la relación entre los actores y los casos de uso del

sistema. Una relación es un enlace entre los elementos del caso de uso, existen dos

tipos de relación muy importantes como son la especialización y la generalización. Los

diagramas de casos de uso sirven para mostrar los requisitos del sistema para ver una

visión general de cómo el sistema responde a eventos que se producen.



Un caso de uso consta de lo siguiente:

- Nombre único del caso de uso

- Actores que participan en el caso de uso

- Condiciones de entrada

- Flujo de los eventos existentes en el caso de uso.

- Condiciones de salida

Sabiendo esto, lo primero que debemos de hacer al realizar un caso de uso es

determinar cuáles son los actores que participan en el caso de uso.

Un actor es una entidad externa al sistema que interacciona con éste. Un actor

tiene que tener un nombre único al igual que sucede con un caso de uso.

En este proyecto intervienen los siguientes actores:

- Usuario: Este actor sería el que accede al sistema para visualizar el

estado de los elementos de su hogar o para modificar el estado de éstos.

- Raspberry: Este actor es el encargado de servir toda la información al

cliente.

Cuando ya tenemos definidos todos los actores de nuestro sistema, llega el

momento de realizar los casos de uso. Para conseguir esto, es necesario que todos

los requisitos funcionales que hemos definido anteriormente sean cubiertos por lo

menos por un caso de uso.

Lo primero que debemos de realizar para conseguir los casos de uso del

proyecto es la consecución de distintos diagramas de casos de uso. El primero que

se tiene que realizar es el diagrama frontera, este diagrama muestra la funcionalidad

del sistema de forma completa.



Figura 8: Diagrama frontera

El sistema se planteará como una aplicación cliente-servidor, por lo tanto,

existirán dos aplicaciones diferentes que interactuarán entre ellas. Por este motivo, a

continuación se definirán los diagramas frontera de cada una de estas aplicaciones.

Figura 9: Diagrama frontera servidor



Figura 10: Diagrama frontera cliente

Los casos de uso que se ve anteriormente pueden ser bastante completos o

pueden necesitar que sean explicados de forma más detallada. Para explicar un caso

de uso de forma detallada se puede usar dos tipos de relaciones:

- <<extend>>: Esta relación la usamos cuando un comportamiento se

debe de dar de forma opcional, es decir, no es obligatorio que se de ese

comportamiento.

- <<include>>: Esta relación la usamos cuando un comportamiento se

debe de dar de forma obligatoria, es decir, siempre se debe de dar dicho

comportamiento.

En este sistema nos enfrentamos ante algunos casos de uso que se debe

explicar con mayor detalle. Los casos de uso que se explicarán con más detalle, irán

referidos a la funcionalidad de la aplicación cliente. No se realizará ningún caso de

uso de la aplicación servidor debido a que cada servicio REST hace simplemente una

operación de consulta/modificación sobre el hardware, por lo que consideramos que

la interacción no requiere un análisis exhaustivo.



2.7.1 - Caso de Uso 1: Inicio de sesión

Actores principales: Usuario, Cliente, Servidor.

Condiciones de entrada: El usuario del sistema no está identificado en el sistema.

Flujo de eventos:

3. El usuario entra en la página de inicio del sistema.

4. La aplicación muestra un formulario para introducir el nombre de

usuario y contraseña.

5. El usuario introduce en el cliente el nombre de usuario y contraseña.

6. El usuario pulsa el botón de enviar los datos.

7. El cliente envía la información al servidor.

8. El servidor valida que los datos sean correctos y envía al cliente que

los datos son correctos.

9. El cliente redirige al usuario a la página de administración.

Condiciones de salida: El usuario del sistema está identificado en el sistema.

Figura 11: Caso de uso de inicio de sesión



2.7.2 - Caso de Uso 2: Modificar datos del usuario


Condiciones de entrada: El usuario se ha logueado en el sistema.

Flujo de eventos:

1. El usuario accede a la página de preferencias.

2. El cliente solicita los datos del usuario al servidor.

3. El servidor devuelve al cliente los datos del usuario.

4. El cliente muestra al usuario los datos del usuario.

5. El usuario modifica alguno de los datos mostrados.

6. El usuario pulsa el botón guardar.

7. El cliente envía los datos introducidos al servidor.

8. El servidor almacena los datos recibidos.

Condiciones de salida: Los datos del usuario quedan modificados.

Figura 12: Caso de uso de modificar datos del usuario



2.7.3 - Caso de Uso 3: Subir mapa del hogar



Flujo de eventos:

1. El usuario accede a la página de preferencias.

2. El cliente solicita los datos del usuario al servidor.

3. El servidor devuelve al cliente los datos del usuario.

4. El cliente muestra al usuario los datos del usuario.

5. El usuario pulsa el botón de añadir archivo.

6. El usuario selecciona el plano de su hogar.

7. El usuario pulsa el botón guardar.

8. El cliente envía los datos introducidos al servidor.

9. El servidor almacena los datos recibidos.

Condiciones de salida: El plano del hogar se guarda correctamente.

Figura 13: Caso de uso de subir mapa del hogar



2.7.4 - Caso de Uso 4: Añadir elemento al plano del hogar



Flujo de eventos:

1. El usuario accede a la página de configuración.

2. El cliente solicita todos los elementos posicionados en el plano.

3. El servidor devuelve al cliente todos los elementos en el plano.

4. El cliente muestra al usuario los elementos en el mapa.

5. El usuario pulsa sobre el elemento que desea añadir.

6. El usuario arrastra el elemento hasta la posición deseada en el plano.

7. El usuario configura el nuevo elemento.

8. El cliente envía el nuevo elemento al servidor.

9. El servidor almacena el nuevo elemento.

Condiciones de salida: El elemento se almacena correctamente en el sistema.

Figura 14: Caso de uso de añadir elemento al plano del hogar



2.7.5 - Caso de Uso 5: Visualizar cámara disponible


Condiciones de entrada: El usuario se ha identificado en el sistema.

Flujo de eventos:

1. El usuario accede a la página de administración.




5. El usuario pulsa sobre el botón con el símbolo de un ojo que se

encuentra al lado del elemento de cámara.

6. El cliente solicita al servidor las imágenes de la cámara seleccionada.

7. El cliente muestra las imágenes de la cámara al usuario.

Condiciones de salida: Se muestran las imágenes de la cámara seleccionada.

Figura 15: Caso de uso de visualizar cámara disponible



2.7.6 - Caso de Uso 6: Cambiar estado de un elemento



Flujo de eventos:





5. El usuario pulsa sobre la imagen del elemento que quiere cambiar el

estado.

6. El cliente envía al servidor la información del elemento para cambiar el

estado.

7. El servidor cambia el estado del elemento seleccionado.

8. El cliente cambia la imagen del elemento que ha cambiado el estado.

Condiciones de salida: El elemento ha cambiado de estado.

Figura 16: Caso de uso de cambiar estado de elemento



2.7.7 - Caso de Uso 7: Ver estado general del hogar



Flujo de eventos:





Condiciones de salida: El cliente muestra todos los elementos con su estado actual.

Figura 17: Caso de uso de ver estado general del hogar



3 - Diseño

En este apartado se va a tratar todo lo relacionado con el diseño software. El

diseño se puede resumir muy brevemente como un conjunto de diagramas que

proporcionen los cimientos respecto a los que se va a desarrollar la aplicación.

En este apartado, se va a detallar el diagrama entidad-relación, el diagrama de

clases, diagramas de secuencia y el diseño de la interfaz.

3.1 - Diagrama Entidad-Relación

Un modelo Entidad-Relación (también denominado E-R por sus iniciales) es

una técnica de modelado de datos que permite representar las entidades más

importantes de un sistema y también representa las relaciones que hay entre dichas

entidades. Además del diagrama entidad-relación existe otro tipo de diagramas para

el modelado de datos, pero el diagrama E-R es el más usado y extendido.

El diagrama entidad-relación de la aplicación que se está desarrollando sería

el siguiente:

Figura 18: Diagrama entidad-relación

Como se puede observar, existe la entidad “Usuario” y la entidad “Elemento”,

estas dos entidades están relacionadas entre sí mediante una relación de muchos a

muchos, ya que un usuario puede configurar muchos elementos y un elemento puede

ser configurados por muchos usuarios. En la relación R1 existen unos atributos como



son “posX” “posY”, “estado” y “puertoGPIO”, estos atributos servirán para conocer la

posición del eje X e Y donde está posicionado el elemento, su estado y el puertoGPIO

al cual está conectado dicho elemento.

3.1.1 - Normalización

El proceso de normalización de una base de datos consiste en aplicar unas

reglas definidas a nuestro modelo relacional. Con la normalización conseguimos que

nuestra base de datos:

- No posea redundancia de datos.

- Disminuir problemas de actualización de los datos en las tablas.

- Proteger la integridad de los datos.

Antes de proceder a realizar la normalización, se deberá realizar un paso del

diagrama Entidad-Relación al modelo relacional, para ello, la relación R1 del diagrama

ER se convertirá en una tabla ya que es una relación muchos a muchos. Las entidades

“Usuario” y “Elemento” se convertirán a tablas sin más.

Figura 19: Modelo relacional



3.1.2 – Normalización de las tablas

Se puede decir que una base de datos está en N forma normal si todas sus

tablas están en N forma normal. Por lo general, una base de datos se considera que

está normalizada si se encuentra en tercera forma normal. El creador de las tres

primeras formas normales es Edgar F. Codd.

Las tres formas normales son:

- Primera forma normal (FN1): Se considera que una tabla está en

primera forma normal si todos sus atributos que no sean clave dependen

funcionalmente de la clave.

- Segunda forma normal (FN2): Se considera que una tabla está en

segunda forma normal si está en primera forma normal y todos los

atributos que no forma parte de ninguna clave dependen de forma

completa de la clave principal.

- Tercera forma normal (FN3): Se considera que una tabla está en tercera

forma normal si está en segunda forma normal y no existen atributos

que no sean clave que dependan transitivamente de la clave.

Por último, sólo queda comprobar que las tablas del esquema conceptual

modificado están normalizadas a tercera forma normal, como se puede observar, las

tres tablas existentes se encuentran en tercera forma normal ya que todos los atributos

no clave dependen funcionalmente de la clave, de forma completa y ningún atributo

no clave depende de otro atributo no clave.

3.2 - Diagrama de Clases

Un diagrama de clases es un tipo de diagrama perteneciente al Lenguaje

Unificado de Modelado (también conocido “UML” por sus siglas en inglés) que detalla

la estructura de un sistema software exponiendo las clases que existen en un sistema,

los atributos, métodos y las relaciones de cada clase. [12]



A continuación se muestra el diagrama de clases diseñado para el sistema que

se está desarrollando. Ya que nuestro sistema tiene una arquitectura cliente/servidor,

se ha dividido el diagrama en dos partes, un paquete correspondiente a la parte del

servidor y otro paquete correspondiente a la parte del cliente.

Figura 20: Diagrama de clases



En la parte del servidor, a través de los servicios REST, se puede acceder a las

clases “Usuario”, “Elemento” y “ElementoMapa”, éstas tres últimas clases están

relacionadas con sus respectivos DAOs que serán los encargados de gestionar todo

el acceso a la base de datos como puede ser el recuperar y guardar la información

En la parte del cliente, las clases “Usuarios”, “Preferencias” y “Elementos” serán

controladores en AngularJS, estos controladores estarán asociados a las vistas

(ficheros HTML) de esta forma, los controladores de las vistas podrán consumir los

servicios REST del servidor de forma que mejor convenga para el sistema



3.3 - Diagramas de secuencia

Un diagrama de secuencia se utiliza para mostrar la interacción de un

conjunto de objetos en un sistema software en una secuencia de tiempo, por lo tanto,

el diagrama tiene dos dimensiones, el eje X (dimensión vertical) representa el tiempo

y el eje Y (dimensión horizontal) representa los objetos. El diagrama de secuencia

resalta el ordenamiento de los mensajes en una interacción. Si hay mensajes entre

dos o más objetos significan que hay una interacción entre dichos objetos. [12]

3.3.1 - Diagramas de secuencia del sistema

En este apartado, se van a detallar los diagramas de secuencia más relevantes

del sistema. Las clases de color naranja serán las clases que están en el cliente,

mientras que las clases de color verde son las que están en el servidor.

- Diagrama de secuencia iniciar sesión:

Figura 21: Diagrama de secuencia iniciar sesión

En este diagrama, el usuario introducirá los datos en el navegador y la vista

enviará al controlador que se desea iniciar sesión. El controlador se comunicará con

el servicio REST correspondiente y se comprobará que los datos introducidos por el

usuario son correctos.



- Diagrama de secuencia modificar datos del usuario

Figura 22: Diagrama de secuencia modificar datos del usuario

El usuario realizará la petición de modificar los datos y enviará a la vista todos

los datos que desea actualizar, la vista enviará los datos a su controlador y el

controlador realizará la petición al servicio REST correspondiente, por último, se

actualizarán los datos del usuario.

- Diagrama de secuencia subir mapa del hogar

Figura 23: Diagrama de secuencia subir mapa del hogar

El usuario enviará la petición de subir un nuevo mapa a la vista, el controlador realizará

la petición al servicio REST correspondiente y seguidamente, se descargará el mapa

en el servidor y se almacenará.



- Diagrama de secuencia añadir elemento al mapa

Figura 24: Diagrama de secuencia añadir elemento al mapa

El usuario realizará la petición de añadir un nuevo elemento al mapa, los datos

del elemento que quiere añadir se enviará al controlador de la vista y éste realizará la

correspondiente petición REST, el servicio realizará la petición a la clase

“elementoMapa” de que quiere crear un nuevo elemento y ésta lo creará.

- Diagrama de secuencia cambiar estado de un elemento

Figura 25: Diagrama de secuencia cambiar estado de un elemento

El usuario pulsará sobre un elemento que esté posicionado en el mapa y la

vista enviará al controlador el id del elemento que se quiere cambiar de estado, el

controlador realizará la petición REST para cambiar el estado enviándole el id del

elemento y el servicio enviará la petición a la clase “elementoMapa”.



- Diagrama de secuencia visualizar estado general del hogar

Figura 26: Diagrama de secuencia visualizar estado general del hogar

El usuario realizará la petición de ver el estado general del hogar y la vista

realizará la petición a su controlador, el controlador conectará con el servicio REST

correspondiente y el servicio realizará la petición a la clase “elementoMapa”.

3.4 - Diseño de la Interfaz

En este apartado, se va a definir el aspecto visual de la interfaz del cliente ya

que la parte del servidor no tendrá ninguna interfaz ya que el servidor solo almacenará

la información y atenderá peticiones REST para devolver toda la información al cliente.

Mediante el diseño de la interfaz se intenta conseguir una interfaz aproximada

de lo que será la futura interfaz del cliente del sistema. Con estos diseños no quieren

decir que sea la interfaz final de la aplicación ya que solamente servirá para dar una

idea de lo será el sistema.

En este caso, he optado por realizar el diseño de la interfaz a través de

wireframe ya que a través de éstos se muestra claramente los grupos principales de

contenido, la estructura de la información y una visualización básica de la interacción

del usuario.



- Ventana para iniciar sesión

Figura 26: Interfaz ventana para iniciar sesión

En esta ventana, el usuario tendrá que escribir su dirección de correo

electrónico y contraseña para poder acceder al sistema, si introduce todos los datos

correctamente, el sistema lo redirigirá a la ventana de administración, si por el

contrario introduce los datos incorrectamente, el sistema volverá a cargar la misma

ventana para que el usuario vuelva a introducir sus datos de acceso.

- Ventana de administración

Figura 27: Interfaz ventana de administración



Una vez que el usuario haya iniciado sesión correctamente, el sistema lo

redirigirá a esta ventana. En esta ventana, el usuario tendrá una visual de todo su

hogar y podrá ver el estado de todos los elementos que tenga instalados en el sistema

de un vistazo.

En esta ventana, el usuario también podrá cambiar el estado de los elementos,

como por ejemplo apagar una bombilla, para ello, solamente tendrá que hacer click

sobre el elemento que desea modificar.

- Ventana para modificar elementos

Figura 28: Interfaz modificar elementos

En esta ventana, el usuario podrá modificar el lugar donde se encuentran los

elementos ya existentes en el sistema, para realizar esta operación, el usuario debe

de pulsar sobre el elemento y sin soltar el botón del ratón, arrastra el elemento hacia

la posición deseada.

Si el usuario desea añadir un nuevo elemento al sistema, solamente tendrá que

pulsar sobre el elemento que desea añadir y están disponibles en la barra de menú

izquierda, una vez pulsado sobre el elemento deseado, le aparecerá la imagen del

elemento en el plano y solamente tendrá que modificar el lugar y colocarla sobre el

lugar deseado.



- Ventana de preferencias

Figura 29: Interfaz preferencias

En esta ventana, el usuario podrá visualizar todos sus datos relacionados

como puede ser el nombre, apellidos, email, etc.

4.- Implementación

La fase de implementación la podemos considerar como la fase final de la

ingeniería del software, es decir, es la fase en la cual a partir de todo lo obtenido en

las fases anteriores se transforma a código fuente.

En el caso del sistema que se está desarrollando, se realizará a través de una

arquitectura cliente/servidor. El funcionamiento de este tipo de arquitectura es el

siguiente: la aplicación se encontrará en un servidor centralizado, los usuarios

accederán a la aplicación a través de un cliente, en el caso de este sistema, el cliente

será una aplicación web, la cual consumirá servicios REST para comunicarse con el

servidor.



Figura 30: Arquitectura cliente-servidor

La arquitectura cliente-servidor tiene numerosas ventajas como pueden ser:

- Fácil mantenimiento: Al estar las funciones distribuidas y no están

centralizadas en un solo equipo, es mucho más sencillo actualizar o reparar

el servidor sin que los clientes se vean afectados en el proceso.

- Centralización del control: El servidor es el encargado de controlar los

accesos o la integridad de datos, de esta forma, si hay algún cliente

defectuoso no puede dañar el sistema.

- Escalabilidad: En cualquier momento se puede aumentar la capacidad

tanto de clientes como de servidores de forma separada.



4.1 - Arquitectura

Para el diseño arquitectónico, se va a realizar un diagrama de componentes en

el que se muestren todos los elementos constituyentes en el sistema y la relación que

hay entre ellos.

En un diagrama de componentes se muestra la organización y las

dependencias que existen en un conjunto de componentes. Un diagrama de

componentes puede considerarse como un diagrama de clases el cual se centra en

los componentes físicos del sistema. [12]

A continuación se muestra el diagrama de componentes del sistema que se ha

desarrollado:

Figura 31: Diagrama de componentes

En este diagrama, se tendrá tres paquetes, los cuales son “Aplicación Web”,

“Servidor” y “Base de datos”, en el paquete “Aplicación Web” se tendrán los



componentes necesarios para su correcto funcionamiento, éstos son “Interfaz de

usuario” y “AngularJS”, en la interfaz de usuario estará el código HTML y JavaScript

mientras que el paquete “AngularJS” será el encargado de comunicarse con el

servidor.

En el paquete “Servidor” estarán los componentes “Datos Json” y “Spark”, el

componente “Datos Json” será el encargado de convertir toda la información a Json

para que AngularJS lo pueda interpretar y el componente “Spark” será el encargado

de gestionar los servicios REST, este componente está relacionado con el paquete

“Base de datos”.

Por último, el paquete “Base de datos” será el encargado de gestionar toda la

información en la base de datos.

4.2 - Detalles sobre implementación

Uno de los detalles más importantes sobre la implementación en este sistema

es el uso de un framework web específico para el desarrollo de los servicios REST. El

framework elegido para dicha función ha sido “Spark Framework” [13]. Se ha decidido

elegir este framework ya que es muy ligero y como el servidor será una raspberry PI2

[14] la cual no tiene un hardware demasiado potente, se ha pensado que es el

framework ideal para este proyecto. Spark Framework es un framework web inspirado

en el framework Sinatra [15] aunque la intención de Spark no es competir con Sinatra,

su principal intención es proporcionar a los desarrolladores una alternativa

desarrollada puramente en Java. La versión que se ha utilizado de Spark framework

ha sido la 2.2.

Spark framework es un simple y ligero framework web basado en Java para un

rápido desarrollo. La intención de Spark no es competir con Sinatra o la docena de

framework web similares en diferentes lenguajes pero proporciona una alternativa en

Java para los desarrolladores que lo deseen. Spark se centra en ser tan simple y

directo como sea posible, sin necesidad de engorrosos ficheros de configuración, para

permitir el desarrollo de aplicaciones web de forma rápida en Java. [13]



Ya que Spark framework es ligero, he decidido usarlo en mi propuesta ya que

los requerimientos de la raspberry PI 2 no son muy altos para ejecutar un framework

web más potente.

Spark incluye por defecto el servidor de aplicaciones Jetty de manera que las

aplicaciones web creadas con Spark pueden lanzarse como cualquier programa Java.

Adicionalmente, las aplicaciones pueden configurarse para ser instaladas bajo otros

servidores como por ejemplo Apache Tomcat.

Sobre la elección de motor de base de datos, se ha optado por MySQL [16], ya

que al igual que Spark framework, es un motor de base de datos relacional liviano

aunque bastante potente. Como no se va a albergar demasiada información en la base

de datos, es una opción bastante interesante para este proyecto. La versión que se

ha utilizado de MySQL ha sido la 5.7.9.

A continuación, se podrá ver una tabla con todos los recursos REST que

estarán disponibles en el servidor:

URL Método Parámetros Descripción

/nuevoUsuario POST Usuario

Crea un nuevo

usuario en el

sistema.

/actualizaUsuario POST

email,

contraseña,

nombre, apellidos

Actualiza la

información de un

usuario.

/buscaTodosUsuarios GET -

Devuelve un

fichero json con

todos los usuarios

del sistema.

/buscaUsuario GET id

Devuelve un

fichero json con el

usuario asociado

al id del sistema.



/borraUsuario GET id

Borra un usuario

con el id

asociado.

/loguearse POST email, contraseña

Comprueba que

los datos de

acceso son

correctos.

/cerrarSesion GET .

Elimina la sesión

creada en el

sistema.

/email GET -

Devuelve el email

del usuario que

está logueado.

/nuevoElemento POST Elemento

Crea un nuevo

elemento para

que esté

disponible para el

usuario.

/nuevoElementoMapa POST

id, posX, posY,

estado,

puertoGPIO,

id_elemento

Crea un nuevo

elemento en el

plano del hogar

del usuario.

/nuevoElementoMapa POST id, puertoGPIO

Modifica el

puertoGPIO de un

elemento con un

id determinado.

/buscaTodosElementosMapa GET -

Devuelve un

fichero json con

todos los

elementos

existentes en el

plano.

/elementoMapa GET id

Devuelve todos

los datos de un

elemento



existente en el

plano.

/elemento GET Id

Devuelve la

información de un

elemento con un

id determinado.

/elementoMapa/eliminar POST Id

Elimina un

elemento del

plano con un id

determinado.

/elementoMapa/modificar POST

id, posX, posY,

estado,

puertoGPIO,

id_elemento

Modifica un

elemento del

plano con un id

determinado.

En la parte del cliente, se ha desarrollado una aplicación web usando

únicamente HTML5, CSS y AngularJS. La decisión de esta elección ha sido para

poder más adelante portar el cliente a una aplicación móvil a través de “Apache

Cordova”, Cordova es un framework que nos permite convertir una aplicación web que

esté desarrollada en HTML, CSS y JavaScript en una aplicación móvil ya sea Android,

IOS o Windows Phone.

AngularJS es un framework de JavaScript escrito en código abierto. El principal

objetivo de angularJS es crear aplicaciones basadas en el cliente apoyándose del

Modelo Vista Controlador (MVC) [17]

AngujarJS será el encargado de consumir todos los servicios REST disponibles

en el servidor, la versión utilizada de AngularJS ha sido la 1.4.3.

A continuación se mostrará un ejemplo interacción entre AngularJS y un

servicio REST del servidor.



La parte del código de la parte de la vista sería la siguiente:

Figura 32: Fragmento código de la vista

Este fragmento de código pertenece a una ventana modal que se mostrará al

modificar los datos de un elemento que está posicionado en el plano. Como se puede

observar, aparece un enlace para eliminar un elemento, si pulsamos sobre él,

angularJS llamará a “eliminarElemento()” enviándole como parámetro el id del

elemento.

A continuación se muestra la función “eliminarElemento”:

Figura 33: Función eliminarElemento de angularJS

Como se puede observar, angular realizará una petición al recurso REST

creando la URL del recurso (urlServidor/elementoMapa/id/eliminar), el recurso será el

encargado de eliminar dicho elemento.



4.2.1 - Detalle de implementación de recurso REST

En este apartado se explicará un ejemplo de un recurso REST que se ha

implementado para mostrar cómo se define un servicio en Spark.

Figura 34: Recurso REST implementado

Como se puede observar, este recurso se utiliza para conseguir toda la

información relacionada con un elemento que está posicionado en el plano del hogar

a partir de un id determinado. El recurso accederá a la base de datos y buscará dicho

elemento. Este recurso se utilizaría de la siguiente manera:

http://urlServidor/elementoMapa/1, el recurso devolvería toda la información del

elemento en formato JSON.

Por último, se mostrará un ejemplo de cómo se accede a los puertos GPIO para

la lectura/escritura desde código. Para ello se ha utilizado una librería adaptada para

Java para poder controlar todos los puertos GPIO. La librería que se ha utilizado es

“Pi4j” y facilita bastante el uso de los puertos GPIO de la Raspberry.

A continuación se podrá ver un ejemplo del uso de los puertos GPIO:

http://urlservidor/elementoMapa/1



Figura 35: Uso puertos GPIO

Como se puede observar, se puede comprobar el estado del puerto con

“getState()” y podemos cambiar el estado con “toggle()” para alimentar por dicho

puerto 5V y “low()”.



4.2.2 – Ejemplo raspberry en funcionamiento

En este apartado, se va a mostrar la instalación de la raspberry con algunos

elementos conectados y se explicará el funcionamiento a través de la aplicación.

Seguidamente se observa una imagen de la raspberry con todos los elementos:

Figura 36: Raspberry PI 2 con elementos conectados

Como podemos observar, todas las bombillas están apagadas, el sensor de

temperatura está funcionando y la cámara también está encendida, todo esto lo

podemos observar en la aplicación del cliente:



Figura 37: Aplicación cliente con elementos ejemplo

Si cambiamos desde la aplicación del cliente, algunos estados de los elementos

que tenemos en el plano de nuestro hogar, podemos observar, como realmente

cambian:

Figura 38: Raspberry PI 2 con algunos elementos encendidos



En esta imagen, podemos ver cómo están encendidas tres bombillas y una está

apagada, podemos contrastarlo con la aplicación del cliente:

Figura 39: Aplicación cliente con elementos encendidos

En la imagen anterior, también podemos observar como el sensor de

temperatura nos está arrojando una temperatura de 23ºC.

Por último, antes se ha comentado que la cámara también estaba encendida,

si pulsamos sobre el icono azul que está al lado de la cámara, se podrá ver lo que la

cámara está grabando:

Figura 40: Aplicación cliente cámara grabando



4.3 - Pruebas

En este apartado, se explicará las pruebas que he realizado para comprobar

que el sistema funciona según lo esperado, gracias a estas pruebas se intentará

conseguir un sistema sin errores y se garantiza un software de calidad.

Las pruebas que se han realizado son las siguientes:

1. Autentificación del usuario correcta

Pr01

Acción Un usuario introduce su dirección de email y contraseña en la

ventana de identificación

Resultado El sistema redirige al usuario a la ventana de administración

2. Autentificación del usuario incorrecta

Pr02

Acción Un usuario introduce su dirección de email y contraseña en la

ventana de identificación

Resultado El sistema muestra un mensaje de error al usuario

3. Cambiar estado de un elemento posicionado en el plano

Pr03

Acción Un usuario accede a la parte de administración y hace clic sobre un

elemento posicionado en el mapa

Resultado El elemento sobre el que se ha hecho clic el estado de éste cambia,

es decir, si está encendido se apagará y viceversa.



4. Modificar la posición de un elemento posicionado en el plano

Pr04

Acción Un usuario accede a la parte de modificación, arrastra un elemento

posicionado en el plano al lugar donde desee

Resultado El elemento cambia su posición hasta donde el usuario ha soltado

el botón izquierdo del ratón

5. Eliminar un elemento posicionado en el plano

Pr05

Acción Un usuario accede a la parte de modificación, hace doble clic sobre

el elemento que desea eliminar y pulsa el botón “Eliminar”

Resultado El elemento se elimina del plano

6. Añadir un elemento al plano

Pr06

Acción Un usuario accede a la parte de modificación y hace clic sobre el

elemento que desea añadir de la lista de elementos disponibles

Resultado El elemento aparece en la esquina superior izquierda del plano

7. Cambiar el puerto GPIO de un elemento posicionado en el plano

Pr07

Acción Un usuario accede a la parte de modificación, hace doble clic sobre

el elemento que quiere cambiar su puerto GPIO y en la ventana

modal que aparece selecciona el puerto

Resultado El puerto GPIO del elemento cambia

8. Visualizar la imagen de una cámara añadida en el plano

Pr07

Acción Un usuario accede a la parte de administración y pulsa sobre el

icono que aparece al lado del elemento de la cámara

Resultado Se abre una ventana modal con la imagen de la cámara



Las pruebas anteriores se han realizado una vez que la implementación del

sistema ha finalizado. Estas pruebas han sido de gran utilidad para detectar algunos

problemas que tenía el sistema, como por ejemplo la prueba número 7, cuando se

finalizó el sistema se pensaba que funcionaba correctamente el cambio de puerto

GPIO y a la hora de ejecutar la prueba se detectó un error de implementación ya que

en todos los casos no se realizaba el cambio correctamente.



5.- Conclusiones

La domótica es una tecnología que como se ha podido ver a lo largo de todo

este documento se está extendiendo de forma muy rápida a muchos hogares. El

sistema que se ha desarrollado en este trabajo es una forma de utilizar la domótica de

forma sencilla e intuitiva, además de conseguirlo de una forma bastante económica.

En el apartado 1.2 de este documento, se definieron unos objetivos que el

sistema debía cumplir una vez estuviese finalizado. Con los resultados obtenidos,

podemos concluir que dicho sistema ha alcanzado estos objetivos, ya que al haber

dividido el sistema en una arquitectura cliente-servidor, se ha dividido el objetivo de

crear una aplicación web a la parte del cliente y el objetivo de crear servicios REST

para el manejo de los elementos a la parte del servidor.

La metodología elegida para este proyecto, Scrum, ha facilitado bastante el

desarrollo del proyecto ya que se ha dividido toda la planificación del proyecto en

sprints y de esta forma se ha podido realizar el proyecto de forma iterativa. Una

desventaja de haber utilizado Scrum es que este proyecto no ha sido realizado por un

grupo de personas o equipo si no que ha sido realizado por una sola persona, por lo

que esta forma de trabajar no se asemeja a lo que Scrum propone.

Los aspectos más relevantes de este proyecto podría ser la de crear un sistema

domótico en un hogar cualquiera de forma sencilla y barata, además de que al haber

orientado este proyecto a una arquitectura cliente-servidor, una persona podría crear

un cliente totalmente diferente al propuesto de forma muy sencilla, utilizando los

servicios REST implementados en el servidor. Otro aspecto relevante podría ser el

que todo el sistema esté alojado en una Raspberry ya que al ser de tamaño reducido

se podría alojar en casi cualquier lugar del hogar sin ser éste un gran problema.

Como reflexión final, este proyecto me ha aportado una gran experiencia, ya

que nunca había utilizado AngularJS, y gracias a la realización de este proyecto, he

podido desarrollar una aplicación alojada en el cliente viendo que utilizar AngularJS

respecto a usar JavaScript tiene bastantes ventajas como puede ser la gran

comunidad que tiene detrás o la calidad del software implementado con AngularJS.



Bibliografía

[1] H. M. Domínguez y F. Sáez Vacas, Domótica: Un enfoque sociotécnico, Madrid:

Fundación Rogelio Segovia para el Desarrollo de las Telecomunicaiones, 2006.

[2] P. Puello Marrugo, A. Cabarcas Álvarez y J. Rodríguez Ribón, «SCRUM:

CONCEPTOS Y APLICACIONES OPEN SOURCE,» REVISTA VIRTUAL DE LOS

PROGRAMAS DE INGENIERÍA, vol. 2, nº 3, pp. 10-21, 2011.

[3] R. S. Pressman, INGENIERIA DE SOFTWARE, Madrid: McGraw-Hill, 2010.

[4] F. Sáez Vacas y H. Martín Dominguez, Domótica: Un enfoque sociotécnico, Madrid:

Fundación Rogelio Segovia para el Desarrollo de las Telecomunicaciones, 2006.

[5] A. García García, C. Morón Fernandez, E. Tremps Guerra, M. López Zambrano, J.

Somolinos Sánchez y M. González Redondo, CONTROL AUTOMÁTIZADO DE

INSTALACIONES DOMÓTICAS, Madrid.

[6] M. Moro Vallina, Instalaciones Domóticas, Madrid: Paraninfo, 2011.

[7] FreeDomotic, «FreeDomotic,» [En línea]. Available: http://freedomotic.com/.

[8] P. -. O. S. domotica, «PiDome - Open Source domotica,» [En línea]. Available:

http://pidome.bitbucket.org/.

[9] «Blog de la historia de la informática,» Universidad Politécnica de Valencia, 18

Diciembre 2013. [En línea]. Available: http://histinf.blogs.upv.es/2013/12/18/raspberry-

pi.

[10] B. W. NIEBEL y A. Freivalds, Métodos, estándares y diseño del trabajo, México:

McGraw Hill, 2009.

[11] B. O. D. ESTADO, «MINISTERIO DE EMPLEO Y SEGURIDAD SOCIAL,» BOE, vol. 3,

nº 224, pp. 82756-82761, 2015.

[12] M. Fowler, UML Distilled. A Brief Guide to the standard object modeling language,

Boston: Object Tecnology, 2004.

[13] S. Framework, «Spark Framework,» [En línea]. Available: http://sparkjava.com/.

[14] «Raspberry,» [En línea]. Available: https://www.raspberrypi.org/products/raspberry-pi-2-

model-b/.

[15] Sinatra, «Sinatra,» [En línea]. Available: http://www.sinatrarb.com/.

[16] «MySQL,» [En línea]. Available: https://www.mysql.com/.



[17] B. Green y S. Seshadri, AngularJS, Sebastopol: O'Reilly Media, 2013.

[18] M. F. Krafft, The Debian System - Concepts and Techniques, Open Source Press.

[19] «Raspberry,» [En línea]. Available: http://www.raspberrypi.org/downloads/.

[20] R. E. SILVERMAN, D. J. BARRETT y R. G. BYRNES , SSH, THE SECURE SHELL:

THE DEFINITIVE GUIDE, O REILLY & ASSOCIATES, 2005.

[21] J. G. Velasco, Energías renovables, Editorial Reverte, 2009.

[22] Y. Benkler, El Pingüino y el Leviatán: Por qué la cooperación es nuestra arma más

valiosa para mejorar el bienestar de la sociedad, 2012.

[23] I. D. C. LEON, «DOMÓTICA E INMÓTICA: VIVIENDAS Y EDIFICIOS

INTELIGENTES,» 2011. [En línea]. Available:

http://cdigital.uv.mx/bitstream/123456789/32912/1/constantinoleon.pdf.

[24] B. W. NIEBEL y A. Freivalds, Métodos, estándares y diseño del trabajo, México:

McGraw Hill, 2009.

[25] «Spark,» [En línea]. Available: http://sparkjava.com/.



Anexo A. Manual de instalación

En este apartado se va a explicar cómo instalar el sistema desde cero para

conseguir que dicho sistema funcione correctamente.

Ya que el sistema que se ha desarrollado está basado en una arquitectura

cliente-servidor y se han implementado ambas partes, primero se detallará la

instalación en el servidor y seguidamente en el cliente.

Instalación del servidor

El servidor como ya se ha hablado en este documento, será una Raspberry PI

2, antes de realizar nada, supondremos que no se ha instalado ningún sistema

operativo en la Raspberry, por lo que lo primero que se va a mostrar, será la instalación

del sistema operativo.

1. Instalación del sistema operativo

Como sistema operativo he elegido Raspbian ya que está basado en Debian

[18] y optimizado para su uso en Raspberry.

Para realizar esta tarea, necesitaremos un monitor o televisión con entrada

HDMI, una tarjeta microSD de unos 8GB, un teclado y un ratón.

Nos descargamos la imagen del sistema operativo desde la página oficial de

Raspberry [19], una vez que se haya descargado, extraemos todo el contenido a la

raíz de la microSD, seguidamente, la introducimos en la Raspberry conectada al

teclado, ratón y televisión o monitor.



Nos arrancará con la siguiente ventana:

Figura 41: Ventana inicio instalación del sistema operativo en raspberry PI 2

Cuando haya cargado, nos aparecerá la siguiente ventana:

Figura 42: Selección del sistema operativo a instalar



En esta ventana, seleccionaremos “Raspbian” y nos aparecerá lo siguiente:

Figura 43: Ventana de confirmación de instalación del sistema operativo

Este mensaje nos está avisando de que se instalará el sistema operativo que

se ha seleccionado y que todos los datos que existan en la tarjeta SD serán

sobreescritos. Pulsamos sobre “Yes” y empezará la instalación.

Figura 44: Ventana de proceso de instalación del sistema operativo



Una vez que el porcentaje de la barra de estado llegue al 100%, nos aparecerá

el siguiente aviso:

Figura 45: Ventana confirmación sistema operativo instalado

Pulsamos sobre “OK”, la Raspberry se reiniciará e iniciará el sistema operativo.

El usuario con permisos de root es “pi” y su contraseña “raspberry”

2. Instalación de SSH

Para poder prescindir del televisor o monitor, teclado y ratón, se va a proceder

a la instalación de SSH [20] y así poder realizar toda la instalación a través de un

ordenador conectado a Raspberry a través de SSH.

Una vez que se ha iniciado el sistema operativo y hemos accedido con el

usuario “pi” y contraseña “raspberry” introduciremos los siguientes comandos:

- Instalación de SSH

sudo apt-get install ssh

- Iniciar el servicio SSH

sudo /etc/init.d/ssh start

- Para que se ejecute al iniciar la Raspberry

sudo update-rc.d ssh defaults



3. Instalación de Java 1.8

Ya que la aplicación está desarrollada en java, es necesario instalar Java en el

servidor, para ello iniciamos sesión a través de SSH e introducimos los siguientes

comandos:

- Añadimos los repositorios

echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty

main" | tee /etc/apt/sources.list.d/webupd8team-java.list

echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu

trusty main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list

- Añadimos las keys

apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys

EEA14886

- Actualizamos los repositorios

apt-get update

- Instalamos Java

apt-get install oracle-java8-installer

4. Instalación de Apache y MySQL

Ya que el cliente web se va a alojar en la Raspberry, es necesario tener un

servidor Web, se ha optado por Apache. Para instalar Apache, se ejecutarán los

siguientes comandos:

- Instalamos apache

sudo apt-get install apache2 apache2-doc apache2-utils

- Instalamos librerías para soporte PHP

apt-get install libapache2-mod-php5 php5 php-pear php5-xcache

- Instalamos el soporte de conectividad con mysql

apt-get install php5-mysql

Ya que la base de datos va a ser albergada en la Raspberry, necesitamos

instalar el gestor de base de datos. Para ello, ejecutamos los siguientes comandos:

- Actualizamos los repositorios

sudo apt-get update && sudo apt-get upgrade



- Instalamos MySQL

sudo apt-get install mysql-server --fix-missing

Nos saldrá la siguiente ventana:

Figura 46: Ventana para introducir la clave de root para MySQL

Introducimos la contraseña para el usuario “root” y pulsamos enter, después

nos saldrá otra ventana para volver a introducir la contraseña.

- Instalamos el cliente de MySQL

sudo apt-get install mysql-client



5. Instalación de FTP

La aplicación será enviada a la Raspberry a través de FTP, para ello,

necesitamos instalar un servidor de FTP en la Raspberry. Para realizar esta operación,

introducimos los siguientes comandos:

- Instalamos FTP

sudo apt-get install vsftpd

6. Ejecutar la aplicación en la Raspberry

Una vez que ya hemos copiado la aplicación en la Raspberry a través de FTP,

la ejecutaremos con el siguiente comando:

sudo java -jar domotic-1.0-SNAPSHOT-jar-with-dependencies.jar

Instalación del cliente

El cliente del sistema será una aplicación web y estará alojada en la Raspberry,

para instalar el cliente solo bastará con copiar por FTP toda la carpeta de la aplicación

web al directorio “/var/www” de la Raspberry, suponemos que la carpeta se llamará

“Domotic”

Una vez copiado todo el contenido y para comprobar que funciona

correctamente, accedemos a través del navegador a la siguiente URL:

http://direccionIPRaspberry/Domotic

http://direccionipraspberry/Domotic



Anexo B. Manual de usuario

A través de este manual, se va a describir cómo usar toda la funcionalidad del

sistema para realizar un uso correcto con ella. Para que este manual sea más legible,

se seguirá un orden desde las operaciones más usadas a las operaciones menos

usadas.

Identificación

El usuario accederá al sistema a través de una dirección de correo y una

contraseña, si los datos de acceso son correctos, el sistema redirigirá al usuario a la

ventana de administración, si por el contrario, algún dato es incorrecto, mostrará un

mensaje de error.

La ventana de identificación es la siguiente:

Figura 47: Ventana identificación



Si el usuario introduce una dirección de email incorrecta, se mostrará la

siguiente ventana:

Figura 48: Ventana email incorrecto

Si el usuario introduce un email correcto pero una contraseña incorrecta, se

mostrará el siguiente mensaje de error:

Figura 49: Ventana contraseña incorrecta

Vista general del hogar

Una vez que el usuario se ha identificado correctamente, el sistema le redirigirá

a la ventana de administración, en esta ventana podrá ver una visión general de todo

su hogar, donde están los elementos y en qué estado están. La ventana de

administración será la siguiente:



Figura 50: Ventana de administración

Como se puede observar, en este hogar hay una cámara que está encendida,

una lámpara que está encendida, un enchufe que está apagado y un radiador que

está encendido. De esta forma, el usuario de un simple vistazo, puede comprobar el

estado de todos los elementos de forma rápida y sencilla.

Cambiar el estado de un elemento del plano

Una vez que el usuario está en la ventana de administración, y desea cambiar

el estado de uno de los elementos, solamente tendrá que hacer clic sobre el elemento

que desea cambiar su estado. Por ejemplo, imaginemos que estamos en la situación

de la imagen anterior y el usuario desea apagar la cámara, para ello, el usuario hará

clic sobre el icono de la cámara y ésta se apagará.



Figura 51: Ventana de administración



Añadir un nuevo elemento al plano

Para añadir un nuevo elemento al plano, el usuario tendrá que acceder al

apartado “Modificar elementos”, una vez que acceda a dicho apartado, se desplegará

una lista de todos los elementos que están disponibles, como se puede apreciar en la

siguiente imagen:

Figura 52: Menú añadir elemento

Seguidamente, el usuario hará clic sobre el elemento que desea añadir,

supongamos que es una televisión, una vez que haga clic sobre “Televisión”, el icono

del nuevo elemento aparecerá en la esquina superior izquierda, como se puede ver

en la siguiente imagen:



Figura 53: Nuevo elemento añadido

Mover un elemento situado en el plano

Hay ocasiones en las cuales se mueve un elemento de lugar, cuando sucede

esto, también es necesario moverlo en el sistema, para ello, el usuario accederá a la

parte de “Modificar elementos” y dejará pulsado el botón izquierdo del ratón sobre el

elemento que desea mover, lo arrastrará y soltará el botón izquierdo del ratón cuando

el elemento se encuentre en la posición deseada por el usuario. Imaginemos que el

elemento que hemos añadido anteriormente (el de la televisión) lo queremos mover a

donde se encuentra realmente la televisión, realizamos la operación antes descrita y

quedará algo como la siguiente imagen:



Figura 54: Mover elemento de posición



Eliminar un elemento del plano

Cuando el usuario desea eliminar un elemento que está situado en el plano, es

decir, está operativo, accederá a la parte “Modificar elementos” y hará doble clic sobre

el elemento que desea eliminar, aparecerá la siguiente imagen:

Figura 55: Ventana modal para eliminar elemento

Como se puede observar, aparece un botón en rojo con el texto “Eliminar

elemento”, el usuario pulsará sobre dicho botón y el elemento quedará eliminado.

Imaginemos que el usuario quería eliminar la lámpara que aparecía anteriormente, el

estado del hogar quedaría así:



Figura 56: Elemento eliminado

Cambiar el puerto GPIO de un elemento

Un usuario tendrá que seleccionar que puerto GPIO de la Raspberry controla

un elemento, por ejemplo, el radiador está conectado al puerto 03 de la Raspberry,

por lo que el usuario tendrá que especificar que ese elemento está conectado al puerto

03, para realizar esta operación, el usuario accederá a la parte “Modificar elemento”,

hará doble clic sobre el elemento que quiere cambiar el puerto GPIO y aparecerá la

siguiente ventana:



Figura 57: Ventana modal cambiar puerto GPIO

Como se puede observar, hay un apartado para seleccionar el puerto,

desplegará la lista haciendo clic sobre ella y aparecerá todos los puertos de la

Raspberry, seleccionará el deseado y el puerto se cambiará.

Ver los datos del usuario

Para visualizar los datos del usuario con el que se ha identificado en el sistema,

se pulsará sobre la opción “Preferencias” y aparecerá toda la información relacionada

con dicho usuario:



Figura 57: Ventana preferencias

Como se puede ver en la imagen anterior, se pueden visualizar datos como el

nombre, apellidos, nombre de usuario, email y contraseña.

Modificar los datos del usuario

Para modificar los datos del usuario, como puede ser el nombre, apellidos,

contraseña o el plano del hogar, el usuario accederá a la parte “Preferencias”,

modificará los datos que se desee y se pulsará sobre el botón “Actualizar”.

Cerrar sesión

Cuando el usuario desee cerrar la sesión de la aplicación, solo se debe pulsar

el botón “Cerrar sesión” situado en el menú de la izquierda, el sistema cerrará la sesión

y redirigirá a la ventana de identificación.



Anexo C. Descripción de contenido suministrado

Todo el contenido sobre este proyecto estará almacenado en un CD. El

contenido del CD será el siguiente:

- Memoria.

- Código fuente:

Carpeta “ClienteDomotic”: Esta carpeta almacenará todo el

código fuente relacionado con la aplicación cliente de la

aplicación.

Carpeta “ServidorDomotic”: Esta carpeta almacenará todo el

código fuente relacionado con la aplicación servidor de la

aplicación.

- Ejecutable: En la carpeta “Ejecutable” se podrá encontrar el fichero .jar

de la aplicación servidor.

- Video de funcionamiento: Se incluirá un video de la aplicación en

funcionamiento.

Índice - ujaen.estauja.ujaen.es/bitstream/10953.1/7996/1/Documentacion.pdf · Antonio Gómez...

Documents

Transcript of Índice - ujaen.estauja.ujaen.es/bitstream/10953.1/7996/1/Documentacion.pdf · Antonio Gómez...