Desarrollo de un sistema para la alimentación automática de aves rapaces

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Desarrollo de un sistema para la alimentaci´ on autom´ atica de aves rapaces Autor: D. David de la Varga del Ca˜no Tutores: Dr. Diego R. Llanos Ferraris D. Guillermo Vicente Oliva 2 Resumen El siguiente Trabajo Fin de Grado consiste en el desarrollo de un prototipo para la alimentaci´on autom´atica de aves rapaces. El prop´osito que se plantea: el due˜no de un ave rapaz ser´a capaz de alimentar a su animal desde cualquier lugar, para lo que es necesario un sistema que sirva de control y el prototipo que ser´a controlado, el prototipo ser´a fabricado. De este modo el cetrero que as´ı es como se denomina al due˜no de un ave rapaz, pueda utilizar tanto el sistema de control, a trav´es de una p´agina web, como el comedero f´ısico para mantener atendidas las necesidades alimenticias de su ave. Se cubrir´an las necesidades de alimentar al animal en un instante previamente establecido o en un momento decidido por el cetrero. Adem´as, se mantendr´a la informaci´on m´as relevante de cada comedero. 3 4 Abstract 5 6 ´ Indice general 1. Introducci´on 15 1.1. Contextoymotivaci´on ................................. 15 1.2. Objetivosyalcance................................... 15 1.3. Explicaci´on del escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2. An´alisis de requisitos 17 2.1. Definici´on de los actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1. Administrador.................................. 17 2.1.2. Usuario ..................................... 17 2.1.3. UsuarioExterno................................. 17 2.2. Requisitosfuncionales ................................. 17 2.3. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4. Reglasdenegocio.................................... 18 2.5. Requisitos de informaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3. Plan de proyecto 19 3.1. Prop´osito, alcance y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Artefactosdeproyecto ................................. 19 3.3. Plandetrabajo..................................... 19 3.3.1. DiagramasdeGantt .............................. 23 3.4. Presupuesto....................................... 26 3.4.1. Proyectosoftware................................ 26 3.4.2. ProyectoIoT .................................. 26 3.4.3. Total....................................... 26 4. Modelo de An´alisis 27 4.1. Casosdeusodelsistema................................ 27 4.1.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.2. Casos de Uso del actor Administrador . . . . . . . . . . . . . . . . . . . . 29 4.1.3. Casos de Uso del actor Usuario . . . . . . . . . . . . . . . . . . . . . . . . 30 4.1.4. Casos de uso del actor Usuario Externo . . . . . . . . . . . . . . . . . . . . 37 4.2. Modelodedominio ................................... 38 4.3. Modelodedatos..................................... 38 5. Dise˜no 39 5.1. Arquitecturadelsistema................................ 39 5.2. Interfazdeusuario ................................... 41 5.3. Modelo de dominio en dise˜no . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.4. Modelodedatos..................................... 45 5.5. Diagramasdesecuencia................................. 46 5.5.1. Diagrama de secuencia del caso de uso: Registrar usuario . . . . . . . . . . 47 5.5.2. Diagrama de secuencia del caso de uso: Servir una raci´on . . . . . . . . . . 48 5.5.3. Diagrama de secuencia del caso de uso: Programar un comedero . . . . . . 49 7 5.5.4. Diagrama de secuencia del caso de uso: Borrar Programaci´on . . . . . . . . 50 5.5.5. Diagrama de secuencia del caso de uso: Registrar n´umero de raciones . . . 50 5.5.6. Diagramas de flujo para la Raspberry Pi . . . . . . . . . . . . . . . . . . . 51 5.6. Planosdelcomedero .................................. 53 5.6.1. Parte superior del Comedero . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.6.2. Parte inferior del Comedero . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6. Implementaci´on 59 6.1. Entornodedesarrollo.................................. 59 6.2. Versiones necesarias de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.3. Herramientasutilizadas................................. 59 6.4. Controldeversiones .................................. 59 6.5. Servidor de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.6. Implementaci´on de la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.7. Sobre el framework Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7. Pruebas 63 7.1. Pruebasdelfrontend .................................. 63 7.1.1. Pruebas de caja negra para los usuarios generales . . . . . . . . . . . . . . 63 7.1.2. Pruebas de caja blanca para los usuarios generales . . . . . . . . . . . . . . 64 7.1.3. Pruebas de caja negra para los usuarios administradores . . . . . . . . . . 67 7.1.4. Pruebas de caja blanca para los usuarios administradores . . . . . . . . . . 68 7.1.5. Pruebas sobre la API Rest . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8. Manual del usuario 75 8.1. Usuarionormal ..................................... 75 8.1.1. Iniciodesesi´on ................................. 75 8.1.2. Editarnombre.................................. 77 8.1.3. A˜nadirraciones................................. 77 8.1.4. Programarcomedero .............................. 79 8.1.5. Borrar programaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 8.1.6. Servir ...................................... 81 8.2. Usuarioadministrador ................................. 81 8.2.1. Iniciarsesi´on .................................. 81 8.2.2. CrearUsuario.................................. 82 8.2.3. CrearComedero................................. 84 8.2.4. GenerarToken ................................. 84 9. Manual del programador 87 9.1. Comprensi´on del framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 9.2. Estructura de ficheros de Django . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 9.3. Configuraci´on de la Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 9.3.1. Hardwareysoftware .............................. 89 9.3.2. Instalaci´on.................................... 90 9.3.3. Configuraci´on de la conexi´on WiFi . . . . . . . . . . . . . . . . . . . . . . 90 9.3.4. Ejecuci´on autom´atica del script . . . . . . . . . . . . . . . . . . . . . . . . 91 10.Resultados 93 10.1.Im´agenes......................................... 93 10.2.V´ıdeo .......................................... 94 8 11.Conclusiones y trabajo futuro 95 11.1.Conclusiones....................................... 95 11.2.Trabajofuturo ..................................... 95 Anexos 98 I. Ap´endice A 101 9 1.3. Explicaci´on del escenario Como el mundo de la cetrer´ıa no es algo mayormente conocido, se procede a explicar brevemente en que consiste el cuidado de un ave de presa y as´ı se pretende justificar este proyecto. Estos animales act´uan por el hambre, es decir, ellos en la naturaleza salen a buscar alimento si se sienten hambrientos, si no es as´ı permanecer´an posados. Por este hecho y para que las aves obedezcan a su due˜no, es necesario saber su sensaci´on de hambre, el cual se controla a trav´es de su peso. Para ello es necesario gestionar de forma precisa lo que comen diariamente. Un ejemplo, si el due˜no del p´ajaro quisiera salir fuera un fin de semana deber´ıa dejar a alguien al cargo de tus animales. Aqu´ı es donde entra la soluci´on que propone este proyecto, podr´a controlar a las aves sin necesidad de encontrarse d´onde ellas est´en. Ahora que se ha puesto en situaci´on de lo que ser´a el proyecto se procede a detallar los requisitos del mismo. 16 Cap´ıtulo 2 An´alisis de requisitos 2.1. Definici´on de los actores 2.1.1. Administrador El Administrador es el encargado de dar de alta nuevos Usuarios y los Comederos asociados a estos Usuarios. 2.1.2. Usuario El Usuario puede utilizar la aplicaci´on web para consultar la informaci´on de sus comederos y ejecutar diversas funciones: servir una raci´on, programar... 2.1.3. Usuario Externo El Usuario Externo es aquel que no est´a registrado en el sistema. ´ El podr´a consultar la informaci´on del proyecto y las instrucciones de uso. 2.2. Requisitos funcionales 1. La aplicaci´on permitir´a al Usuario identificarse mediante usuario y contrase˜na. 2. La aplicaci´on mostrar´a todos los comederos que tengas activos, en cada uno podr´an verse los datos relativos al mismo: nombre, raciones actuales, raciones m´aximas y descripci´on de la programaci´on. 3. La aplicaci´on permitir´a al Usuario introducir una nueva cantidad de raciones. 4. La aplicaci´on permitir´a al Usuario modificar las raciones previamente introducidas. 5. La aplicaci´on permitir´a dar la orden de servir una raci´on. 6. La aplicaci´on permitir´a programar el servicio de una/s raci´on/es para un d´ıa o varios d´ıas y para uno o varios comederos, permitiendo elegir la hora para cada uno de los d´ıas y para cada comedero. 7. La aplicaci´on permitir´a borrar la programaci´on establecida para un comedero. 8. La aplicaci´on permitir´a al Usuario editar la programaci´on de cada uno de los comederos. 9. La aplicaci´on permitir´a editar el nombre del comedero. 17 10. La aplicaci´on permitir´a al Administrador registrar un nuevo Usuario mediante un nombre de usuario, una contrase˜na y la MAC asociada a la Raspberry en uso. 11. La aplicaci´on permitir´a al Administrador dar de alta nuevos Comederos. 12. La aplicaci´on permitir´a al Administrador asignar un n´umero m´aximo de raciones a un modelo de Comedero. 13. La aplicaci´on permitir´a al Administrador visualizar todos los Usuarios y los Comederos que poseen. 14. La aplicaci´on permitir´a ver toda la informaci´on relativa al proyecto. 15. La aplicaci´on permitir´a ver las instrucciones de uso de toda la aplicaci´on 2.3. Requisitos no funcionales 1. La aplicaci´on web se desarrollar´a en el framework Django basado en Python. 2. La aplicaci´on web ser´a al menos compatible para los navegadores Google Chrome y Mozilla Firefox. 3. La aplicaci´on web se albergar´a en un servidor (PythonAnywhere). 4. La Raspberry funcionar´a sobre Raspbian. 5. La Raspberry actuar´a sobre un servo para servir la comida. 6. La Raspberry estar´a embebida en el comedero con el que interactuar´a. 7. El comedero estar´a dise˜nado en freeCAD 0.16. Se adjuntar´an los planos. 8. El comedero se imprimir´a en 3D. 9. El prototipo del comedero se imprimir´a en un pl´astico denominado PLA (Poli´acido l´actico). 2.4. Reglas de negocio 1. Las raciones m´aximas que un comedero puede servir est´an limitadas por el n´umero de huecos para almacenarlas. 2. El n´umero m´aximo de programaciones que se pueden establecer para un comedero estar´a limitado por la cantidad de raciones actuales albergadas por el comedero y nunca ser´a superior al n´umero m´aximo de raciones posibles. 3. Si existen raciones previas registradas en el comedero se advertir´a antes de a˜nadir m´as raciones. 4. La programaci´on m´as temprana que se puede establecer para un comedero es, como m´aximo, al d´ıa siguiente del que se encuentra. 2.5. Requisitos de informaci´on 1. La cantidad de comida por raci´on depende del usuario que utilice la aplicaci´on. T´ıpicamente el cetrero sabr´a la cantidad de comida adecuada que contendr´a cada raci´on. 2. Es obligaci´on del usuario de la aplicaci´on retirar las raciones que perezcan o no utilizar´a. Una vez conocidos los requisitos del sistema a elaborar se procede a planificar el proyecto. 18 Cap´ıtulo 3 Plan de proyecto 3.1. Prop´osito, alcance y objetivos Como se ha introducido anteriormente el prop´osito de este proyecto es cubrir la necesidad de alimentar remotamente a las aves de cetrer´ıa, para as´ı mantener sus cuidados aunque el due˜no no se encuentre en el lugar donde las aves habitan. Se podr´a servir a decisi´on el alimento, o bien, programar un servicio. Tambi´en se mantendr´a informado del estado de cada comedero. Todo esto accesible desde la interfaz web de Hungry Falconry. 3.2. Artefactos de proyecto El conjunto de artefactos RUP est´a compuesto del siguiente modo: Modelo de negocio Requisitos An´alisis Dise˜no Implementaci´on Pruebas Despliegue 3.3. Plan de trabajo A continuaci´on se realizar´a una estimaci´on del esfuerzo y duraci´on de las diferentes etapas que lo compondr´an, siguiendo un modelo en cascada. Para llevar a cabo este proyecto es necesario tener conocimientos de los siguientes ´ambitos: Conocimientos de Python Conocimientos de HTML, CSS junto con Bootstrap Conocimientos sobre el Framework Django Conocimientos en SQL, espec´ıficamente SQLite Conocimientos de control de servomotores mediante Python y pines GPIO en Raspberry Pi Conocimientos de dise˜no 3D con FreeCAD 0.16 Conocimientos en impresi´on 3D 19 Fase de Inicio 1. Inicio de la fase de inicio Predecesoras: Duraci´on: 2. Elicitaci´on de requisitos Predecesoras: 1 Duraci´on: 5 d´ıas Se obtiene los requisitos para alcanzar los objetivos que se proponen. Adem´as de definir con que herramientas se llevar´an a cabo. 3. Calendario de tareas Predecesoras: 2 Duraci´on: 1 d´ıas Se distribuyen las tareas a lo largo del periodo de desarrollo del proyecto. 4. Adquisici´on de conocimientos en Django Predecesoras: 3 Duraci´on: 12 d´ıas En este periodo se espera adquirir los conocimientos suficientes para trabajar con dicho framework. 5. Control de versiones Predecesoras: 3 Duraci´on: 1 d´ıas Se establecer´a un sistema de control de versiones git, en GitHub. 6. Fin de la fase de inicio Predecesoras: 4, 5 Duraci´on: Fase de elaboraci´on 7. Inicio de la fase de elaboraci´on Predecesoras: 6 Duraci´on: 8. Casos de Uso Predecesoras: 7 Duraci´on: 5 d´ıas Se identificar´an y describir´an los casos de uso del sistema a partir de los requisitos. 9. Modelo de dominio Predecesoras: 8 20 Duraci´on: 1 d´ıas Realizaci´on del modelo del dominio. Identificar las clases implicadas. 10. Modelo de la base de datos Predecesoras: 9 Duraci´on: 1 d´ıas Realizaci´on del modelo de datos. Una versi´on simplificada de lo que ser´a la base de datos. 11. Dise˜no en 3D del prototipo Predecesoras: 7 Duraci´on: 9 d´ıas Se dise˜nar´a el prototipo con FreeCAD. Software de dise˜no en 3D. 12. Boceto de la interfaz de usuario Predecesoras: 9 Duraci´on: 1 d´ıas Se realizar´an unos bocetos de la interfaz de usuario que servir´an como referencia. 13. Dise˜no de la arquitectura del sistema Predecesoras: 10, 12 Duraci´on: 2 d´ıas La mayor´ıa de la arquitectura del sistema viene determinada por el framework. 14. Dise˜no de la base de datos Predecesoras: 13 Duraci´on: 2 d´ıas Se construir´a el esquema final de la base de datos. Su creaci´on va ligada a los denominados modelos del framework. 15. Diagramas de secuencia en dise˜no Predecesoras: 13, 14 Duraci´on: 5 d´ıas Realizaci´on de los diagramas de secuencia de los casos de uso de mayor relevancia. 16. Fin de la fase de elaboraci´on Predecesoras: 11, 15 Duraci´on: Fase de construcci´on 17. Inicio de la fase de construcci´on Predecesoras: 16 Duraci´on: 21 18. Configuraci´on del entorno de desarrollo Predecesoras: 17 Duraci´on: 1 d´ıa Se configurar´a una base de datos de prueba y se instalar´a lo correspondiente al framework. 19. Desarrollo del backend Predecesoras: 18 Duraci´on: 20 d´ıa Se desarrollar´a la gesti´on de usuarios y funcionalidades. As´ı como el API REST con ¡. El script cliente con Python. 20. Desarrollo del frontend Predecesoras: 18 Duraci´on: 10 d´ıa Se realizar´an todas las vistas del sistema, la capa de presentaci´on, con Bootstrap, HTML y CSS. 21. Impresi´on 3D del prototipo Predecesoras: 18 Duraci´on: 5 d´ıa Se imprimir´a el prototipo en 3D. La duraci´on viene determinada por el tiempo invertido por la impresora. 22. Fin de la fase de construcci´on Predecesoras: 19, 20, 21 Duraci´on: Fase de Transici´on 23. Inicio de la fase de transici´on Predecesoras: 22 Duraci´on: 24. Pruebas Predecesoras: 23 Duraci´on: 8 d´ıas 25. Elaborar manual del programador Predecesoras: 24 Duraci´on: 3 d´ıas 26. Elaborar manual del usuario Predecesoras: 24 Duraci´on: 2 d´ıas 27. Fin de la fase de transici´on Predecesoras: 25, 26 Duraci´on: 22 3.3.1. Diagramas de Gantt A continuaci´on se muestra los diagramas de Gantt de la planificaci´on del proyecto, es una aproximaci´on de la calendarizaci´on. En el Anexo I - Diagrama de Gantt Completo se muestra la planificaci´on completa. Fase de Inicio Figura 3.1: Diagrama de Gantt para la Fase de Inicio Fase de Elaboraci´on Figura 3.2: Diagrama de Gantt para la Fase de Elaboraci´on 23 Fase de Construcci´on Figura 3.3: Diagrama de Gantt para la Fase de Construcci´on Fase de Transici´on Figura 3.4: Diagrama de Gantt para la Fase de Transici´on Diagrama de Gantt completo 24 8 11 18 25 4 11 18 25 1 8 15 22 29 6 13 20 27 Feb '19 Mar '19 Apr '19 May '19 Hungry Falconry 0h 0% Fase de Inicio 0h 0% Inicio fase de Inicio 0 0% Elicitacion de requisitos 0 0% Calendario de tareas 0 0% Conocimientos en DJango 0 0% Control de versiones 0 0% Fin fase de Inicio 0 0% Fase de elaboracion 0h 0% 7. Inicio fase Elaboracion 0 0% 8. Casos de Uso 0 0% 9. Modelo de dominio 0 0% 10. Modelo de la Base de Datos 0 0% 11. Diseño 3D prototipo 0 0% 12. Boceto interfaz usuario 0 0% 13. Arquitectura del sistema 0 0% 14. Diseño BD 0 0% 15. Diagramas secuencias 0 0% 16. Fin fase Elaboracion 0 0% Fase de construccion 0h 0% 17. Inicio fase Construccion 0 0% 18. Configuracion entorno desarrollo 0 0% 19. Desarrollo backend 0 0% 20. Desarrollo frontend 0 0% 21. Impresion 3D del prototipo 0 0% 22. Fin fase Construccion 0 0% Fase de transicion 0h 0% 23. Inicio fase Transicion 0 0% 24. Pruebas 0 0% 25. Manual del programador 0 0% 26. Manual del usuario 0 0% Fin fase de transicion 0 0% Powered by TCPDF (www.tcpdf.org) Editar Programaci´on CU-4 Editar programaci´on Actor Usuario Descripci´on El sistema deber´a permitir editar la programaci´on de un comedero. Precondici´on El actor ha iniciado sesi´on en el sistema, el comedero tiene raciones y una programaci´on previa. Secuencia Normal Paso Acci´on 1 El actor selecciona la opci´on editar programaci´on. 2 El sistema muestra el men´u de editar programaci´on de un comedero. 3 Se ejecuta el caso de uso ((Programar un comedero)) 4 El sistema muestra un mensaje de ´exito y el caso de uso finaliza. Postcondici´on Excepciones Variaci´on Acci´on Tabla 4.4: Caso de Uso 4 - Editar programaci´on Borrar programaci´on CU-5 Borrar programaci´on Actor Usuario Descripci´on El sistema deber´a permitir borrar la programaci´on de un comedero. Precondici´on El actor ha iniciado sesi´on en el sistema, el comedero tiene una programaci´on previa. Secuencia Normal Paso Acci´on 1 El actor selecciona la opci´on borrar programaci´on. 2 El sistema muestra un mensaje de confirmaci´on. 3 Se actor selecciona Si. 4 El sistema muestra un mensaje de ´exito y el caso de uso finaliza. Postcondici´on Se ha borrado la programaci´on del comedero. Excepciones Variaci´on Acci´on 3a El actor selecciona No. El caso de uso finaliza y queda sin efecto. Tabla 4.5: Caso de Uso 5 - Borrar programaci´on 32 Registrar el n´umero de raciones CU-6 Registrar el n´umero de raciones Actor Usuario Descripci´on El sistema deber´a permitir registrar el n´umero de raciones que previamente se han introducido en el comedero. Precondici´on El actor ha introducido las raciones en forma de alimento en el comedero. Secuencia Normal Paso Acci´on 1 El actor selecciona la opci´on nuevas raciones. 2 El sistema muestra el men´u de a˜nadir raciones. 3 El actor registra el n´umero de raciones y pulsa aceptar. 4 El sistema muestra un mensaje de ´exito y el caso de uso finaliza. Postcondici´on Se ha registrado la cantidad de raciones que ahora contiene el comedero. Excepciones Variaci´on Acci´on 1a El actor selecciona a˜nadir m´as raciones. 2a El comedero tenia raciones ya introducidas, entonces el sistema advierte de que se eliminaran las anteriores raciones. 3a El actor introduce un n´umero superior a la cantidad de raciones m´aximas permitidas por el comedero, el sistema muestra un error y el caso de uso contin´ua en el paso 2. 3b El actor introduce 0 o menos raciones, el sistema muestra un error y el caso de uso contin´ua en el paso 2. 3c El actor pulsa Atr´as y el caso de uso queda sin efecto. 4a Ocurre alg´un error en el proceso, se muestra un mensaje de error y el caso de uso contin´ua en el paso 3. Tabla 4.6: Caso de Uso 6 - Registrar el n´umero de raciones 33 Editar n´umero de raciones CU-7 Editar n´umero de raciones Actor Usuario Descripci´on El sistema deber´a permitir editar el n´umero de raciones que previamente se han introducido en el comedero. Precondici´on Se ha ejecutado el Caso de Uso (( Registrar el n´umero de raciones de un comedero)). Secuencia Normal Paso Acci´on 1 El actor selecciona la opci´on editar raciones. 2 El sistema muestra el men´u de editar raciones y la cantidad anterior de raciones. 3 El actor pulsa la opci´on a˜nadir raci´on. 4 El sistema aumenta en 1 el n´umero de raciones por cada pulsaci´on. 5 El actor pulsa Aceptar. 6 El sistema muestra un mensaje de ´exito y el Caso de Uso finaliza. Postcondici´on Se ha editado la cantidad de raciones que ahora contiene el comedero. Excepciones Variaci´on Acci´on 2a El comedero no ten´ıa raciones previamente introducidas, se muestra un mensaje de error y el Caso de Uso finaliza. 3a El actor pulsa la opci´on restar raci´on. 3b El actor pulsa cancelar y el caso de uso queda sin efecto. 4a El sistema disminuye en 1 el n´umero de raciones por cada pulsaci´on. 5a El actor pulsa Cancelar y el Caso de Uso queda sin efecto. 6a Ocurre alg´un error en el proceso, se muestra un mensaje de error y el caso de uso contin´ua en el paso 5. Tabla 4.7: Caso de Uso 7 - Editar n´umero de raciones 34 Identificarse CU-8 Identificarse Actor Usuario y Administrador Descripci´on El sistema permitir´a iniciar sesi´on en ´el. Precondici´on El usuario debe estar registrado en el sistema. Secuencia Normal Paso Acci´on 1 El actor entra en el sistema. 2 El sistema muestra la vista de iniciar sesi´on. 3 El actor introduce el nombre de usuario, contrase˜na y pulsa Iniciar Sesi´on. 4 El sistema comprueba los datos introducidos y se ejecuta el caso de uso (( Consultar informaci´on de todos mis comederos )) para el rol de Usuario y la vista correspondiente al Administrador en el caso de que el rol sea Administrador. Postcondici´on El actor ha iniciado sesi´on en el sistema. Excepciones Variaci´on Acci´on 3a El actor pulsa Cancelar y el caso de uso queda sin efecto. 4a El sistema comprueba que los datos introducidos son err´oneos, muestra un mensaje de error y el caso de uso contin´ua en el paso 2. Tabla 4.8: Caso de Uso 8 - Identificarse 35 Consultar informaci´on de todos mis comederos CU-9 Consultar informaci´on de todos mis comederos Actor Usuario Descripci´on El sistema mostrar´a la informaci´on de todos los comederos que tenga el Usuario en funcionamiento. Precondici´on Se ha ejecutado el Caso de Uso ((Identificarse)). Secuencia Normal Paso Acci´on 1 El sistema muestra una lista con toda la informaci´on correspondiente a los comederos que el usuario tiene activos. Postcondici´on Excepciones Variaci´on Acci´on Tabla 4.9: Caso de Uso 9 - Consultar informaci´on de todos mis comederos Editar informaci´on CU-10 Editar informaci´on Actor Usuario Descripci´on El sistema permitir´a editar la informaci´on de un comedero tales como el nombre. Precondici´on El actor se ha identificado en el sistema y tiene comederos activos. Secuencia Normal Paso Acci´on 1 El actor selecciona la opci´on de editar informaci´on de un comedero. 2 El sistema muestra el men´u de editar propiedades de un comedero. 3 El actor modifica el nombre. Pulsa Aceptar. 4 El sistema muestra un mensaje de ´exito y el caso de uso finaliza. Postcondici´on La informaci´on editada queda guardada. Excepciones Variaci´on Acci´on 3a El actor pulsa Atr´as y el caso de uso queda sin efecto. 4a Ocurre alg´un error en el proceso, se muestra un mensaje de error y el caso de uso contin´ua en el paso 3. Tabla 4.10: Caso de Uso 10 - Editar informaci´on 36 4.1.4. Casos de uso del actor Usuario Externo Consultar informaci´on del proyecto CU-11 Consultar informaci´on del proyecto Actor Usuario Externo Descripci´on El sistema permitir´a ver toda la informaci´on relevante para el usuario del proyecto Precondici´on Secuencia Normal Paso Acci´on 1 El actor selecciona la opci´on de informaci´on del proyecto. 2 El sistema muestra toda la informaci´on referente al proyecto. Postcondici´on Excepciones Variaci´on Acci´on Tabla 4.11: Caso de Uso 11 - Editar Consultar informaci´on del proyecto Consultar instrucciones de uso de la aplicaci´on CU-12 Consultar instrucciones de uso de la aplicaci´on Actor Usuario Externo Descripci´on El sistema permitir´a ver las instrucciones de uso de la aplicaci´on. Precondici´on Secuencia Normal Paso Acci´on 1 El actor selecciona la opci´on de instrucciones de uso. 2 El sistema muestra toda la informaci´on referente a las instrucciones de uso. Que pasos hay que seguir para hacer cada funcionalidad. Postcondici´on Excepciones Variaci´on Acci´on Tabla 4.12: Caso de Uso 12 - Consultar instrucciones de uso de la aplicaci´on 37 4.2. Modelo de dominio El siguiente diagrama muestra las clases detectadas junto con sus atributos. Figura 4.2: Diagrama modelo de dominio en an´alisis 4.3. Modelo de datos El siguiente apartado muestra el diagrama entidad relaci´on de la base de datos que se implementar´a. Los campos algorithm,salt yhash ser´an explicados en la fase de dise˜no. Figura 4.3: Diagrama de la base de datos en an´alisis Realizada la fase de an´alisis se procede a la fase de dise˜no. 38 Cap´ıtulo 5 Dise˜no 5.1. Arquitectura del sistema Como el proyecto se desarrollar´a con el framework Django, la arquitectura viene definida por ´el mismo. En esencia Django sigue una arquitectura Modelo-Vista-Controlador (MVC) pero con una salvedad, a las vistas las denominan plantillas (Templates) y a los controladores, vistas (Views). As´ı que se podr´ıa establecer el acr´onimo MTV (Model-Template-View) [4]. Figura 5.1: Arquitectura Django 39 En realidad los paquetes no son directorios como tal, se trata de ficheros Python (.py) que alojan funciones y clases pero que est´an diferenciados por funcionalidad. Es decir, en el fichero views.py est´an todos los controladores, act´ua como paquete de clases, pero no es un directorio, es un fichero Python. Lo primero que hay que diferenciar es la existencia de tres niveles. Se procede a explicar del nivel m´as externo al m´as interno. En el nivel m´as externo de todos se encuentra el manage , encargado, entre una multitud de funcionalidades, de crear los proyectos y las aplicaciones, crear superusuarios, arrancar el servidor... En el paquete static se encuentran todos los archivos gr´aficos, ficheros css y javascript. El siguiente nivel, el nivel de proyecto, llamado hungryFalconry, alberga las opciones ( settings ), las urls y el paquete wsgi , utilizado para el despliegue. El paquete urls se encarga del direccionamiento interno del proyecto: para una URL dada se ejecutar´a una acci´on. Adem´as incluye las URL de las aplicaciones del proyecto. El paquete settings se encarga de toda la configuraci´on del proyecto, librer´ıas instaladas, opciones de estas librer´ıas, conexi´on a la base de datos, idioma, zona horaria... Nivel de aplicaciones. Aqu´ı se encuentran las aplicaciones desarrolladas dentro del mismo proyecto. En este caso solo existe una, denominada hungryFalconryApp . Dentro de cada aplicaci´on existen tres paquetes m´as relevantes que el resto. El paquete models , encargado de crear los objetos y adem´as plasmarlos en forma de tabla a la base de datos. Sigue actuando como el Modelo en una arquitectura MVC. Las plantillas ( templates ), corresponden a la vista en arquitectura MVC. Albergan el HTML y javascript correspondientes para visualizaci´on de la p´agina. Por ´ultimo las views , act´uan como controladores de vista, por cada acci´on ocurrida en las templates se ejecutar´a una view. El resto de paquetes: urls: Asocia cada URL a una acci´on, que es ejecutada en las views. admin : Registra los modelos para que sean accesibles desde la p´agina de administraci´on. Para as´ı poderlos crear, editar, borrar... apps: Registra todas las aplicaciones instaladas en el proyecto. forms : Crea formularios. Es capaz de crear un formulario y ubicarlo en las templates para luego recoger sus valores y enviarlos a las views. test: Para crear pruebas de las aplicaciones. permisions : Pertenece a Django Rest Framework. Establece los permisos para los recursos de la API Rest. serializers : Pertenece a Django Rest Framework. Se encarga de enviar los campos establecidos de la base de datos a trav´es de la API Rest. 40 5.2. Interfaz de usuario En esta secci´on se incluir´an los bocetos de las vista que compondr´an la p´agina web [ 1 ]. S´olo se muestra la vista del Usuario, pues, gracias al framework, las funciones de gesti´on que llevar´ıa a cabo el Administrador vienen ya implementadas. Figura 5.2: Vista inicio de sesi´on 41 5.5.2. Diagrama de secuencia del caso de uso: Servir una raci´on Figura 5.10: Diagrama de secuencia del caso de uso: Servir una raci´on 48 5.5.3. Diagrama de secuencia del caso de uso: Programar un comedero Figura 5.11: Diagrama de secuencia del caso de uso: Programar un comedero 49 5.5.4. Diagrama de secuencia del caso de uso: Borrar Programaci´on Figura 5.12: Diagrama de secuencia del caso de uso: Borrar Programaci´on 5.5.5. Diagrama de secuencia del caso de uso: Registrar n´umero de raciones Figura 5.13: Diagrama de secuencia del caso de uso: Registrar n´umero de raciones 50 5.5.6. Diagramas de flujo para la Raspberry Pi Autenticaci´on contra el API Rest Figura 5.14: Diagrama de secuencia: Autenticaci´on contra la API Rest 51 Escucha activa para la espera de un servicio y guardar programaci´on Figura 5.15: Diagrama de secuencia: Servir y guardar programaci´on 52 Cumplir programaci´on establecida y guardada Figura 5.16: Diagrama de secuencia: Consumir programaci´on establecida 5.6. Planos del comedero 5.6.1. Parte superior del Comedero 53 Figura 5.17: Plano parte superior del comedero 54 5.6.2. Parte inferior del Comedero 55 Figura 5.18: Plano parte inferior del comedero 56 Establecidas ambas partes del dise˜no del sistema, aplicaci´on web y prototipo, se procede a su realizaci´on. 57 Prueba 1.4 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de modificar las raciones Acci´on Se modifican las raciones de un comedero Resultado Esperado Se sobrescribe el valor de raciones anterior por el que actual introducido Prueba 1.5 Requisito funcional 6. Prueba 1.5 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de programar un comedero Acci´on Se programa el servicio de una raci´on Resultado Esperado Se a˜nade un nuevo d´ıa y hora a la lista de programaciones, su estado es pendiente, se refleja con un icono de reloj Prueba 1.6 Requisito funcional 6. Prueba 1.6 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de programar un comedero Acci´on Llega el instante programado Resultado Esperado Se sirve una raci´on del comedero, se resta una raci´on y la programaci´on asociada se marca como servida con un tick verde en la lista de programaciones Prueba 1.7 Requisito funcional 7. Prueba 1.7 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de borrar una programaci´on Acci´on Se borra una programaci´on Resultado Esperado Se elimina la programaci´on correspondiente. Si es una programaci´on servida no se borrar´a Prueba 1.8 Requisito funcional 9. Prueba 1.8 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de editar el nombre del comedero Acci´on Se edita el nombre del comedero Resultado Esperado Se edita el nombre del comedero y se refleja en la vista de todos los comederos 7.1.2. Pruebas de caja blanca para los usuarios generales Prueba 1.9 Requisito funcional 3 y 4. Prueba 1.9 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de a˜nadir nuevas raciones Acci´on Se accede al men´u de a˜nadir raciones. Resultado Esperado Como existen raciones anteriores se muestra un mensaje de advertencia. 64 Figura 7.1: Mensaje de advertencia a˜nadiendo raciones Prueba 1.10 Requisito funcional 3 y 4. Prueba 1.10 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de a˜nadir m´as raciones de las permitidas. Acci´on Se intenta a˜nadir m´as raciones que el n´umero m´aximo de raciones. Resultado Esperado Se muestra un mensaje de error, advirtiendo de que es un n´umero de raciones err´oneo. Figura 7.2: Mensaje de error a˜nadiendo m´as raciones de las permitidas Prueba 1.11 Requisito funcional 3 y 4. Prueba 1.11 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de a˜nadir un n´umero negativo de raciones. Acci´on Se intenta a˜nadir un n´umero negativo de raciones. Resultado Esperado Se muestra un mensaje de error, advirtiendo de que es un n´umero de raciones err´oneo. 65 Figura 7.3: Mensaje de error a˜nadiendo un n´umero negativo de raciones Prueba 1.12 Requisito funcional 3 y 4. Prueba 1.12 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de a˜nadir cero raciones. Acci´on Se intenta a˜nadir cero raciones. Resultado Esperado Se muestra un mensaje de error, advirtiendo de que es un n´umero de raciones err´oneo. Figura 7.4: Mensaje de error a˜nadiendo cero raciones En el caso de las figuras proporcionadas para las pruebas 1.10, 1.11 y 1.12 se observa que el comedero posee una raci´on, este par´ametro no influye en el comportamiento ni las pruebas ni del programa, porque si se introduce un n´umero de raciones correcto este valor se sobrescribir´a. 66 Prueba 1.13 Requisito funcional 6. Prueba 1.13 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de a˜nadir m´as programaciones que raciones actuales. Acci´on Se intenta a˜nadir una segunda programaci´on teniendo solo una raci´on en el comedero. Resultado Esperado Se muestra un mensaje de error, advirtiendo de que es no se puede programar m´as servicios que raciones. Figura 7.5: Mensaje de error a˜nadiendo m´as programaciones que raciones actuales 7.1.3. Pruebas de caja negra para los usuarios administradores Prueba 2.1 Requisito funcional 1. Prueba 2.1 Descripci´on Esta prueba est´a destinada a probar el funcionamiento del inicio de sesi´on Acci´on Iniciar sesi´on en la aplicaci´on web con rol Administrador Resultado Esperado El usuario tiene acceso a todas las funcionalidades de administrador Prueba 2.2 Requisito funcional 10. Prueba 2.2 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de registrar un nuevo usuario Acci´on Se registra un usuario nuevo Resultado Esperado El nuevo usuario sale en la lista de usuarios, con todos sus datos 67 Prueba 2.3 Requisito funcional 11. Prueba 2.3 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de registrar un nuevo comedero Acci´on Se da de alta un nuevo comedero Resultado Esperado El nuevo comedero aparece en la lista de todos los comederos, con su nombre. Adem´as aparece asociado a un usuario existente 7.1.4. Pruebas de caja blanca para los usuarios administradores No se realizar´an pruebas de caja blanca para el sitio del Administrador, pues es una funcionalidad proporcionada por el propio framework, as´ı que se supondr´a su correcto funcionamiento. 68 7.1.5. Pruebas sobre la API Rest Para las siguientes pruebas se usar´a la interfaz gr´afica proporcionada por Django REST framework. Se adjunta la URL sin la direcci´on del servidor. Previa autenticaci´on en todas las pruebas. En este caso la autenticaci´on es mediante usuario y contrase˜na. Prueba 3.1 Prueba 3.1 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de la operaci´on GET para todos los comederos. Resultado Esperado Se consigue un JSON con todos los comederos del sistema. Figura 7.6: GET comederos API REST Prueba 3.2 Prueba 3.2 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de la operaci´on GET para un comedero. Resultado Esperado Se consigue un JSON con la informaci´on del comedero deseado. 69 Figura 7.7: GET un s´olo comedero API REST Prueba 3.3 Prueba 3.3 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de la operaci´on GET para la programaci´on de un comedero. Resultado Esperado Se consigue un JSON con todas las programaciones del comedero deseado. Figura 7.8: GET programaci´on para un comedero API REST 70 Prueba 3.4 Prueba 3.4 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de la operaci´on GET para los usuarios del sistema y sus comederos. Resultado Esperado Se consigue un JSON con todos los usuarios y sus comederos. Figura 7.9: GET usuarios y sus comederos API REST 71 Prueba 3.5 Prueba 3.5 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de la operaci´on GET para un s´olo usuario del sistema y sus comederos. Resultado Esperado Se consigue un JSON con datos del usuario y sus comederos. Figura 7.10: GET un solo usuario y sus comederos API REST 72 Prueba 3.6 Prueba 3.6 Descripci´on Esta prueba est´a destinada a probar el funcionamiento de la operaci´on PUT para modificar la programaci´on de un comedero. Resultado Esperado Se modifica los datos de la programaci´on. Figura 7.11: PUT programaci´on de un comedero API REST 73 Figura 8.7: Vista programar comederos con nueva programaci´on 8.1.5. Borrar programaci´on Para borrar una programaci´on nos dirigimos al men´u de Programar comedero (ver Fig. 8.8) y all´ı pulsamos la papelera asociada a la programaci´on que queremos eliminar. Nos mostrar´a un mensaje de confirmaci´on y en el caso de aceptar (Si), se borrar´a la programaci´on. Figura 8.8: Vista programar comederos con nueva programaci´on 80 8.1.6. Servir Para servir inmediatamente una raci´on del comedero podemos hacerlo pulsando la opci´on de Servir de la pantalla principal. S´olo se podr´a servir si hay raciones introducidas en el comedero y en el caso de que el n´umero de programaciones no sea igual al n´umero de raciones que guarde el comedero, es decir, si hay una programaci´on por raci´on no se podr´a servir. Figura 8.9: Vista confirmaci´on cuando se sirve 8.2. Usuario administrador El men´u de administraci´on es accesible desde http://davidelavarga.pythonanywhere.com/ admin. 8.2.1. Iniciar sesi´on El administrador iniciar´a sesi´on (ver Fig. 8.9) y se le mostrar´a el panel de control (ver Fig. 8.10). En el panel de control se observa toda la funcionalidad que el administrador puede modificar: Grupos, Usuarios, Comederos y Programaci´on. Los Tokens son necesarios para la autenticaci´on. Y a la derecha del panel de control se guarda un historial de acciones que va realizando el administrador. 81 Figura 8.10: Vista inicio de sesi´on para Administrador 8.2.2. Crear Usuario Nos dirigiremos a la creaci´on de Usuarios presionando el texto de A˜nadir en la fila de Usuarios. Y se mostrar´a la vista de creaci´on de Usuarios (ver Fig. 8.11). Se completan los campos con la petici´on correspondiente del Usuario. Se pulsa GRABAR. 82 Figura 8.11: Vista panel de control para Administrador Figura 8.12: Vista a˜nadir Usuario para Administrador 83 8.2.3. Crear Comedero Ahora hay que crear el Comedero que se le proporcionar´a al Usuario. Nos dirigimos a A˜nadir en la fila de Comederos. Se completan los campos adecuadamente. En el campo MAC es importante poner correctamente la direcci´on MAC de la Raspberry Pi embebida en el comedero. Despu´es para asociar al Usuario adecuado lo seleccionamos en el desplegable del campo titular. Figura 8.13: Vista a˜nadir Comedero para Administrador 8.2.4. Generar Token Es necesario generar un token para el usuario y a˜nadirlo al programa que se ejecuta en la Raspberry Pi. Se realizar´a dirigi´endonos al apartado de Tokens y seleccionando el usuario deseado, una vez adquirido el token lo copiaremos en la l´ınea pertinente del programa que se encuentra en la Raspberry: /home/pi/Desktop/pruebaAPIRest/simulacion rest.py (ver Fig. 8.14 y 8.15). Figura 8.14: Vista Token en el c´odigo 84 Figura 8.15: Vista a˜nadir Token para un Usuario Explicadas las instrucciones de uso de la aplicaci´on, ahora se llevar´a a cabo la explicaci´on de la aplicaci´on para un desarrollador. 85 86 Cap´ıtulo 9 Manual del programador En este cap´ıtulo se detallar´an las cuestiones necesarias para que un posible futuro programador pudiera extender el sistema, bien a˜nadiendo m´as funcionalidades o modificando y mejorando las actuales. 9.1. Comprensi´on del framework Para poder entender y posteriormente trabajar sobre esta aplicaci´on es necesario y primordial conocer el framework Django 2.2 [ 2 ]. Adem´as, para la comprensi´on de la API Rest es necesario conocimiento sobre Django Rest Framework [9]. 9.2. Estructura de ficheros de Django La siguiente estructura est´a explicada, aunque a menor nivel de detalle, en el apartado 5.1 Arquitectura. La estructura de directorios que sigue es la siguiente: hungryFalconry/ – hungryFalconry/ —— settings.py —— urls.py —— wsgi.py —— init .py – hungryFalconryApp/ —— migration/ —— templates/ ———– hungryFalconryApp/ —————– add raciones.html —————– base.html —————– editar info.html —————– programar info.html —————– tus comederos.html ———– registration/ —————– login.html —— init .py —— admin.py —— apps.py —— forms.py —— models.py —— permissions.py 87 —— serializers.py —— urls.py —— views.py —— tests.py – static/ —— admin/ —— bootstrap4 datetime/ —— bootstrap datepicker plus/ —— css/ —— images/ —— rest framework/ – manage.py – requirements.txt – db.sqlite3 Una vez conocida la estructura de directorios y ficheros que sigue el sistema, se procede a describirlos. El directorio principal, hungryFalconry , contiene el proyecto, las aplicaciones, la base de datos y los ficheros necesarios para arrancar y configurar el servidor. El directorio hungryFalconry, que cuelga del anterior, contiene todo lo relativo a configuraciones (settings.py), todas las URLs del proyecto y las aplicaciones (urls.py) y todo lo necesario para el despliegue (wsgi.py). El directorio hungryFalconryApp corresponde a la aplicaci´on con su nombre. Dentro de ´el se encuentra: templates/hungryFalconryApp : contiene los HTML para la vista en el navegador. El fichero base.html contiene la informaci´on com´un a todas las plantillas, a excepci´on de la plantilla login.html, situada en el directorio registration/. templates/registration: HTML para la plantilla de inicio de sesi´on. models.py : Es una representaci´on de las tablas de la base de datos, adem´as cuando se aplica una migraci´on (necesaria cuando se crea o modifica un modelo) se crea una tabla con el nombre del modelo en cuesti´on y una columna por etiqueta (CharField, IntegerField ...) existente en el modelo. Aqu´ı existen los modelos: Comedero , Programaci´on y Usuario . Tambi´en existen algunos m´etodos utilizados para la validaci´on de determinados campos de los modelos. views.py : Son los tradicionalmente denominados controladores [ 4 ]. Se han desarrollado m´etodos para las funcionalidades de la aplicaci´on y clases para las de la API Rest. •tus comederos : Recupera los Comederos del Usuario y muestra la vista de sus comederos. •servir : Para el comedero seleccionado cambia el valor de la variable tengo que servir a True. Gracias a este cambio y a trav´es del consumo de la API Rest, el comedero asociado actuar´a en consecuencia, sirviendo una raci´on y devolviendo esta variable a False, tambi´en se restar´a una raci´on. •add raciones : Para el nombre del comedero pasado como par´ametro muestra la vista de a˜nadir raciones, una vez completado el formulario guarda el n´umero de raciones nuevas. •editar info : Para el nombre del comedero pasado como par´ametro muestra la vista de editar informaci´on y una vez completado el formulario modifica el nombre del comedero. •programar comederos : Para el nombre del comedero pasado como par´ametro muestra la vista de programar comederos, una vez seleccionado d´ıa y hora guarda una nueva 88 programaci´on para el comedero. Cuando llegue el momento, el comedero, mediante el consumo de la API Rest, actuar´a sirviendo una raci´on y marcando la programaci´on correspondiente como servida, tambi´en se restar´a una raci´on. •borrar programacion : Una vez en la vista programar comederos y seleccionando el icono de la papelera se borrar´a la programaci´on. Toda la documentaci´on de la API en http://davidelavarga.pythonanywhere. com/docs y en el Anexo 1 • (API Rest) ComederoList , para la URL comederos/ devuelve la lista de todos los comederos. • (API Rest) ComederoDetail , para las acciones de POST, PUT y PATCH sobre los comederos. • (API Rest) ProgramacionList , para la URL programacion/pk/get devuelve las programaciones relativas al comedero con dicha pk (Clave primaria). • (API Rest) ProgramacionDetail para las acciones de POST, PUT y PATCH sobre las programaciones. •(API Rest) UserList, para la URL users/ devuelve todos los usuarios. • (API Rest) UserDetail para la URL users/pk se pueden ejecutar las acciones de POST, PUT y PATCH del comedero con dicha pk (Clave primaria). forms.py : Aqu´ı se crean los denominados formularios, por lo general en esta aplicaci´on un formulario se crea a partir de un conjunto de etiquetas de una tabla de la base de datos. Cada formulario se crear´a a la hora de construir la template, esto sucede cuando se invoca a alg´un m´etodo o clase de views.py. serializers.py , se encarga de determinar que subconjunto de etiquetas de los modelos se env´ıan a trav´es de la API Rest. Existe una clase serializer por cada modelo: ComederoSerializer,UserSerializer,ProgramacionSerializer. permissions.py , define los permisos para los recursos de la API Rest. IsOwnerOrReadOnly establece permisos de lectura para los recursos y de lectura y escritura para el propietario de ese recurso. Entendiendo como propietario el usuario que se ha registrado. static/ , almacena todos los archivos para el estilo y formato de los diferentes elementos de la aplicaci´on. Para las siguientes librer´ıas instaladas en el proyecto contiene los ficheros .css , JavaScript (.js) e im´agenes necesarias. Las librer´ıas instaladas son admin, bootstrap4 datetime, bootstrap datepicker plus y rest framework. Los directorios images/ y css/ est´an creados por el desarrollador para la aplicaci´on, contienen las im´agenes y el estilo de la aplicaci´on, respectivamente. 9.3. Configuraci´on de la Raspberry Pi 9.3.1. Hardware y software Raspberry Pi 3 Model B+ Micro SD 16 GB 2018-11-13-raspbian-stretch-full.img 89 Aplicaci´on de alg´un tipo de envoltorio para convertir esta aplicaci´on en una aplicaci´on m´ovil. Desarrollo de una interfaz de gesti´on de usuarios m´as completa. Dise˜no de un modelo de comedero capaz de ser construido por m´odulos. Es decir, que un comedero pueda ser de una raci´on y luego pueda ampliarse a tres raciones f´acilmente. Refrigeraci´on del comedero para evitar que el alimento perezca. A trav´es de c´elulas peltier y sistema aislante tipo PIRALU (panel de espuma r´ıgida de poliisocianurato revestido de aluminio). Implementar un sistema de comunicaci´on alternativo a la conexi´on WiFi, permitiendo as´ı la conexi´on desde lugares remotos (3G, 4G). Implantaci´on de un sensor de presi´on en el comedero para cerciorar que el alimento ha sido expulsado del interior cuando se ha realizado la acci´on de servir. 96 Bibliograf´ıa [1] https://balsamiq.com/. Balsamiq mockups. ´ Ultimo acceso: 10 de junio de 2019. [2] https://djangoproject.com/. Django. ´ Ultimo acceso: 12 de junio de 2019. [3] https://docs.djangoproject.com/en/2.2/topics/auth/passwords/. Password management in django. ´ Ultimo acceso: 12 de junio de 2019. [4] https://docs.djangoproject.com/es/2.2/faq/general/. Django parece ser un framework mvc, pero ustedes llaman al controlador (( vista )) , y a la vista (( plantilla )) . ¿c´omo es que no usan los nombres est´andares?, Marzo 2019. ´ Ultimo acceso: 12 de junio de 2019. [5] https://getbootstrap.com/. Bootstrap. ´ Ultimo acceso: 12 de junio de 2019. [6] https://pypi.org/. django-bootstrap-datepicker-plus. ´ Ultimo acceso: 12 de junio de 2019. [7] https://pypi.org/. django-bootstrap4. ´ Ultimo acceso: 12 de junio de 2019. [8] https://pypi.org. Django jquery. ´ Ultimo acceso: 12 de junio de 2019. [9] https://www.django-rest framework.org/. Django rest framework. ´ Ultimo acceso: 12 de junio de 2019. [10] https://www.jetbrains.com/. The python ide for professional developers. ´ Ultimo acceso: 12 de junio de 2019. [11] https://www.pythonanywhere.com/. Host, run, and code python in the cloud! ´ Ultimo acceso: 12 de junio de 2019. [12] https://www.sqlite.org/index.html. Sqlite. ´ Ultimo acceso: 12 de junio de 2019. 97 98 Anexos 99 Anexo I Ap´endice A Documentaci´on API Rest 101     Hungry Falconry API Rest  api-token-auth  comederos  programacion  users none python  Authentication  Source Code shell javascript python api-token-auth comederos Hungry Falconry API Rest # Install the Python client library $ pip install coreapi  Interact create POST /api-token-auth/ Request Body The request body should be a "application/json" encoded object, containing the following items. Parameter Description username required Valid username for authentication password required Valid password for authentication import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["api-token-auth", "create"] params = { "username": ..., "password": ..., } result = client.action(schema, action, params=params)  Interact list GET /comederos/ Devuelve una lista de todos los Comederos. import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["comederos", "list"] result = client.action(schema, action)  Interact create POST /comederos/ Devuelve una lista de todos los Comederos. Request Body The request body should be a "application/json" encoded object, containing the following items. Parameter Description mac required nombre required tengo_que_servir numRacionesActuales required nuevaProgramacion     Hungry Falconry API Rest  api-token-auth  comederos  programacion  users none python  Authentication  Source Code shell javascript python import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["comederos", "create"] params = { "mac": ..., "nombre": ..., "tengo_que_servir": ..., "numRacionesActuales": ..., "nuevaProgramacion": ..., } result = client.action(schema, action, params=params)  Interact read GET /comederos/{mac}/ Devuelve una instancia de Comederos. Path Parameters The following parameters should be included in the URL path. Parameter Description mac required A unique value identifying this comedero. import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["comederos", "read"] params = { "mac": ..., } result = client.action(schema, action, params=params)  Interact update PUT /comederos/{mac}/ Edita una instancia de Comedero. Path Parameters The following parameters should be included in the URL path. Parameter Description mac required A unique value identifying this comedero. Request Body The request body should be a "application/json" encoded object, containing the following items. Parameter Description mac required nombre required tengo_que_servir numRacionesActuales required nuevaProgramacion     Hungry Falconry API Rest  api-token-auth  comederos  programacion  users none python  Authentication  Source Code shell javascript python import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["comederos", "update"] params = { "mac": ..., "mac": ..., "nombre": ..., "tengo_que_servir": ..., "numRacionesActuales": ..., "nuevaProgramacion": ..., } result = client.action(schema, action, params=params)  Interact partial_update PATCH /comederos/{mac}/ Path Parameters The following parameters should be included in the URL path. Parameter Description mac required A unique value identifying this comedero. Request Body The request body should be a "application/json" encoded object, containing the following items. Parameter Description mac nombre tengo_que_servir numRacionesActuales nuevaProgramacion import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["comederos", "partial_update"] params = { "mac": ..., "mac": ..., "nombre": ..., "tengo_que_servir": ..., "numRacionesActuales": ..., "nuevaProgramacion": ..., } result = client.action(schema, action, params=params)  Interact delete DELETE /comederos/{mac}/ Elimina una instancia de Comedero. Path Parameters The following parameters should be included in the URL path. Parameter Description mac required A unique value identifying this comedero.     Hungry Falconry API Rest  api-token-auth  comederos  programacion  users none python  Authentication  Source Code shell javascript python import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["comederos", "delete"] params = { "mac": ..., } result = client.action(schema, action, params=params)  Interact read_0 GET /comederos/{mac}{format} Devuelve una instancia de Comederos. Path Parameters The following parameters should be included in the URL path. Parameter Description format required mac required A unique value identifying this comedero. import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["comederos", "read_0"] params = { "format": ..., "mac": ..., } result = client.action(schema, action, params=params)  Interact update_0 PUT /comederos/{mac}{format} Edita una instancia de Comedero. Path Parameters The following parameters should be included in the URL path. Parameter Description format required mac required A unique value identifying this comedero. Request Body The request body should be a "application/json" encoded object, containing the following items. Parameter Description mac required nombre required tengo_que_servir numRacionesActuales required nuevaProgramacion     Hungry Falconry API Rest  api-token-auth  comederos  programacion  users none python  Authentication  Source Code shell javascript python import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["programacion", "set > update"] params = { "id": ..., "dia": ..., "hora": ..., "comedero": ..., "servida": ..., } result = client.action(schema, action, params=params)  Interact set > partial_update PATCH /programacion/{id}/set Path Parameters The following parameters should be included in the URL path. Parameter Description id required A unique integer value identifying this programacion. Request Body The request body should be a "application/json" encoded object, containing the following items. Parameter Description dia hora comedero servida import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["programacion", "set > partial_update"] params = { "id": ..., "dia": ..., "hora": ..., "comedero": ..., "servida": ..., } result = client.action(schema, action, params=params)  Interact set > delete DELETE /programacion/{id}/set Elimina una instancia de Programacion. Path Parameters The following parameters should be included in the URL path. Parameter Description id required A unique integer value identifying this programacion.     Hungry Falconry API Rest  api-token-auth  comederos  programacion  users none python  Authentication  Source Code shell javascript python users import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["programacion", "set > delete"] params = { "id": ..., } result = client.action(schema, action, params=params)  Interact list GET /users/ Devuelve una lista de todos los Usuarios. import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["users", "list"] result = client.action(schema, action)  Interact read GET /users/{id}/ Devuelve una instancia de Usuario. Path Parameters The following parameters should be included in the URL path. Parameter Description id required A unique integer value identifying this usuario. import coreapi # Initialize a client & load the schema document client = coreapi.Client() schema = client.get("http://localhost:8000/docs/") # Interact with the API endpoint action = ["users", "read"] params = { "id": ..., } result = client.action(schema, action, params=params)  Interact read_0 GET /users/{id}{format} Devuelve una instancia de Usuario. Path Parameters The following parameters should be included in the URL path. Parameter Description id required A unique integer value identifying this usuario. format required