Análisis, diseño e implementación de una aplicación para dispositivos móviles multiplataforma para la comunicación entre centros educativos y padres de alumnos

Análisis, diseño e implementación de una aplicación para dispositivos móviles multiplataforma para la comunicación entre centros educativos y padres de alumnos 2017 ALUMNO JOEL DAVID DELGADO PERDOMO TUTOR DR. ALEXIS QUESADA ARENCIBIA GRADO EN INGENIERÍA INFORMÁTICA (INGENIERÍA DEL SOFTWARE) Julio 2017 - Las Palmas de Gran canaria Trabajo de Fin de Grado en Ingeniería Informática (intensificación en Ingeniería del Software) de la Universidad de Las Palmas de Gran Canaria presentado por el alumno: Joel David Delgado Perdomo Título del proyecto Análisis, diseño e implementación de una aplicación para dispositivos móviles multiplataforma para la comunicación entre centros educativos y padres de alumnos Tutor Dr. Alexis Quesada Arencibia Agradecimientos A mi tutor Alexis Quesada Arencibia, por apoyarnos y recibirnos con los brazos desde el primer día, haciendo lo imposible por atendernos. A mi compañero y amigo Adrián Louro Alonso, por haberme acompañado en este proyecto y haberme ayudado tanto durante la carrera. Al grupo Monóxido Ferroso, sin vosotros no estaría aquí. A mi familia, novia y amigos, por apoyarme siempre desde el primer crédito hasta el último. Resumen En la actualidad la tecnología está presente en todas partes. Pero existiendo alternativas tecnológicas aún seguimos haciendo uso de herramientas tan tradicionales, como el papel. Su fabricación conlleva una serie de desventajas hacia el medioambiente, que puede ser paliado haciendo uso de alternativas. Uno de los usos más populares consiste en el papeleo escolar. Millones de hojas son utilizadas cada año para realizar encuestas, autorizaciones, o circulares escolares, con uso único y desechadas después de cumplir su objetivo, la mayoría de las veces sin reciclarse. Como alternativa, proponemos un sistema que posibilita a centros y padres para comunicarse de manera rápida, sencilla, directa y económica, permitiendo además que los padres puedan las firmar autorizaciones de sus hijos. Abstract Nowadays, technology is present everywhere. But with technologic alternatives we still use some of the most traditional tools, like paper. Its making carry a series of disadvantages to the enviroment, that can be mitigated using alternatives. One of the most populars uses consists in scholar papelwork. Millions of paper sheets are used every year to make scholar polls, authorizations, or circulars, with a single-time use and they are discarded after being used, the most of them without recycling. As an alternative, we purpose a system that enables the communication between centres and parents in a fast, simple, direct and economic way, allowing as well parents to sign authorizations for their children. Índice de tablas Tabla 1: Resumen de casos de uso .............................................................................................. 34 Tabla 2: Especificaciones de casos de uso (Responder autorizaciones) ..................................... 35 Tabla 3: Especificaciones de casos de uso (Responder encuestas) ............................................. 35 Tabla 4: Especificaciones de casos de uso (Cambiar código de seguridad) ................................ 36 Tabla 5: Especificaciones de casos de uso (Añadir centro/s) ...................................................... 37 Tabla 6: Contenido de las tablas de la Base de Datos ................................................................. 44 1 Introducción El malgasto de los recursos del planeta en general nos parece un problema fundamental en nuestro sistema sociocultural. Por ello, hemos decidido realizar un proyecto que pueda colaborar a remediar este hecho en la medida de lo posible y de lo que nuestros conocimientos en la informática y nuestra capacidad de buscar soluciones nos lo permitan. Hemos decido centrarnos en una actividad que, si bien cotidiana, tiene como resultado un consumo de papel que creemos innecesario con las tecnologías disponibles hoy en día. Por ello, hemos decidido realizar una propuesta para los centros educativos para evitar el método actual y poco amigable con el medio ambiente de comunicación con los padres. La finalidad de nuestra propuesta es poner fin al uso del papel para enviar mensajes de carácter general y/o autorizaciones a los padres por parte de los centros educativos. Por consiguiente, hemos desarrollado una solución que permite a los centros enviar distintos tipos de mensajes con uno o varios administradores encargados de gestionar dicha mensajería a los padres de sus alumnos (autorizaciones de actividades, circulares de carácter general y encuestas) y que estos últimos puedan visualizarlas en sus dispositivos móviles e incluso responderlas desde el mismo, evitando costes y ofreciendo una alternativa más actualizada y respetuosa con el ecosistema. En este Trabajo de Fin de Grado en concreto nos centraremos en la aplicación móvil dedicada a los padres, en la que podrán visualizar el contenido de los tres tipos de mensajes anteriormente mencionados y responder en consecuencia a aquellos en los que se solicite una respuesta, más específicamente, se permitirá autorizar o desautorizar a los hijos/as a asistir a actividades propuestas por el centro, así como responder a encuestas solicitadas por el centro para mejorar su comunicación con el mismo. La aplicación destinada a ser gestionada por el centro será desarrollada por Adrián Louro Alonso en el Trabajo de Fin de Grado titulado: “Análisis, Diseño e Implementación de un Backend para la Comunicación entre Centros Educativos y Padres de Alumnos”, en la que se permitirá a uno o a varios administradores enviar autorizaciones, encuestas y circulares a los padres, además de permitir visualizar los resultados que se envían desde la aplicación cliente a desarrollar en este Trabajo de Fin de Grado. Como se previó necesario, hemos además diseñado y desarrollado un servicio web RESTful que, haciendo uso de una capa de acceso a datos perteneciente al backend diseñado en el Trabajo de Fin de Grado encargado del mismo, permita a nuestra aplicación móvil acceder a la base de datos de la aplicación. 2 Estructura del documento Esta memoria está separada por capítulos, que procederemos a describir brevemente en las siguientes líneas: 1. Estado actual y objetivos iniciales Establecemos el punto de partida del proyecto, detallando la situación actual del problema, competidores de nuestra propuesta y los objetivos que nos hemos propuesto alcanzar con el proyecto. 2. Competencias específicas cubiertas Enumeramos y justificamos cómo se han alcanzado las competencias cubiertas durante la realización del proyecto. 3. Aportaciones Detallamos cuáles son las aportaciones que tiene nuestro proyecto en el apartado socioeconómico y cuál ha sido el impacto personal que ha tenido en nosotros. 4. Normativa y legislación Explicamos nuestro análisis de la normativa y legislación vigente y qué medidas hemos tomado en el proyecto para adoptarlas, se incluyen también información sobre las licencias utilizadas de los diferentes productos software utilizados durante el desarrollo del proyecto. 5. Metodología de trabajo y planificación del proyecto Especificamos cuál de las diferentes metodologías de trabajo hemos escogido y justificamos nuestra elección además de mostrar cuál ha sido la planificación del proyecto. 6. Tecnologías y herramientas utilizadas Introducimos cuáles han sido las tecnologías escogidas para trabajar en el proyecto, así como las herramientas utilizadas para ello. 3 7. Análisis Señalamos y detallamos el análisis realizado del proyecto, así como la identificación de requisitos funcionales y la esquematización de los mismos mediante diagramas de casos de uso. 8. Diseño Definimos el diseño y la arquitectura bajo los cuáles se ha construido el sistema. Además, estos se justifican debidamente y se detalla su implementación y funcionamiento. Añadimos también el diseño utilizado para nuestra base de datos. 9. Desarrollo Visualizamos de manera sencilla cómo ha sido el desarrollo en el proyecto, justificando la elección del framework escogido, la estructura de archivos de la aplicación móvil, y como se ha configurado y utilizado el paquete escogido para desarrollar nuestra API Restful. 10. Pruebas Describimos las pruebas que hemos realizado para validar el funcionamiento de la aplicación, separadas por pruebas de usabilidad y pruebas de integración. 11. Resultados, conclusiones y trabajo futuro Concluimos con el desarrollo de la memoria, señalando cuales han sido nuestras reflexiones, resultados finales y los posibles cambios y mejoras que se podrían introducir en el sistema en el futuro. 12. Bibliografía Enunciamos todas las referencias a las que se ha hecho alusión durante la memoria, sus autores y sus fuentes respectivas. 13. Anexos I. Explicamos de manera concisa y sencilla cómo hacer uso de la aplicación móvil. II. Explicamos cómo instalar el sistema de la aplicación móvil y la API Restful para poder utilizarla en escritorio. III. Adjuntamos un script de sentencias SQL que dan como resultado la base de datos utilizada durante el transcurso del proyecto. 4 1. Estado actual y objetivos iniciales 1.1 Estado actual 1.1.1 Alternativas Existentes Si queremos que nuestra aplicación tenga éxito, primeramente, deberemos asegurarnos de que problema queremos resolver. Una vez decidido este punto, debemos comprobar que competidores posibles tenemos en nuestro entorno, y como satisfacen los mismos las necesidades del usuario y cómo solventan el problema. Si conseguimos ofrecer alternativas a dichas soluciones, o mejores soluciones en general, podremos mejorar la probabilidad de éxito de nuestra aplicación incluso antes de comenzar el desarrollo de la misma. Teniendo en cuenta esta premisa, hemos decidido realizar un análisis del mercado actual para ver que soluciones existen al problema de comunicación entre Centros y Padres haciendo uso de las nuevas tecnologías. A continuación, procederemos a enumerar dichas soluciones, así como comentar que carencias encontramos en las mismas y que no existen en nuestro primer concepto de aplicación. • [1] miColegioApp: ▪ Para el centro: permite el envío de circulares y adjuntar documentos a los mismos. ▪ Para los padres: confirmar citas, firmar autorizaciones. ▪ No permite: realización de encuestas y auto-importación de datos. • [2] TokApp: ▪ Para el centro: importación de datos, permite el envío de mensajes entre profesores y alumnos. ▪ Para los padres: contactar con los profesores, con los alumnos y con el centro sin restricciones. ▪ No permite: Firmar autorizaciones, enviar mensajes de un tipo específico de contenido, restringir la comunicación entre padres/profesores/centro. • [3] ClickEdu: ▪ Para el centro: contabilidad, gestión de recursos del centro, gestión de boletines de notas, actividades extraescolares, realización de exámenes, entrega de trabajos. ▪ Para los padres: Avisos, Emails: ▪ No permite: Firmar autorizaciones, responder encuestas, autoimportación de datos. 5 • [4] Remind: ▪ Para el centro: creación de grupos de alumnos/ profesores/padres en forma de chats, envío de circulares. ▪ Para los padres: comunicación vía chat con cualquier profesor, alumno o padre. ▪ No permite: firmar autorizaciones, responder encuestas, enviar circulares a todos los usuarios, auto-importación de datos. • [5] ClassDojo: ▪ Para el centro: permite al profesorado crear una red social con sus alumnos, valorar sus comentarios, enviar mensajes a sus alumnos en específico. ▪ Para los padres: Permite visualizar fotografías tomadas en clase o en actividades por parte de los padres, actualizaciones por parte del profesor y comunicación privada con el profesorado. ▪ No permite: restringir la comunicación padre/profesorados, envío de circulares, envío de encuestas, adjuntar documentos, enviar encuestas. 1.1.2 Conclusiones Como hemos podido observar, en general tenemos dos grupos de aplicaciones: • Las primeras están destinadas a la gestión completa del centro: boletines de notas, calificaciones, gestión de salarios, contabilidad, horarios, realización de exámenes, entregas de trabajos, etc. Por ello, el apartado de la mensajería flaquea y es de carácter general, no suelen permitir diferenciar entre mensajes de carácter informativo de aquellos que requieren de una retroalimentación por parte de los padres. • Las segundas están destinadas a la mensajería, pero a una mensajería de carácter individual o de grupos pequeños, teniendo los chats como abanderados. Este tipo de aplicaciones es efectivo para tener comunicación en tiempo real y volcar contenido multimedia, pero no lo es tanto para el envío más general de información o documentación, como son las circulares, las encuestas o autorizaciones. Además de lo mencionado, ambos tipos de aplicación suelen carecer de la autoimportación de datos, algo que consideramos esencial, debido a lo tedioso que puede ser realizar la importación de cientos de alumnos y sus respectivos padres de manera manual. 6 Respecto a la mensajería, nuestra aplicación se centra más en la información general y de carácter oficial, y permite suplir la mensajería individual que las alternativas ofrecen, sin llegar a proporcionar un libre albedrío a la hora de comunicarse con el centro o el profesorado: toda la comunicación se realiza desde el centro y es este el que decide si desea una respuesta y de qué tipo específico la desea. Por último, ambos grupos cuentan con aplicaciones pensadas para ser utilizadas por padres acostumbrado a las interacciones más modernas pero que pueden ser no tan intuitivas, y nuestra solución brinda la facilidad de uso por su claridad y sencillez, intentando ser lo más intuitiva y clara posible. 1.2 Objetivos El objetivo principal de nuestra solución es ofrecer una solución sencilla, amigable con el medioambiente y viable incluso para aquellos centros con infraestructuras mínimas y personal inexperto. En el caso específico de este Trabajo de Fin de Grado, los objetivos son claros: • Ofrecer una interfaz de usuario sencilla, clara e intuitiva. • Proporcionar siempre al usuario transparencia sobre que acciones realiza en la aplicación. • Garantizar la seguridad del usuario, la privacidad de sus datos y que centros pueden verlos y sobre cuando realizamos acciones que sustituyen a la firma tradicional. • Asegurarnos de que la información de los centros y la retroalimentación que estos requieren llegue a los padres y no se extravíe como podría suceder con métodos más tradicionales. Para ello, desde la aplicación móvil, la interfaz está diseñada en un modelo de pestañas, con iconos claros y que representan las diferentes secciones de la aplicación, se informa de manera activa y retroactiva al usuario cuando accede al contenido de los mensajes y de cuando envía respuestas a los mismos y los padres sólo deberán introducir su número de teléfono para iniciar sesión y su nombre y apellidos si nos encontráramos en el registro. La asignación de padres/alumnos se realizaría por parte del centro. 7 2. Competencias específicas cubiertas 2.1 Comunes a la Ingeniería Informática CII01 Capacidad para diseñar, desarrollar, seleccionar y evaluar aplicaciones y sistemas informáticos, asegurando su fiabilidad, seguridad y calidad, conforme a principios éticos y a la legislación y normativa vigente. Durante el proyecto hemos tenido que diseñar y desarrollar la aplicación móvil para los padres, así como evaluar que funciona en todas las condiciones, que cumple los requisitos de seguridad y de calidad establecidos para los mismos, así como asegurar que sólo los centros que un padre seleccione tendrán acceso a su información, para cumplir con la normativa y legislación vigente de protección de datos. CII03 Capacidad para comprender la importancia de la negociación, los hábitos de trabajo efectivos, el liderazgo y las habilidades de comunicación en todos los entornos de desarrollo de software. Debido al carácter colaborativo del proyecto, ha sido de vital importancia establecer una buena comunicación entre los dos autores de las dos partes que componen el mismo. Por ello, sobre todo en las fases de análisis y diseño, colaboramos íntimamente con el autor del Trabajo de Fin de Grado encargado del backend, para así poder evitar en gran medida posibles problemas que pudieran surgir posteriores al desarrollo de integración de ambas aplicaciones. CII08 Capacidad para analizar, diseñar, construir y mantener aplicaciones de forma robusta, segura y eficiente, eligiendo el paradigma y los lenguajes de programación más adecuados. Debido al carácter original del proyecto, hemos tenido que ejecutar todas y cada una de las fases de un proyecto: desde el análisis, pasando por el diseño, hasta el desarrollo. Como el prototipo final escogido de nuestra aplicación requería ser multiplataforma, hemos estudiado las distintas opciones de tecnologías disponibles, escogiendo finalmente Ionic como framework del desarrollo. Para poder comunicarnos con el backend debíamos también desarrollar un servicio web RESTful en el proyecto del mismo, basado en Symfony. Por ello decidimos utilizar el paquete Friends Of Symfony que nos permite una configuración sencilla y una implementación mecánica de los métodos requeridos en el servicio. 8 CII012 Conocimiento y aplicación de las características, funcionalidades y estructura de las bases de datos, que permitan su adecuado uso, y el diseño y el análisis e implementación de aplicaciones basadas en ellos. Debido a las dimensiones del proyecto, nos hemos visto obligados a realizar un análisis exhaustivo y un diseño preciso de la base de datos del sistema, y haciendo uso de un Object-Relational Mapping hemos conseguido poder generar objetos a partir de los datos. Con ello hemos sacado partido de las ventajas que nos proporciona la programación orientada a objetos aprendidas durante el grado. CII013 Conocimiento y aplicación de las herramientas necesarias para el almacenamiento, procesamiento y acceso a los Sistemas de información, incluidos los basados en web. Dado que el proyecto completo consta de dos aplicaciones, como ya se ha mencionado previamente, se necesita desarrollar una API que nos permita comunicar ambas aplicaciones sobre el mismo sistema de base de datos. CII016 Conocimiento y aplicación de los principios, metodologías y ciclos de vida de la ingeniería de software. Realizando una comparación entre los distintos ciclos de vida y los principios de los mismos, concluimos que dada nuestra manera de trabajar la mejor opción a escoger sería el desarrollo basado en prototipos, permitiéndonos generar en cada iteración un prototipo funcional que nos permitiera validar los requisitos del usuario, así como comprobar la integración de nuestra aplicación y la del compañero que trabajaba en el backend del proyecto. CII017 Capacidad para diseñar y evaluar interfaces persona computador que garanticen la accesibilidad y usabilidad a los sistemas, servicios y aplicaciones informáticas. Por el formato móvil de nuestra aplicación, resultó muy importante identificar los elementos a destacar dentro de nuestra interfaz, simplificándola lo mayor posible para conseguir una destacable facilidad de uso y sencillez. Se han utilizado como base para ello los contenidos aprendidos en la asignatura de Diseño de Interfaces de Usuario, así como otros adquiridos durante nuestra formación. 9 CII018 Conocimiento de la normativa y la regulación de la informática en los ámbitos nacional, europeo e internacional. Hemos realizado una búsqueda concisa en referencia a aquellos apartados de la legislación actual que se aplican en los distintos apartados de nuestra aplicación, para cumplir de manera adecuada con la normativa y regulación vigentes. 2.2 Trabajo Fin de Grado TFG01 Ejercicio original a realizar individualmente y presentar y defender ante un tribunal universitario, consistente en un proyecto en el ámbito de las tecnologías específicas de la Ingeniería en Informática de naturaleza profesional en el que se sinteticen e integren las competencias adquiridas en las enseñanzas. Teniendo en cuenta que es un proyecto complejo, y además original, hemos tenido que pasar por todas las fases de un desarrollo de proyecto completo que nos ha permitido emplear muchos de los conocimientos adquiridos en el grado. 2.3 Ingeniería del Software (IS) IS01 Capacidad para desarrollar, mantener y evaluar servicios y sistemas software que satisfagan todos los requisitos del usuario y se comporten de forma fiable y eficiente, sean asequibles de desarrollar y mantener y cumplan normas de calidad, aplicando las teorías, principios, métodos y prácticas de la ingeniería del software. Utilizando una metodología de software hemos conseguido simplificar la organización de nuestro proyecto, así como realizar un seguimiento y validación de que el mismo satisfacía las necesidades del usuario. Además, haciendo uso de distintas prácticas de la ingeniería del software hemos conseguido generar un sistema fiable, eficiente y robusto, sin perder la flexibilidad de por medio. 16 4.1.4 Licencia MIT [12] La licencia MIT es una Licencia de software libre permisiva lo que significa que impone muy pocas limitaciones en la reutilización y por tanto posee una excelente compatibilidad de licencia. La licencia MIT permite reutilizar software dentro de software propietario. Por otro lado, la licencia MIT es compatible con muchas licencias copyleft, como la GNU GPL (software con licencia MIT puede integrarse en software con licencia GPL, pero no al contrario). El texto de la licencia no tiene copyright, lo que permite su modificación. Esta licencia permite reutilizar el software así licenciado tanto para ser software libre como para ser software no libre, permitiendo no liberar los cambios realizados al programa original. También permite licenciar dichos cambios con licencia BSD, GPL u otra cualquiera que sea compatible (es decir, que cumpla las cláusulas de distribución). Con esta licencia se tiene software libre. Ejemplos en los que podría interesar su aplicación serían las licencias duales, si se pretende difundir un estándar mediante una implementación de referencia, o si simplemente se pretende que el producto sea libre sin mayores consideraciones. La licencia MIT es utilizada por los siguientes productos software usados en el desarrollo: Symfony, Doctrine, JQuery, Ionic, NodeJS, MomentJS, Angular Moment, Ionic Filter Bar y Atom. 4.1.5 Licencia para educación de JetBrains [13] La licencia de JetBrains para educación tiene un formato de suscripción anual y es gratuita para los miembros de la comunidad universitaria. No obstante, comprende una serie de restricciones en lo que respecta a su uso, por lo que no se permite: • Alquilar, reproducir, modificar, adaptar, crear trabajos derivados, vender, sublicenciar o transferir los productos, o proveer dicho producto asociado a nuestra cuenta a terceros. • El uso de ingeniería inversa, descompilar, desensamblar, modificar, traducir los productos o cualquier intento de descubrir el código fuente de los productos. • Eliminar u ocultar cualquier aviso de propiedad o de otro tipo contenidos en los productos. • Usar los productos para propósitos comerciales. Dicha licencia se ha utilizado en el IDE PhpStorm. 17 4.1.6 Licencia de Justinmind [14] Justinmind considera las siguientes declaraciones en lo que respecta al copyright y a los derechos de propiedad: 1. Justinmind o sus proveedores son los propietarios de los derechos de propiedad intelectual de cualquier y todos los componentes protegibles del Servicio, incluyendo por tanto al nombre del Servicio, trabajo artístico y elementos de la interfaz de usuario final contenidos en el Servicio. No se permite copiar, modificar, adaptar, reproducir, distribuir, realizar ingeniería inversa, descompilar, o desensamblar cualquier aspecto del Servicio de los cuáles Justinmind o sus proveedores sean propietarios. 2. Justinmind no reclama los derechos de propiedad intelectual del Contenido que sea subido o proveído al Servicio. Sin embargo, si se usa el Servicio para enviar contenido, se está de acuerdo en que otros puedan ver y compartir el Contenido. Esta licencia va ligada al producto Justinmind Prototyper. 4.1.7 Licencia para educación de Office 365 [15] La licencia para educación de Office 365 destinada a la Universidad enumera las siguientes restricciones en lo que respecta su uso: 1. Debe ser un “Usuario educacional cualificado” para suscribirse y utilizar el servicio y el software de edición “University”. 2. Suscripción No para reventa. Las tarjetas de suscripción No para reventa se distribuyen con propósitos limitados. No puede vender las tarjetas de suscripción identificadas como “NPR” o “No para reventa”. 3. Programas de terceros. El software puede incluir programas de terceros que Microsoft, no los terceros, le licencia a usted conforme a este contrato. Las notificaciones, si las hay, para el programa de terceros se incluyen para su información solamente. 4. Microsoft le concede una licencia para copiar, distribuir, realizar y mostrar elementos multimedia (imágenes, imágenes prediseñadas, animaciones, sonidos, música, clips de vídeo, plantillas y otro contenido) incluidos con el servicio y/o el software en proyectos y documentos; sin embargo, no puede: (i) vender, licenciar ni distribuir copias de elementos multimedia por sí mismos o como un producto, si el valor principal del producto son los elementos multimedia; (ii) conceder a sus clientes el derecho de volver a licenciar o distribuir los elementos multimedia; (iii) licenciar o distribuir para propósitos comerciales elementos multimedia que incluyan la manifestación de personas, gobiernos, logotipos, marcas o emblemas identificables, o utilizar estos tipos de imágenes de maneras que pudieran implicar una aprobación o una asociación 18 con su producto, entidad o actividad; o (iv) crear trabajos obscenos o escandalosos mediante los elementos multimedia. Otros elementos multimedia, a los que se puede acceder en otros sitios web a través de las características de Office, se rigen por los términos de esos sitios web. Se ha utilizado dicha licencia en el producto software Microsoft Word 2016. 4.2 Seguridad de los Datos [16] La Ley Orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal, (LOPD), es una ley orgánica española que tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente de su honor, intimidad y privacidad personal y familiar. Su objetivo principal es regular el tratamiento de los datos y ficheros, de carácter personal, independientemente del soporte en el cual sean tratados, los derechos de los ciudadanos sobre ellos y las obligaciones de aquellos que los crean o tratan. Esta ley afecta a todos los datos que hacen referencia a personas físicas registradas sobre cualquier soporte, informático o no. Para cumplir con esta ley, se debe garantizar que la protección de datos personales es un elemento presente en todos aquellos apartados relacionados de nuestra aplicación, en especial en lo que respecta a información almacenada, esto es: en la base de datos. En el caso específico de nuestra aplicación, para cada persona física se recogen los siguientes datos: • Nombre y Apellidos. • Número de teléfono personal. Por lo tanto, figuran en el denominado [17] Nivel básico por lo que se deben garantizar los siguientes requisitos y se han adoptado las siguientes medidas: • Dicha información no es accesible por cualquier persona, y sólo aquellos habilitados para ello tendrán acceso a ella. ▪ Para ello, hemos garantizado que dicha información sólo será visible por los propietarios de la misma, así como únicamente por los Administradores designados por el centro para hacer uso del sistema. ▪ El acceso a la base de datos está protegido por contraseña, garantizando que solo personas integrantes del equipo de desarrollo de la empresa puedan acceder a ella. ▪ La información referente a los padres será únicamente visible para aquellos centros que los padres hayan configurado para ceder su información durante la configuración inicial de su cuenta. 19 • Esta información tiene que ser necesaria además de contar con fines determinados explícitos y explícitos, garantizando que no se usarán para otros fines que no sean los acordados. Nunca se exigirá al usuario de la aplicación datos innecesarios o superfluos conforme a lo requerido para el correcto funcionamiento de la aplicación. • Se garantiza que la toma de decisiones en las autorizaciones por parte de los padres para actividades de los centros está protegida por contraseña, siendo únicamente los padres los conocedores de la misma, en forma de un código de seguridad de 4 dígitos. • El sistema garantiza a que dichos datos sólo serán albergados en su base de datos durante el tiempo necesario para cumplimentar la funcionalidad que se requiere por parte de los centros. En caso de no ser necesarios en cierto punto, serán eliminados de la base de datos del sistema, previa solicitud por parte del centro o de un padre/madre. 20 5. Metodología de trabajo y planificación del proyecto Metodología de trabajo En lo que a la metodología de trabajo respecta hemos escogido basarnos en el [18] modelo de ciclo de vida del software basado en prototipos pues es la mejor que se adapta a nuestra forma de trabajo, teniendo en cuenta que el proyecto tiene dos aplicaciones independientes nos permitía poder construir nuestras aplicaciones de manera incremental e ir verificando en cada etapa que se alcanzaban los objetivos y se validaban los requisitos considerados en el análisis junto a la ayuda de nuestro tutor. Para explicar mejor en que consiste este ciclo de vida, primeramente, definiremos que es un prototipo: Los prototipos son una representación limitada de un producto, que permite a ambas partes interesadas en el desarrollo (cliente y desarrollador) probarlo en situaciones reales o explorar su uso, creando así un proceso de diseño de iteración que genera calidad. Teniendo claro lo que es un prototipo procedemos a incidir en la metodología de desarrollo basada en prototipos. Este tipo de metodología pertenece a los modelos de desarrollo evolutivo, por tanto, se establece una primera implementación del proyecto, y se itera sobre este consecutivamente hasta llegar al producto final. Destacan por estar diseñados para ajustarse al cambio durante el desarrollo del proyecto, por lo que resulta ideal en un trabajo original como este. 21 Ilustración 1: Modelo de construcción de prototipos Tal y como se puede visualizar en la Ilustración 1 este modelo sigue una estructura iterativa que consta de las siguientes etapas: ▪ Plan rápido, Modelado y Diseño rápido: esta etapa se centra en la representación de aquellos aspectos visibles para el cliente. ▪ Construcción del prototipo: se construye un prototipo funcional o no, en el que el cliente valida si dichas funcionalidades son las deseadas. ▪ Desarrollo, Entrega y retroalimentación: se desarrollan las funcionalidades y se entregan al cliente, consiguiendo una retroalimentación de su parte al respecto acerca de si los requisitos han sido validados correctamente o no. ▪ Comunicación: El cliente comunica cambios que desea realizar en la implementación o posibles mejoras antes de cerrar la iteración. Por dicho funcionamiento, el modelo basado en la construcción de prototipos disfruta de las siguientes [19] ventajas e inconvenientes: Ventajas • Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. 22 ▪ En nuestro caso particular, nuestro tutor comparte la autoría de la idea original del proyecto y, por tanto, conoce en detalle cuáles son los objetivos generales de la aplicación para móvil, inclusive conociendo e ayudándonos a identificar los requisitos para la misma, lo cual es una gran ventaja. • También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humanomáquina. ▪ Dada nuestra falta de experiencia en desarrollar aplicaciones móviles y que, en general, todo desarrollo tiene margen de mejora, resulta ideal poder validar que cada implementación está yendo en la dirección adecuada para validar los requisitos del producto conforme se va realizando. • Se puede reutilizar el código. ▪ Hemos podido aprovechar durante el desarrollo código implementado durante los prototipos parcialmente funcionales, ahorrándonos trabajo y sobre todo tiempo de desarrollo para cumplir con las entregas. Inconvenientes • El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. ▪ En este caso, dado que las validaciones han sido realizadas por el tutor, sustituyendo al usuario, y que el mismo conoce las características y el proceso de esta metodología no hemos tenido ninguno de estos problemas. • En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final. ▪ Gracias a nuestra experiencia y las buenas prácticas aprendidas durante el grado hemos podido evitar en mayor medida la mala toma de 23 decisiones al realizar el prototipo y escoger las tecnologías para el desarrollo. Conclusiones A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en: • Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos. • Que el prototipo se descarte, al menos en parte. • Que después se desarrolle el software real con un enfoque hacia la calidad. Pudiendo tener estas condiciones claras y siguiendo las indicaciones del tutor en el papel de cliente, al final esta metodología nos ha aportado muchas ventajas y muy pocas desventajas reales, claro que todo ello es debido a la naturaleza de nuestro cliente por lo que dichos resultados no deben desvirtualizarse y generalizarse, pues la metodología basada en prototipos aún contempla ciertos riesgos. 5.2 Planificación del proyecto 5.2.1 Planificación inicial Para realizar una planificación correcta del proyecto, primeramente, realizamos un estudio del estado del arte, para poder identificar cuáles eran los usuarios principales de nuestra aplicación, así como que funcionalidades requerirían los mismos dentro de nuestro sistema. A partir de esta información pudimos identificar mejor cuáles serían los actores de nuestro sistema y que requisitos funcionales precisaba nuestro sistema. Para representar esta información y tenerla a nuestra disposición de manera clara y sencilla, construimos una serie de diagramas de casos de uso, con sus respectivas tablas de especificación, donde se detalla al completo la funcionalidad a implementar. Realizada dichas representaciones procedimos a validarlas con nuestro tutor, realizando los ajustes que consideramos oportunos en las mismas. Una vez actualizadas, pasamos a realizar una primera representación gráfica de la interfaz de nuestro sistema, haciendo uso del producto software Justinmind Prototyper. Dicha interfaz gráfica nos ayudó muchísimo a darnos especificar mejor las funcionalidades que habíamos definido, así como a identificar algunas que nos habíamos planteado. Sumándose a esto, nos permitió visualizar cómo interaccionarían los usuarios con sus aplicaciones y sus respectivas funcionalidades. 24 Para continuar, teníamos que definir bien cuál iba a ser la arquitectura de nuestro sistema, hecho esto, deberíamos realizar un análisis de las tecnologías disponibles para el desarrollo del sistema, ver sus distintas ventajas e inconvenientes para nuestra aplicación, y realizar una elección en base a cuál de ellas se adaptaba mejor a nuestras necesidades. Al final nos acabamos decantando por las tecnologías de Ionic y AngularJS, declarándonos así abanderados de las aplicaciones móviles híbridas multiplataforma. Una vez escogidas dichas tecnologías, comenzó un periodo de aprendizaje de dichas tecnologías, siguiendo las documentaciones correspondientes y realizando pequeñas aplicaciones superfluas que nos permitieran aprender lo más posible acerca de las mismas, así como ganar agilidad desarrollando con ellas. Una vez ganada cierta destreza con dichas tecnologías comenzó el desarrollo de la aplicación móvil y su servicio RESTful correspondiente. Siguiendo las directivas del modelo basado en prototipos, detallado en el apartado anterior de esta memoria, el proyecto fue dividido en una serie de iteraciones y se fueron realizando conforme al ciclo de este modelo. Dichas iteraciones consistieron en lo siguiente: 1º. Se realizó una instalación de las herramientas necesarias para el desarrollo, así como del proyecto del backend. Realizamos una primera implementación del inicio de sesión y registro en el sistema, así como de los métodos necesarios para ello en la API REST. 2º. Se desarrollaron las vistas de las distintas pestañas principales de la aplicación. Se implementaron las visualizaciones del listado y el contenido de Circulares, Autorizaciones y Encuestas, así como de la vista de Mi Perfil. 3º. Realizamos la implementación del envío de respuestas a las autorizaciones y encuestas desde la vista del contenido de las mismas, así como de los métodos del servicio web requeridos para su correcto funcionamiento. Además, se añadió el código de seguridad como método de autentificación. 4º. Se implementaron las funcionalidades respectivas a la pestaña de Mi Perfil, tales como la visualización de Mis Datos, Mis Hijos y la selección de Centros en el apartado Mi Centro. También se corrigió el flujo del inicio de sesión/registro para que incluyera un establecimiento del código de seguridad y de una selección de centros. Por ende, se añadieron también los métodos del servicio necesarios para el funcionamiento de dichas vistas. 5º. Por último, se realizó una refactorización del código en donde fue posible, ahorrando mucho código previamente escrito al comienzo del desarrollo, sustituible por directivas, así como una mejor organización de las rutas de la API para seguir las buenas prácticas propuestas por las APIs REST pragmáticas. Y para finalizar se realizó un control de errores y validación de formularios en aquellas partes de la aplicación en las que era necesario. 25 5.2.2 Ajustes de la planificación La aplicación ideada originalmente contemplaba una implementación de un sistema de tutorías entre los padres de los alumnos y el profesorado del centro. Por ende, el sistema a desarrollar era mucho más complejo, dicho sistema implicaría añadir a las funcionalidades ya existentes las que están bajo estas líneas: • Administradores del centro: ▪ Registrar profesores en el centro. ▪ Asociar profesores a un curso. ▪ Asociar un tutor a un curso. ▪ Establecer asignaturas en el centro. ▪ Asociar asignaturas a un profesor. • Profesores: ▪ Establecer un horario de tutorías. ▪ Solicitar tutorías a los padres. ▪ Ver calendario de tutorías. ▪ Confirmar tutorías. ▪ Cancelar tutorías. • Padres: ▪ Solicitar tutorías a los profesores de sus hijos. ▪ Confirmar asistencia a una tutoría. ▪ Cancelar tutorías. Conforme avanzábamos en el desarrollo, llegamos a la conclusión de que dichas implementaciones requerirían de un tiempo y adaptación a las nuevas tecnologías de las que no disponíamos. Por ello, consultando con Adrián Louro Alonso y nuestro tutor concluimos que, para cumplir con las iteraciones planificadas y los plazos de entrega con la mejor calidad posible, lo mejor sería descartar estas ideas en la implementación de este trabajo de fin de grado. 32 Ilustración 4: Diagrama de casos de uso (Gestionar autorizaciones) Ilustración 5: Diagrama de casos de uso (Gestionar encuestas) 33 Ilustración 6: Diagrama de casos de uso (Gestionar cuenta) Bajo estas líneas, especificaremos en la Tabla 1 cada uno de los casos de uso representados anteriormente en el diagrama, acompañados de una breve descripción de los mismos. ID Actor Descripción 1 Padre/Madre Se muestra el contenido de la circular seleccionada. 2 Padre/Madre Se descarga el documento adjunto a la circular que se está visualizando. 3 Padre/Madre Se muestra el listado de circulares que coinciden con el filtro introducido. 4 Padre/Madre Se muestra un listado de todas las circulares destinadas al usuario. 5 Padre/Madre Se muestra el contenido de la autorización seleccionada. 6 Padre/Madre Se descarga el documento adjunto a la autorización que se está visualizando. 7 Padre/Madre Se autoriza o desautoriza al hijo/hija de la autorización mostrada a realizar la actividad propuesta por el centro. 8 Padre/Madre Se muestra el listado de autorizaciones que coinciden con el filtro introducido. 9 Padre/Madre Se muestra un listado de todas las autorizaciones destinadas al usuario. 10 Padre/Madre Se muestra el contenido de la encuesta seleccionada. 11 Padre/Madre Se descarga el documento adjunto a la encuesta que se está visualizando. 34 12 Padre/Madre Se responde a la encuesta propuesta por el centro. 13 Padre/Madre Se muestra el listado de encuestas que coinciden con el filtro introducido. 14 Padre/Madre Se muestra un listado de todas las encuestas destinadas al usuario. 15 Padre/Madre Se cambia el Nombre y Apellidos actuales del usuario por el introducido. 16 Padre/Madre Se cambia el código de seguridad actual del usuario por el introducido. 17 Padre/Madre Se muestra un listado de los hijos/as asociados al usuario. 18 Padre/Madre Se desasocia el hijo/ha seleccionado del usuario. 19 Padre/Madre Se muestra un listado de los centros asociados al usuario. 20 Padre/Madre Se añade el centro seleccionado a la lista de centros permitidos del usuario. 21 Padre/Madre Se elimina el centro seleccionado de la lista de centros permitidos del usuario. Tabla 1: Resumen de casos de uso 7.2.2 Especificación de casos de uso Bajo estas líneas adjuntamos una serie de casos de uso, los cuáles consideramos los más relevantes de la aplicación, especificados siguiendo un modelo tabulado: CASO DE USO 7 RESPONDER AUTORIZACIONES Descripción El padre/madre autoriza o desautoriza a su hijo/a para asistir a una actividad. Actores Padre/Madre. Precondiciones El padre/madre debe haber iniciado sesión en el sistema. Flujo normal Paso Acción 1 Se accede a una de las autorizaciones de actividades. 2 Se autoriza la actividad. 3 Se introduce el código de seguridad del usuario. 4 Se responde a la autorización. Postcondiciones Se modifica la lista de autorizados para dicha actividad, añadiendo al hijo/a del padre/madre correspondiente. Variaciones Paso Acción 35 2 A Se desautoriza la actividad. Extensiones Paso Condición Caso de Uso Excepciones 3 El código de seguridad introducido no es correcto. Observaciones Tabla 2: Especificaciones de casos de uso (Responder autorizaciones) CASO DE USO 12 RESPONDER ENCUESTAS Descripción El padre/madre responde a una encuesta enviada por el centro para un tema determinado. Actores Padre/Madre. Precondiciones El padre/madre debe haber iniciado sesión en el sistema. Flujo normal Paso Acción 1 Se accede a una de las encuestas. 2 Se selecciona la respuesta/s deseada entre las mostradas. 3 Se introduce el código de seguridad del usuario. 4 Se responde a la encuesta. Postcondiciones Se registra el voto/s del padre/madre en la encuesta. Variaciones Paso Acción Extensiones Paso Condición Caso de Uso Excepciones 4 El código de seguridad introducido no es correcto. Observaciones Tabla 3: Especificaciones de casos de uso (Responder encuestas) 36 CASO DE USO 16 CAMBIAR CÓDIGO DE SEGURIDAD Descripción El padre/madre cambia el código de seguridad que estableció al registrarse/iniciar sesión. Actores Padre/Madre. Precondiciones El padre/madre debe haber iniciado sesión en el sistema. Flujo normal Paso Acción 1 Se accede a la ventana de “Mis datos”. 2 Se introduce el código actual en el formulario del código de seguridad. 3 Se introduce el nuevo código de seguridad. 4 Se introduce la repetición del código de seguridad. 5 Se realiza el cambio del código de seguridad. Postcondiciones Se establece el nuevo código y se limpia el formulario. Variaciones Paso Acción Extensiones Paso Condición Caso de Uso Excepciones 5 El código de seguridad actual no es correcto. 5 El nuevo código de seguridad no coincide. Observaciones Tabla 4: Especificaciones de casos de uso (Cambiar código de seguridad) CASO DE USO 20 AÑADIR CENTRO/S Descripción El padre/madre añade un centro/s a su lista de centros permitidos que pueden consultar su información personal. Actores Padre/Madre. Precondiciones El padre/madre debe haber iniciado sesión en el sistema. Flujo normal Paso Acción 37 1 Se accede a la ventana de “Mis Centros”. 2 Se seleccionan aquellos centros del listado que se quieren añadir. 3 Se envían los centros nuevos y se añaden a la lista ya existente. Postcondiciones Se registra el voto del padre/madre en la encuesta. Variaciones Paso Acción Extensiones Paso Condición Caso de Uso Excepciones Observaciones Tabla 5: Especificaciones de casos de uso (Añadir centro/s) 38 8. Diseño En este capítulo vamos a describir el diseño al que hemos llegado a posteriori de realizar el análisis, comenzando por el diseño de la arquitectura del sistema. 8.1 Diseño de la arquitectura del sistema La arquitectura de sistema escogida para el proyecto ha sido la arquitectura de tipo multi-nivel que procederemos a definir a continuación. [38] La arquitectura multi-nivel o por capas: en dicha arquitectura a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten). El más utilizado actualmente es el diseño en tres niveles (o en tres capas): • Capa de presentación: la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio. • Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación. • Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. 39 Ilustración 7: Instalación típica de una arquitectura multi-nivel Sobre estas líneas, en la Ilustración 7, podemos apreciar que, la capa de presentación reside en el lado de los clientes, la de negocio suele incluirse en un servidor de negociación y por último la capa de datos en el servidor que alberga la base de datos. Hemos decidido escoger esta arquitectura porque nos proporciona las siguientes ventajas: • Centralización del control: los accesos, recursos e integridad de los datos son controlados por el servidor, de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema. Esta centralización también facilita la tarea de actualizar dichos datos u otros recursos. • Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Cualquier elemento puede ser aumentado (o mejorado) en cualquier momento. • Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades entre varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o incluso trasladar un servidor, mientras que sus clientes no se verán afectados por ese cambio (o se afectarán mínimamente). Esta independencia de los cambios también se conoce como encapsulación. • Simplifica la seguridad: no es necesario aplicar políticas de seguridad complejas en las aplicaciones del cliente, ya que la lógica de negocio y los datos están alojados en un único servidor. Además, Existen tecnologías, suficientemente desarrolladas, diseñadas para esta arquitectura que aseguran la seguridad en las transacciones, la amigabilidad de la interfaz, y la facilidad de uso. En nuestro caso particular, las aplicaciones del cliente sólo tienen la capa de presentación y una capa de red que permite conectarse al servidor, y el backend de la aplicación web y la API RESTful residen en un servidor web, que sustituye a las capas de negocio, de acceso a datos y de datos. Dicha arquitectura puede observarse en detalle en la Ilustración 8 que acompaña a estas líneas. 40 Ilustración 8: Diagrama de despliegue 8.1.1 Frontend En el frontend del sistema contamos con dos aplicaciones distintas: • Aplicación móvil: en la cual, el actor principal es el padre/madre del alumno. Su funcionalidad conlleva permitir ver los mensajes enviados por la administración de los centros de sus hijos, así como responder a autorizaciones y encuestas. • Aplicación web: en ella, el actor principal es el administrador del centro. Su funcionalidad contempla permitir enviar mensajes a los padres de los alumnos, y poder visualizar qué alumnos han sido autorizados para una determinada autorización por sus padres y ver los resultados de una encuesta realizada a los padres de los alumnos. El uso de la aplicación móvil se restringirá a cualquier dispositivo móvil que los padres tengan, dado el carácter multiplataforma de nuestra aplicación. Por otro lado, el uso de la aplicación web estará restringido a un equipo de la administración que el centro designe para el uso de nuestro sistema. 8.1.2 Backend Como hemos descrito y se podía observar en la Ilustración 8 el backend de nuestro sistema se encuentra alojado en un servidor, que ejecuta un servidor web Apache que incorpora tanto la API RESTful que necesita nuestra aplicación móvil para funcionar, como el backend de la aplicación web. Tanto el backend de la aplicación móvil como el de la aplicación web están desarrollados e implementados utilizando las mismas tecnologías (Symfony3, PHP7 y Doctrine) de tal manera que ambas utilicen la misma capa de acceso a datos y evitemos un sistema repetitivo. 41 8.2 Diseño de la Base de Datos Como se mencionó en el capítulo destinado al a especificación de herramientas y tecnologías, hemos utilizado el sistema de gestión de bases de datos relacional MySQL. La estructura de dicha base de datos puede observarse en la Ilustración 9 adjunta en la siguiente página. 48 Principio 6 • Facilita el aprendizaje. • Consistencia: significado de los controles deducido a partir de ellos mismos o pistas muy fáciles, nunca valiéndonos de nuestra memoria (poner el conocimiento de uso de las coas en el mundo no en nuestro cerebro). • Evita las consecuencias de los errores, el usuario se atreverá a explorar cosas nuevas, ya que no suponen riesgo. La configuración inicial de la aplicación aclara cómo se debe seleccionar un centro, qué datos realmente se conocerán del usuario final y el avance por dicha configuración siempre está aclarado haciendo uso de grandes botones que indican la acción que se está realizando en cada etapa. Partiendo de que el uso de los controles en la aplicación está limitado a tocar y realizar un desplazamiento por el contenido, dichos controles son homogéneos en toda la aplicación. Además, ninguno de los errores que se muestran en la aplicación conlleva un efecto negativo en el usuario y en su experiencia. Principio 7 • Proporciona información al usuario, no simplemente soltarle datos. • “La pantalla le pertenece al usuario” es una forma de no alterar ese espacio en el que él se mueve. Respeta su territorio y no cambies las cosas bruscamente (inercia de la pantalla). Cuando el usuario realiza alguna actividad que debería de tener una retroalimentación, se ha implementado que tenga algún tipo de respuesta gráfica. Por ejemplo, cuando el usuario autoriza o desautoriza una autorización, se actualiza la interfaz (no se cambia bruscamente) y se muestra un mensaje indicando el estado de la autorización, así como el único botón que permite “Desautorizar” en caso de haber autorizado, y “Autorizar” en el caso contrario. Principio 8 • Diseña para la interactividad entre la aplicación y el usuario. • Respetar el tiempo del usuario. El tiempo del usuario es vital, por ello, se ha diseñado la aplicación para que la navegación por la misma sea rápida, con el menor tiempo de espera y mostrando el menor número de pantallas posible sin repercutir en la sencillez de uso. 49 Principio 9 • Prueba los diseños con usuarios reales, es decir: Test y Verificación. • Corrige los fallos. Además de las pruebas de la aplicación realizadas con el Tutor para validar los requisitos funcionales, se hicieron pruebas con usuarios potenciales para verificar si el diseño cumplía con su cometido y si todas las funcionalidades se ejecutaban correctamente. Gracias a esto, se descubrieron algunos errores que no se habían identificado durante las pruebas del desarrollo y se corrigieron debidamente. 50 9. Desarrollo 9.1 Ionic Ionic es un SDK móvil atractivo, gratuito y de código abierto para desarrollar aplicaciones web nativas y progresivas con facilidad. Las principales que obtenemos de usar Ionic como framework principal de desarrollo y por las que nos hemos decantado para hacerlo son: • El desarrollo principal se realiza en HTML junto con CSS y JS, lenguajes muy extendidos por la comunidad de desarrolladores, con lo que la implantación de esta herramienta en la empresa facilitará el desarrollo de proyectos de la forma más efectiva aun cuando la plantilla de desarrolladores contenga nuevas incorporaciones. • Si ya contamos con una web app que queremos convertir en aplicación móvil, en la mayoría de los casos habremos hecho uso de JavaScript, por lo que el código es reutilizable. • Para el caso de aplicaciones híbridas, tendremos con un único proceso de desarrollo e implementación, una app para Android, iOS y web. • AngularJS: Ionic trabaja perfectamente con AngularJS. Dando lugar a una arquitectura robusta para el desarrollo de apps. Podremos crear apps móviles ricas y robustas, para subir desde la plataforma a tu tienda de aplicaciones a escoger. • Es fácil de entender: no tremos que complicarnos en exceso utilizando Ionic, es bastante sencillo de entender. Si ya hemos programado alguna aplicación para iOS o Android, seguro que nos entenderemos bien con el SDK, pues con Ionic también. Permite desarrollar un código una vez y reutilizarlo las veces que quieras ya que desde una única fuente podremos llegar a las plataformas que soporta este framework (Android e iOS). • Pulcro: Ionic es moderno y está diseñado para trabajar con lo más actual, con un diseño limpio y pulcro. Los componentes son atractivos, la tipografía, etc. • Crea, construye, prueba y compila: con Ionic podremos crear, construir, y compilar aplicaciones en cualquier plataforma, todo con un solo comando. Por eso se considera un potente CLI. • Funciona rápido: si no disfrutamos de excesiva paciencia, nos gustará Ionic. Está hecho para ser rápido. • Ionic Creator: una de las ventajas de Ionic, es Ionic Creator. Básicamente nos permite crear las Interfaces sin tener que meter el código de manera tradicional. Podremos crear la parte gráfica fácil sin apenas escribir código para ello. • Construído y mantenido por diseñadores y desarrolladores. 51 9.2 Estructura de la aplicación Las aplicaciones de Ionic están construidas haciendo uso de Cordova. Cordova es un conjunto de HTML/CSS/JavaScript empaquetados que permiten ejecutar el código en dispositivos móviles y en escritorio, y nos provee de una arquitectura de complementos para acceder a funcionalidades nativas más allá de lo que podría hacer un código JavaScript en una aplicación web. Por esto, las aplicaciones de Ionic tienen [42] la estructura de archivos de Cordova. En la Ilustración 11 que acompaña a estas líneas podemos observar la estructura principal de nuestro proyecto, de la cual procederemos a detallar a continuación el contenido de los directorios más relevantes. Ilustración 11: Estructura de archivos de la aplicación • hooks: se utiliza para almacenar las acciones personalizadas que queremos que se realicen en nuestra aplicación durante el proceso de desarrollo de Cordova. Puede sernos útil en grandes proyectos que requieran de procesos automatizados de ejecución y modificación de código, pero normalmente no lo usamos. • platforms: contiene nuestros proyectos de iOS y Android. En general, no necesitamos trabajar en esos directorios a no ser que estemos hacking nativo personalizado o llevando nuestras aplicaciones a producción. • plugins: es el directorio donde Cordova almacena los plugins añadidos al proyecto haciendo uso del comando: ionic cordova plugin add {plugin} • scss: almacena el archivo SASS para nuestra aplicación. El uso de SASS es opcional en Ionic, pero de por sí Ionic está construido con SCSS, por lo que hay muchos estilos por defecto que se pueden cambiar y personalizar rápidamente sin añadir ninguna sobre-escritura a los CSS de la aplicación. • www: es el directorio donde desarrollamos nuestra aplicación. 52 Ilustración 12: Estructura del directorio www En la Ilustración 12 podemos observar el contenido del directorio www del cuál mencionaremos también qué contienen sus subdirectorios. • css: contiene o bien el archivo CSS especificado para nuestra aplicación, o bien contiene el archivo de salida generado por nuestro SCSS, que debemos usar junto al resto de archivos CSS que deseamos utilizar. La carpeta css está enlazada a nuestro proyecto bajo la etiqueta <link> en el archivo index.html. • js: por defecto, en este directorio se incluyen los siguientes archivos enumerados a continuación. ▪ app.js: contiene nuestros métodos de ejecución y configuración de Angular, en él se definen las variables de entorno, por ejemplo: que tipo de estilo de pestañas usar si de iOS o Android. ▪ controllers.js: contiene nuestros controladores de Angular para los estados que así lo requieran. ▪ directives.js: contiene las directivas de Angular personalizadas que deseemos utilizar. ▪ routes.js: define el enrutamiento de nuestra aplicación, así como los distintos estados que existen en la misma y la vista que requiere mostrar cada uno de ellos si la hubiera. ▪ services.js: contiene los servicios personalizados de Angular que deseemos usar, como, por ejemplo: una factory que nos permite realizar peticiones Ajax haciendo uso del módulo $http de manera sencilla. • lib: contiene las librerías de Ionic y otras librerías que hayamos instalado, como aquellas instaladas con Bower: por ejemplo, en nuestro caso, angular-moment utilizó este instalador de paquetes, por lo que el contenido de la librería yace en este directorio. • templates: en este directorio se albergan los archivos de vistas de nuestra aplicación, enlazados a estados en el archivo de routes.js. 53 9.3 API Restful Para el desarrollo de nuestra API Restful buscamos algún tipo de herramienta que nos permitiera crear un servicio web de manera sencilla partiendo del proyecto del backend que ya contaba con una capa de acceso a datos hecha, explicada en detalle en el trabajo de fin de grado correspondiente al mismo, para así poder ahorrar repetir trabajo innecesario. De entre todas las opciones acabamos decantándonos por [43] Friends of Symfony. 9.3.1 Friends of Symfony Este paquete nos provee de varias herramientas para desarrollar de manera rápida APIs RESTful y aplicaciones con Symfony. Entre sus características destacan: • Una capa de vista para habilitar la salida y formatear controladores. • Un [44] cargador personalizado de rutas que genera urls que siguen los convenios REST. • Acepta la negociación del formato de la cabecera incluyendo la manipulación de la misma para crear tipos personalizados. • Decodifica en RESTful el cuerpo de las solicitudes HTTP y de las cabeceras de aceptación. • Crea excepciones en el controlador para enviar códigos de estado HTTP apropiados. 9.3.2 Configuración de la API Para la configuración de la API requerimos de la instalación de los paquetes Friends of Symfony y Nelmio-Cors (este último permite que la API sea accesible fuera de la máquina local) y para ello deben ser correctamente configurados en el proyecto del backend del sistema. Primeramente, debemos instalar ambos componentes usando composer, desde consola ejecutamos en el directorio del backend del sistema: composer require friendsofsymfony/rest-bundle composer require nelmio/cors-bundle Una vez instalados los paquetes, debemos editar el archivo localizado en la ruta /Hermerest/App/AppKernel.php añadiendo las siguientes líneas en la sección de bundles para poder registrar los paquetes recién instalados e indicar que ahora forman parte de nuestro proyecto. new FOS\RestBundle\FOSRestBundle(), 54 new Nelmio\CorsBundle\NelmioCorsBundle(), A continuación, debemos editar la configuración del proyecto para incorporar la configuración propia de dichos paquetes, añadiendo las líneas que siguen al archivo /Hermerest/App/config/config.yml al final del mismo: # Nelmio CORS Configuration nelmio_cors: defaults: allow_credentials: false allow_origin: ['*'] allow_headers: ['*'] allow_methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'] max_age: 3600 hosts: [] origin_regex: false # Friends Of Symfony Configuration fos_rest: view: view_response_listener: 'force' formats: json: true format_listener: rules: - { path: ^/api, priorities: [ json ], fallback_format: json, prefer_extension: true } - { path: ^/, priorities: [ html ], fallback_format: html, prefer_extension: true } 55 Debemos también, añadir en la sección de Frameworks de este archivo la siguiente línea para activar la serialización: serializer: enabled: true Añadimos ahora, un directorio en el que se almacenarán las rutas configuradas para el paquete de Friends of Symfony. Dicho directorio tendrá la siguiente ruta final: src/AppBundle/Resources/config En ese directorio, crearemos el archivo api-rest-routing.yml, que incluirá las rutas del servicio web. Siguiendo una forma del estilo: api_progenitors: type: rest resource: "@AppBundle/Controller/api/ProgenitorsController.php" name_prefix: api_progenitors_ Ahora, en el archivo de enrutamiento general del proyecto, app/config/routing.yml, debemos añadir la ruta para que el paquete pueda encontrar su lista de enrutamientos: app_bundle_api: type: rest prefix: /api resource: "@AppBundle/Resources/config/api-rest-routing.yml" Por último, permitimos que se acceda al servicio web si autentificarse como administrador. Esto es necesario porque la aplicación web está protegida para forzar la autentificación como administrador. Para ello editamos el archivo /app/config/security.yml y en la sección access_control añadimos: { path: ^/api/, roles: IS_AUTHENTICATED_ANONYMOUSLY } Y ya tendríamos los paquetes configurados para hacer uso de la API en nuestro proyecto de backend. 9.3.3 Enrutamiento de la API En el servicio web de la aplicación móvil el enrutamiento hacia los métodos correctos ha sido una parte importante del desarrollo de la API. Haciendo uso del módulo $http desde Ionic hemos realizado peticiones Ajax de manera sencilla a dicho servicio web, por lo que nos pareció relevante organizar de manera correcta y homogénea dichos enrutamientos. Por este motivo hemos decidido seguir las prácticas recomendadas para realizar [45] APIs RESTful pragmáticas en la construcción de nuestra API, obteniendo los siguientes beneficios: 56 • Usa estándares web que tienen sentido. • Es amigable y entendible para el desarrollador, además de explorable con sólo visualizar la ruta de la barra de direcciones. • Es sencilla, intuitiva y consistente, no sólo fácil de usar, también agradable. • Provee la suficiente flexibilidad para proveer a cualquier interfaz de usuario. • Es eficiente, manteniendo el balance con los otros requerimientos. Para ello hemos tomado las siguientes medidas: • Hemos separado nuestra API en recursos lógicos usando nombre sustantivos que tienen sentido desde la perspectiva del consumidor de la API. • Usamos los métodos HTTP para manejar las acciones CRUD (crear, leer, actualizar y eliminar) mapeados de la siguiente manera: ▪ GET: obtenemos un recurso ▪ POST: creamos un recurso. ▪ PUT: actualizamos un recurso. ▪ PATCH: actualizamos parcialmente un recurso. ▪ DELETE: eliminamos un recurso. • Para evitar el uso de plurales irregulares, lo más sencillo es utilizar siempre el plural en los nombres de los endpoint. 57 10. Pruebas 10.1 Pruebas de usabilidad Para verificar que nuestra aplicación era satisfactoria y cumplía los objetivos que nos habíamos marcado, realizamos una serie de pruebas del prototipo solicitando a distintos usuarios finales (padres, madres y compañeros del grado con conocimientos en informática) que hicieran uso de nuestra aplicación y íbamos comprobando y solicitando que nos dieran su opinión sobre los siguientes apartados: • Verificar si la interfaz era clara, sencilla de usar, intuitiva. • Comprobar si el proceso de inicio de sesión y registro resultaba tedioso o largo de realizar. • Verificar si los usuarios, por sí mismos y sin indicaciones, eran capaces de navegar sin problemas por la aplicación y realizar las acciones que deseaban. • Asegurar que cuando se mostraba un mensaje de error, éste era claro y conciso y ayudaba al usuario a subsanarlo por si mismo. • Medir y cuantificar si los tiempos de carga resultaban o no molestos para el usuario. • Preguntar si realmente notaban alguna diferencia respecto a aplicaciones nativas en cuanto a rendimiento, fluidez o diseño. • Solicitar si recomendarían dicha aplicación a otros padres y colegios. Una vez realizadas dichas pruebas de usabilidad, vimos que nuestros objetivos habían sido cumplidos por las respuestas de los usuarios: • La aplicación es sencilla y clara de usar, no tiene demasiados adornos y se indican claramente los apartados. • El proceso de inicio de sesión es muy similar al de otras aplicaciones de mensajería, por lo que parece estándar, sencillo y rápido. • No tuvimos que aclarar a los usuarios como navegar por la aplicación, ni mucho menos que acciones podían realizarse o qué significaba algún componente de la interfaz. • Los mensajes de error son claros y ayudan mucho a darnos cuenta de qué errores se han cometido y hay muy pocos. • La aplicación es rápida, con un rendimiento muy similar al de otras aplicaciones de mensajería. • La mayoría pensó que se trataba de una aplicación nativa en el caso de los padres. Los compañeros con conocimientos en informática notaban la diferencia, pero nos comentaban que era casi inapreciable para un usuario estándar. • Todos los usuarios de prueba recomendarían el uso de la aplicación. 64 [40] Wikipedia. “Modelo-vista-controlador”, [en línea]. Disponible en: https://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador [41] Juan Méndez Rodríguez. “Reglas Empíricas de Diseño de Interfaces”, [en línea]. Disponible en: http://telepresencial1617.ulpgc.es/cv/ulpgctp17/pluginfile.php/80359/mod_re source/content/1/Tema_I_7.pdf [42] Driffty Co. “Ionic Concepts – App Structure”, [en línea]. Disponible en: http://ionicframework.com/docs/v1/concepts/structure.html [43] Fabien Potencier. “FOSRestBundle”, https://github.com/FriendsOfSymfony/FOSRestBundle [44] Fabien Potencier. “Routing (FOS Rest Bundle)”, [en línea]. Disponible en: http://symfony.com/doc/current/bundles/FOSRestBundle/5-automatic-routegeneration_single-restful-controller.html [45] Vinay Sahni. “Best Practices for Designing a Pragmatic RESTful API”, [en línea]. Disponible en: http://www.vinaysahni.com/best-practices-for-apragmatic-restful-api 65 Anexo I: Manual de usuario Introducción En este apartado procederemos a explicar concisa y precisamente las distintas funcionalidades de la aplicación web desarrollada para los padres/madres del alumnado. Se irán explicando una a una las distintas partes del programa, acompañadas de una ilustración para detallar su funcionamiento. Inicio de sesión – Registro Ilustración 13: Inicio de sesión 66 Ilustración 14: Validación por SMS En la pantalla correspondiente a la Ilustración 13, el padre/madre introduce su teléfono móvil siendo únicamente válidos aquellos de 6 dígitos. En caso de encontrar el teléfono en la base de datos del sistema, se procede a un inicio de sesión en el mismo, de lo contrario, se procede al registro del padre/madre. En la siguiente pantalla, Ilustración 14, procedemos a validar el código recibido por SMS. Esta implementación no se realizó por motivos detallados anteriormente, así que solo se muestra a modo de mock-up. El código por defecto es “123456”. 67 Ilustración 15: Establecer código de seguridad En la Ilustración 15 podemos observar que en esta pantalla sólo se requiere establecer un código de seguridad. Para ello, sólo debemos escoger un código de 4 dígitos y repetirlo donde se indica. En el caso de ser un inicio de sesión, esto es, ya estamos registrados en el sistema, la pantalla mostraría un mensaje de “Finalizar” en el botón mostrado, y nos llevaría directamente a la pantalla de Circulares. 68 Ilustración 16: Registro En la Ilustración 16 podemos observar la pantalla de registro. En ella se solicita al usuario que introduzca su Nombre y Apellidos para proceder al registro. 69 Ilustración 17: Selección de centros Como último paso del registro, se aprecia en la Ilustración 17 que se le solicita al usuario que seleccione aquellos centros a los que permitirá conocer su información personal. Una vez seleccionados uno o varios centros, procedemos a finalizar el registro y a pasar a la pantalla observada en la Ilustración 18, llamada Circulares. 70 Circulares Ilustración 18: Circulares En Circulares se aprecia la interfaz completa de la aplicación. En ella se aprecia que la misma está divida en cuatro secciones principales: Circulares, Autorizaciones, Encuestas y Mi Perfil. Iremos repasando cada una de ellas en este anexo. En circulares se aprecia en cada elemento de la lista su título, detallado en azul, un icono de un clip si dicha circular lleva un archivo adjunto, y un mensaje que nos indica hace cuánto tiempo que se ha enviado el mensaje desde la aplicación web del centro. Además, en la esquina superior derecha, puede apreciarse un icono de búsqueda, que al activarlo permitirá realizar filtrados entre las circulares, como se puede observar en la Ilustración 19. Este componente está presente en todas las secciones, salvando la de Mi Perfil. 71 Ilustración 19: Búsqueda de mensajes Si accedemos a alguno de los elementos de circulares, pasaremos a la pantalla de contenido de las mismas, apreciable en la Ilustración 20. 72 Ilustración 20: Contenido de circular En ella se pueden apreciar los siguientes elementos: en la esquina superior izquierda, podemos volver a Circulares tocando el botón de atrás. En el encabezado de la circular podemos ver el título (a veces acortado por su extensión o resolución de la pantalla), y en su contenido, de nuevo el título por si apareciera acortado, la fecha en la que la circular fue enviada, una sección de archivo adjunto si la circular lo tuviera y por último el contenido. En caso de accionar el botón del archivo adjunto, se nos redirigirá al navegado por defecto del sistema para proceder a su descarga. 73 Autorizaciones Ilustración 21: Autorizaciones En la Ilustración 21 podemos observar que el listado de Autorizaciones, así como el de Encuestas, añade además un subtítulo, que informa de la fecha límite que dicha autorización para ser respondida. Si accedemos a una de ellas nos encontraremos con la pantalla mostrada en la Ilustración 22. 80 Mis hijos Ilustración 28: Mis hijos Al acceder a esta sección (Ilustración 28) se nos presenta un listado de los hijos/as que el usuario tiene asociados. Tendremos la opción de desasociar un hijo/a realizando un simple toque en el botón de eliminar de su derecha. Esto lanzará una pequeña pantalla de confirmación, apreciable en la Ilustración 29. 81 Ilustración 29: Confirmación al desasociar hijo/a 82 Mis centros Ilustración 30: Mis centros De igual manera que en el registro, podremos marcar y desmarcar los centros que deseemos de entre el listado de todos los centros del sistema, permitiendo sólo a los marcados visualizar nuestra información personal, tal y como se ve en la Ilustración 30. 83 Anexo II: Manual de instalación En este anexo explicaremos de manera rápida como instalar la aplicación móvil en escritorio y la API en el backend del sistema. Por ello, se requiere previamente haber instalado el backend del sistema, el manual para ello se encuentra en el Anexo II del Trabajo de Fin de Grado titulado: “Análisis, Diseño e Implementación de un Backend para la Comunicación entre Centros Educativos y Padres de Alumnos”. API Para la instalación de la API Restful sólo debemos seguir los pasos de configuración previos señalados en el apartado 9.3.2 de esta memoria. Una vez hecho, simplemente copiaremos el directorio api del directorio abajo señalado y lo copiamos en la misma ruta. La localización del directorio es: /Hermerest/src/AppBundle/Controler/ Y sustituimos copiamos el directorio config del directorio abajo señalado y lo copiamos en la misma ruta. La localización del directorio es: src/AppBundle/Resources/ Aplicación móvil Para la aplicación móvil requerimos de tener instalados en el sistema los siguientes componentes: • Node.js • Cordova • Ionic En caso de no tener dichos componentes instalados en el sistema, primeramente, instalaríamos Node.js descargándolo de su página web: https://nodejs.org/en/download/ Una vez descargado e instalado, procedemos a la instalación de Cordova. Abrimos una ventana del terminal (cmd en el caso de Windows) y ejecutamos el siguiente comando: npm install -g cordova Una vez finalizada la instalación, continuaremos instalando Ionic ejecutando este comando: npm install -g ionic 84 Una vez instalado todo el software requerido podemos ejecutar nuestra aplicación de ionic, abriendo el directorio donde esté localizada y ejecutando un terminal desde esa ubicación. En el mismo, ejecutaremos el siguiente comando: npm install -g ionic Y si todo funciona correctamente, deberíamos poder ver nuestra aplicación funcionando en el explorador web. Si al intentar arrancar el servidor de pruebas locales de Ionic nos diera un error solicitando la ruta del gulp file simplemente deberemos ejecutar desde el directorio de la aplicación la siguiente secuencia de comandos para solucionarlo: npm update npm remove gulp-sass npm install gulp-sass --save-dev 85 Anexo III: Script para la base de datos DROP DATABASE IF EXISTS hermerest; CREATE DATABASE hermerest DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE USER IF NOT EXISTS hermerest; GRANT ALL ON hermerest.* to 'hermerest'@'localhost' IDENTIFIED BY 'hermerest'; CREATE TABLE centre( id int AUTO_INCREMENT, name VARCHAR(255) NOT NULL, PRIMARY KEY(id) ); CREATE TABLE administrator( id int AUTO_INCREMENT, user VARCHAR(255) NOT NULL UNIQUE, password VARCHAR(32) NOT NULL, name VARCHAR(255) NOT NULL, centre int NOT NULL, PRIMARY KEY(id), FOREIGN KEY(centre) REFERENCES centre(id) ON DELETE CASCADE ); CREATE TABLE class( id int AUTO_INCREMENT, name VARCHAR(255) NOT NULL UNIQUE, centre int NOT NULL, PRIMARY KEY(id), UNIQUE (name,centre), FOREIGN KEY(centre) REFERENCES centre(id) ON DELETE CASCADE ); CREATE TABLE student( id int AUTO_INCREMENT, name VARCHAR(255) NOT NULL, 86 surname VARCHAR(255) NOT NULL, class int, centre int NOT NULL, PRIMARY KEY(id), FOREIGN KEY(class) REFERENCES class(id) ON DELETE SET NULL FOREIGN KEY(centre) REFERENCES centre(id) ON DELETE CASCADE ); CREATE TABLE parent( id int AUTO_INCREMENT, name VARCHAR(255) NOT NULL, telephone VARCHAR(255) NOT NULL UNIQUE,72 PRIMARY KEY(id) ); CREATE TABLE student_parent( student int NOT NULL, parent int NOT NULL, PRIMARY KEY(student, parent), FOREIGN KEY(student) REFERENCES student(id) ON DELETE CASCADE, FOREIGN KEY(parent) REFERENCES parent(id) ON DELETE CASCADE ); CREATE TABLE centre_parent( centre int NOT NULL, parent int NOT NULL, PRIMARY KEY(centre, parent), FOREIGN KEY(centre) REFERENCES centre(id) ON DELETE CASCADE, FOREIGN KEY(parent) REFERENCES parent(id) ON DELETE CASCADE ); CREATE TABLE message( id int AUTO_INCREMENT, subject VARCHAR(255) NOT NULL, message TEXT NOT NULL, sendingDate TIMESTAMP NOT NULL, centre int NOT NULL, type VARCHAR(255) NOT NULL, 87 PRIMARY KEY(id), FOREIGN KEY(centre) REFERENCES centre(id) ON DELETE CASCADE ); CREATE TABLE authorization( id int, limitDate TIMESTAMP NOT NULL, PRIMARY KEY(id), FOREIGN KEY(id) REFERENCES message(id) ON DELETE CASCADE ); CREATE TABLE circular( id int, PRIMARY KEY(id), FOREIGN KEY(id) REFERENCES message(id) ON DELETE CASCADE ); CREATE TABLE poll( id int, limitDate TIMESTAMP NOT NULL, multipleChoice TINYINT(1) NOT NULL; PRIMARY KEY(id), FOREIGN KEY(id) REFERENCES message(id) ON DELETE CASCADE ); CREATE TABLE pollOption( id int AUTO_INCREMENT,73 text VARCHAR(255) NOT NULL, poll int NOT NULL, PRIMARY KEY(id), FOREIGN KEY(poll) REFERENCES poll(id) ON DELETE CASCADE ); CREATE TABLE message_student( message int NOT NULL, student int NOT NULL, PRIMARY KEY(message, student), FOREIGN KEY(student) REFERENCES student(id) ON DELETE CASCADE, FOREIGN KEY(message) REFERENCES message(id) ON DELETE CASCADE 88 ); CREATE TABLE pollReply( id int AUTO_INCREMENT, parent int, pollOption int, PRIMARY KEY(id), UNIQUE(parent, pollOption), FOREIGN KEY(parent) REFERENCES parent(id) ON DELETE CASCADE, FOREIGN KEY(pollOption) REFERENCES pollOption(id) ON DELETE CASCADE ); CREATE TABLE authorizationReply( id int AUTO_INCREMENT, authorization int, parent int, student int, authorized boolean NOT NULL, PRIMARY KEY(id), UNIQUE(parent, authorization, student), FOREIGN KEY(authorization) REFERENCES authorization(id) ON DELETE CASCADE FOREIGN KEY(parent) REFERENCES parent(id) ON DELETE CASCADE, FOREIGN KEY(student) REFERENCES student(id) ON DELETE CASCADE, ); CREATE TABLE attachment( id int AUTO_INCREMENT, name VARCHAR(255) NOT NULL, message int NOT NULL, PRIMARY KEY(id), FOREIGN KEY(message) REFERENCES message(id) ON DELETE CASCADE ); 89