Automatización de la gestión de la piscina de la UCM mediante Pista Virtual Trabajo de Fin de Grado en Grado en Ingeniería del Software, Grado en Ingeniería Informática de la Facultad de Informática, Universidad Complutense de Madrid Autores: Carlos Martín Gutiérrez. Patricia Ortiz Zamora. Director: Adrián Riesco Índice Resumen ........................................................................................................................................ 4 Summary ....................................................................................................................................... 5 Agradecimientos ........................................................................................................................... 6 Acknowledgements ....................................................................................................................... 7 1. Introducción .......................................................................................................................... 8 1.1. Motivación .................................................................................................................... 8 1.2. Objetivos ....................................................................................................................... 8 1.3. Plan de trabajo .............................................................................................................. 9 1.4. Estructura de la memoria. ............................................................................................. 9 2. Introduction ........................................................................................................................ 10 2.1. Motivation ................................................................................................................... 10 2.2. Objetives ..................................................................................................................... 11 2.3. Workplan ..................................................................................................................... 11 2.4. Memory structure ....................................................................................................... 12 3. Preliminares ........................................................................................................................ 12 3.1. Pista Virtual ................................................................................................................. 12 3.2. Tecnologías .................................................................................................................. 13 3.2.1. .NET ..................................................................................................................... 13 3.2.2. Xamarin ............................................................................................................... 13 3.3. Visual Studio ................................................................................................................ 14 3.4. Licencias ...................................................................................................................... 14 4. Requisitos ............................................................................................................................ 15 4.1. Requisitos Iniciales ...................................................................................................... 15 4.2. Requisitos Posteriores ................................................................................................. 17 4. Implementación .................................................................................................................. 19 4.1. Diseño .......................................................................................................................... 19 4.2. Explicación de la implementación. .............................................................................. 20 5. Manual de Usuario .............................................................................................................. 27 5.1. Aplicación Gestor ........................................................................................................ 28 5.2. Aplicación usuario ....................................................................................................... 30 6. Contribución de los alumnos ............................................................................................... 35 6.1. Carlos ........................................................................................................................... 35 6.2. Patricia ......................................................................................................................... 37 7. Conclusiones y trabajo futuro ............................................................................................. 38 7.1. Conclusiones................................................................................................................ 39 7.2. Trabajo futuro ............................................................................................................. 40 8. Conclusions and Future work .............................................................................................. 40 8.1. Conclusions ................................................................................................................. 41 8.2. Future Work ................................................................................................................ 42 Bibliografía .................................................................................................................................. 43 Resumen A pesar de la modernización de distintas áreas de las zonas deportivas de la Universidad Complutense de Madrid, no se ha modernizado la gestión de los accesos y reservas a las instalaciones. Sin embargo, en los últimos años se ha hecho un esfuerzo para que estas acciones puedan llevarse a cabo online a través de una aplicación móvil llamada Pista Virtual. En este contexto, en este trabajo de fin de grado presentamos una extensión de Pista Virtual a la gestión de las piscinas. La aplicación tiene varios módulos, nosotros hemos realizado la parte de la piscina de verano. En un principio iban a ser ambas piscinas, pero finalmente de la piscina de invierno no recibimos ningún requisito por lo que solo hemos implantado la piscina de verano. El módulo piscina está implementado con las tecnologías .NET y Xamarin, nuevas para nosotros en un primer momento. A día de hoy entendemos por qué Pista Virtual decidió desde un primer momento desarrollar la aplicación en C#, ya que el desarrollo multiplataforma da muchas facilidades para los distintos sistemas operativos (Android, iOS) que hoy en día son mayoritariamente utilizados. El resultado que hemos tenido de este Trabajo de Fin de Grado, es el módulo integrado en la aplicación. En él podemos tener dos roles, el de usuario o el de gestor. Para los usuarios la aplicación tiene una sección llamada Piscina en la que puedes comprar entradas para el acceso a la misma, la entrada se genera mediante un código BIDI que permite acceso al usuario para el uso y disfrute de la piscina. Para los gestores la aplicación tiene una sección llamada Entradas en la que seleccionan el día y les permiten escanear los códigos BIDI y así poder dar acceso a los distintos usuarios a la piscina. Palabras clave: Pista Virtual, Piscina UCM, .NET, Xamarin, C#, Android, iOS, usuario, gestor, acceso, Código BIDI. Summary Despite the modernization of different areas of the sports areas of the Complutense University of Madrid, the management of access and booking to the facilities have not been modernized. However, in recent years an effort has been made so that these actions can be carried out online through a mobile application called Pista Virtual. In this context, in this end-of-degree project we present an extension of Pistal Virtual to the management of swimming pools. The application has several modules, we have made part of the summer pool. At first they were going to be both pools, but at the end we did not receive any requirement about the Winter pool so we only implemented the summer pool. The pool module is implemented with .NET and Xamarin technologies, new for us at first. Today we understand why Pista Virtual decided from the first moment to develop the application in C#, since the multiplatform development gives many facilities for the different operating systems (Android, iOS) that today are mostly used. The result we have had from this Final Degree Project is the module integrated in the application. We can fin have two roles in it, the user and the manager. For the users, the application has a section called “Pool” where you can buy tickets to Access, the entry is generated by a BIDI code that allows users to entry the pool. For managers the application has a section called “Tickets” in which the users select the day and allow them to scan the BIDI codes and give access to the different users to the pool. Keywords: Pista Virtual, Pool UCM, .NET, Xamarin, C #, Android, iOS, user, manager, access, BIDI Code. Agradecimientos En primer lugar queremos agradecer a nuestro tutor, Adrián Riesco, el haber aceptado nuestro TFG, el haber estado todo el curso con nosotros ayudando y tranquilizándonos en los momentos de mayor agobio. También queremos dar las gracias al equipo de Pista Virtual, que siempre nos han recibido con los brazos abiertos en sus oficinas, y han estado disponibles para ayudarnos cuando lo hemos necesitado, en especial queríamos agradecérselo a Rafael, que ha sido el que más tiempo ha estado con nosotros ayudándonos y explicándonos las distintas tecnologías y resolviéndonos cada duda que teníamos. Nos sentimos verdaderamente realizados tras haber aprendido una tecnología nueva, que sin su ayuda no hubiera sido posible. No nos queremos olvidar de nuestra familia y amigos que nos han estado apoyando y motivando a lo largo de todo el curso, siempre con una sonrisa y dándonos ánimos para conseguir sacar este proyecto adelante. Acknowledgements First of all we want to thank our tutor, Adrián Riesco, to accepting our TFG, for being the whole course with us helping us and reassuring us in the moments of greatest load of work. We also want to thank the Pista Virtual team, who have always welcomed us with open arms in their offices, and willing to help us when we needed it, especially we wanted to thank Rafael, who has been the guy who has helped us the most , explaining the different technologies and resolving every doubt we had. We feel truly fulfilled after having learned a new technology, which without their help would not have been possible. We do not want to forget about our family and friends who have been supporting and motivating us throughout the course, always with a smile and giving us encouragement to get this project forward 1. Introducción En esta sección de este Trabajo de Fin de Grado presentamos la motivación, los objetivos y el plan de trabajo. Por último, describimos la organización del resto de la memoria. La gestión del acceso a las zonas deportivas en la UCM se quiere automatizar poco a poco. Esta automatización se está realizando mediante una aplicación móvil llamada Pista Virtual. En particular, en las piscinas, tienen una gestión manual que ralentiza el acceso a los usuarios y dificulta la gestión a los administradores. En este trabajo proponemos una extensión de Pista Virtual que consiste en la entrada a la piscina de verano mediante la aplicación. El acceso a la piscina de verano de la Complutense que ha habido hasta ahora ha sido mediante la compra de abonos en papel o de entradas individuales en la puerta de acceso. Para poder pasar solo tenías que presentar un carnet universitario y pagar en la puerta o dar el bono. Además, el aforo era difícil de controlar ya que no había un registro de ventas diarias. Introducir la piscina en Pista Virtual supone una ayuda para poder controlar el aforo, ya que la aplicación no dejará reservar más entradas de las permitidas. Impedir que con un mismo abono de la Complutense pasen dos o más personas, ya que un abono lo puedes utilizar una vez al día. Tener controlado el acceso de usuarios tanto que pertenecen a la Complutense como los que no y que los usuarios que accedan conozcan las normas para poder disfrutar de la piscina. El módulo piscina en Pista Virtual ayuda a un avance tecnológico en el acceso a la piscina ya que con solo llevar el móvil puedes acceder y pagar en el momento. 1.1. Motivación Ayudar a la Complutense a mejorar su sistema de acceso a las piscinas fue una de las principales motivaciones de este proyecto. Cuando conocimos a Pista Virtual y nos ofreció realizar este proyecto no pudimos decir que no ya que saber que nuestra aplicación va a utilizarse y va a estar implantada en el sistema de la UCM de carácter más o menos inmediato nos ha servido como motivación para hacer el proyecto y trabajar con más ganas. Otro motivo por el cuál elegimos colaborar con ellos fue aprender un lenguaje nuevo como es .NET y Xamarin.Forms, ya que es algo que a lo largo de la carrera no hemos utilizado y gracias a que Pista Virtual está implementada con esta tecnología hemos podido aprenderla y formarnos en un ámbito que hasta ahora no habíamos conocido. Introducir Pista Virtual en la universidad supone un avance tecnológico ya que tras años de colas y esperas para acceder a cualquier instalación deportiva, gracias a esta aplicación solo necesitas tenerla en tu móvil para poder reservar el acceso a cualquiera de ellas. Por esto mismo elegimos una colaboración con ellos para nuestro TFG. 1.2. Objetivos El objetivo principal de este TFG es crear una herramienta que permita el acceso a las piscinas de la Complutense de una manera más cómoda para los usuarios y mejorar la gestión de la piscina. Este proyecto tiene como objetivo la realización del módulo para la automatización de la piscina, es decir, el acceso a la piscina mediante la aplicación. El proyecto está dividido en dos áreas independientes, una para el trabajador de la UCM que consiste en la lectura de un código BIDI para permitir el acceso a la piscina, y otra área para los usuarios (empleados, estudiantes, alumni) que consiste en la compra de entradas o bonos para acceder a la piscina mediante la generación de un código BIDI. La organización del trabajo se ha llevado a cabo como sigue:  Investigación y aprendizaje sobre la tecnología y del lenguaje que íbamos a utilizar.  Instalación del módulo de .NET en Visual Studio.  Realizar las primeras pantallas y pruebas para comenzar a familiarizarnos con el lenguaje.  Desarrollo de la aplicación previa a los requisitos.  Introducción de los requisitos en nuestra aplicación.  Pruebas de funcionamiento y arreglo de los errores.  Adaptación de nuestras interfaces a las de Pista Virtual utilizando los estilos que nos dieron.  Integración del Módulo Piscina en la aplicación de Pista Virtual. 1.3. Plan de trabajo Durante los primeros meses nuestro principal trabajo fue familiarizarnos con el lenguaje y con la tecnología que hemos estado usando. Hicimos pequeñas interfaces que se conectaban las unas con las otras y con un funcionamiento mínimo. Comenzamos realizando un pequeño menú como el que podemos ver en nuestro código, del que poco a poco fue surgiendo nuestro modulo. Fuimos añadiendo funcionalidad a medida que fuimos visitando a Pista Virtual y aprendiendo de los errores que íbamos cometiendo para no tenerlos más adelante. A finales de marzo La Complutense nos dio sus requisitos, los añadimos en nuestra aplicación y comenzamos a ir a Pista Virtual con bastante más frecuencia para que nos indicaran como querían las interfaces y nos solucionaran alguna duda que íbamos teniendo respecto a los requisitos, ya que ellos han sido los que se han comunicado con la Complutense en todo momento. La semana previa a Semana Santa, Pista Virtual nos dio sus interfaces y adaptamos nuestra aplicación a los diseños que ellos nos pidieron. En Semana Santa hicimos la entrega del código al equipo de Pista Virtual para que hicieran la integración en la aplicación y la Complutense pudiera probar el código y los requisitos con tranquilidad de cara a la apertura de la piscina de verano. Después de Semana Santa escribimos la memoria. 1.4. Estructura de la memoria. El resto de la memoria se estructura de la siguiente forma:  En la sección 2 se explican las tecnologías utilizadas y qué es Pista Virtual.  En la sección 3 se detallan los requisitos que hemos seguido durante la realización del proyecto.  En la sección 4 se expone la implementación del módulo y cómo está formado.  En la sección 5 ofrecemos un manual de usuario.  En la sección 6 hablamos de las contribuciones al proyecto de cada uno de nosotros.  En la sección 7 se muestran las conclusiones del proyecto y el trabajo futuro. El código de la aplicación está disponible en: https://github.com/patrioz/Modulo-PiscinaTFG/tree/master/ModuloPiscina 2. Introduction In this section of this Degree Thesis we explain the motivation, the objectives and the work plan. Finally, we present the organization of the rest of the memory. The management of the sports areas in the UCM is being automated little by little. It is being done through a mobile application called Pista Virtual. In the pools, they have a manual management that slows down access to users and makes it difficult for administrators to manage. In this work we propose an extension of Pista Virtual consisting of the entrance to the summer pool through the application. The access to the summer pool of the Complutense that has been used so far, it has been managed through the purchase of paper tickets or individual tickets at the gate. In order to pass you only had to present a university card and pay at the door or hand out the voucher. In addition, the capacity was difficult to control since there was no record of daily sales. Introducing the pool in Pista Virtual helps to control the capacity, since the application will not book more tickets than allowed. It also prevents people from using the same pass, as a pass can be used only once a day. To control the access of users both belonging to the Complutense and those who do not and that the users who access are in knowledge the rules to enjoy the pool. The Pista Virtual pool module helps a technological breakthrough in the access to the pool since you can access and pay at the moment by just carrying the mobile phone. 2.1. Motivation Helping the Complutense to improve its access system to the swimming pools was one of the main motivations of this project. When we met Pista Virtual and offered to carry out this project we could not say no because knowing that our application will be used and will be implemented in the UCM system of more or less immediate nature has served us as a motivation to fulfill the project and work with more desire. Another reason why we chose to collaborate with them was to learn a new language such as .NET and Xamarin.Forms, since it is something that we have not used throughout the degree and thanks to the fact that Pista Virtual is implemented with this technology, we have been able to learn it and train us in a field that until now we had not known. https://github.com/patrioz/Modulo-PiscinaTFG/tree/master/ModuloPiscina https://github.com/patrioz/Modulo-PiscinaTFG/tree/master/ModuloPiscina 2.2. Objetives The main objective of this TFG is to create a tool that allows access to the swimming pools of the Complutense in a more comfortable way for users and improve the management of the pool. The objective of this project is to create the module for the automation of the pool, that is to say, access to the pool through the application. The project is divided into two independent areas, one for the staff of the UCM that consists of reading a BIDI code to allow access to the pool, and another area for users (employees, students, alumni) consisting of the purchase of tickets or bonuses to access the pool by generating a BIDI code. The organization of work has been carried out as follows: • Research and learning about the technology and the language that we would use. • Installation of the .NET module in Visual Studio. • Make the first screens and tests to begin to familiarize ourselves with the language. • Development of the application prior to the requirements. • Introduction of the requirements in our application. • Tests of operation and arrangement of errors. • Adaptation of our interfaces to Pista Virtual using the visual styles they gave us. • Integration of the Pool Module in the Pista Virtual application. 2.3. Workplan Among the first months our main job was to familiarize ourselves with the language and with the technology that we have been using. We made small interfaces that were connected to each other and with minimal operability. We started by making a small menu like the one we can see in our code, from which our module was gradually growing. We were adding functionality as we were visiting Pista Virtual and learning from the mistakes we were making so we will not make them again. At the end of March, Complutense gave us their requirements and started to implement our application, and at this moment we started to go to Pista Virtual a lot more frequently so they could indicate us how they wanted the interfaces and solve any doubts that we were having regarding the requirements, since they have been the ones who have communicated with the Complutense at all times. The week before Easter, Pista Virtual gave us the interfaces and we adapted our application to the designs they asked us for. In Easter we sent Pista Virtual the code so they could do the integration in the application and the Complutense could try the code and the requisites with tranquility facing the opening of the summer pool. After Easter we wrote the memory. 2.4. Memory structure The rest of the memory is structured as follows: • Section 2 explains the technologies used and what is Virtual Track • Section 3 details the requirements that we have followed during the implementation of the project. • Section 4 explains the implementation of the module and how it is formed. • In Section 5 we present the user manual. • In section 6 we discuss the contributions to each of our projects. • Section 7 concludes and presents some issues of future work. The code of the application is available in: https://github.com/patrioz/Modulo-PiscinaTFG/tree/master/ModuloPiscina 3. Preliminares En esta sección presentamos a Pista Virtual y las tecnologías utilizadas en el proyecto. En particular el desarrollo de la automatización de la gestión de las piscinas se ha realizado con .NET y Xamarin.Forms, que detallamos a continuación. 3.1. Pista Virtual Pista Virtual es un equipo de desarrolladores que cuando estaban acabando la carrera se les ocurrió, como a nosotros, realizar como TFG una aplicación para la gestión polideportiva ya fuese de una universidad o de un grupo de centros deportivos. Una vez presentado su TFG decidieron seguir con él y dar un paso más, se lo ofrecieron a la Complutense y llevan dos años intentando implantar su aplicación en la universidad. Nosotros tuvimos una idea muy similar a la de ellos, cuando se la propusimos a nuestro tutor nos recomendó hablar con el equipo de deportes, y fueron ellos los que nos llevaron hasta el equipo de Pista Virtual quienes sin ningún problema nos enseñaron su aplicación y nos ofrecieron realizar el módulo de la piscina para posteriormente poder implantarlo en su aplicación. Desde un primer momento el equipo de Pista Virtual nos ofreció toda la ayuda que estaba en sus manos, nos ofrecieron ir a visitarles siempre que lo necesitásemos y un lugar donde poder trabajar, nos ayudaron a dar los primeros pasos en la aplicación explicándonos el funcionamiento de la plataforma y del lenguaje, nos enseñaron como trabajaban ellos y como ir haciéndonos a las nuevas tecnologías que hemos estado utilizando. Sin conocerles mucho, desde la primera reunión que tuvimos con ellos hace ya más de un año nos transmitieron confianza y supimos que hacer el proyecto con ellos sería una buena idea, siempre que hemos tenido algún problema o hemos necesitado de su ayuda han estado a nuestra disposición sin importarles perder una tarde entera con nosotros explicándonos el funcionamiento de sus módulos o de ideas de cómo realizar el nuestro. La piscina de verano va a ser el primer módulo que pongan en funcionamiento. Considerando que después de dos años de reuniones con la universidad para poder implantar la aplicación lo https://github.com/patrioz/Modulo-PiscinaTFG/tree/master/ModuloPiscina https://github.com/patrioz/Modulo-PiscinaTFG/tree/master/ModuloPiscina primero que la Complutense haya decidido desplegar sea nuestro módulo nos motiva bastante, ya que es un módulo que ha salido adelante en un curso académico y que creemos que va a ser muy útil y cómodo tanto para los trabajadores como para los usuarios. Para los trabajadores porque con un simple sonido sabrán qué tipo de usuario está accediendo a la piscina y saber si la entrada es buena o mala. Y para los usuarios porque solo necesitan una aplicación en el teléfono para poder acceder a la piscina. Con este módulo conseguimos mejorar el acceso que ha habido hasta ahora que era mediante la compra de abonos en papel o de entradas individuales en la puerta de acceso. Para poder pasar tenías que presentar un carnet universitario y pagar en la puerta o dar el bono. 3.2. Tecnologías Como tecnologías utilizadas durante el desarrollo del proyecto has sido .NET y Xamarin.Forms, ya que es la tecnología en la que el equipo de Pista Virtual tiene implementada su aplicación. 3.2.1. .NET .NET es una tecnología para el desarrollo de software multiplataforma, usada para que la aplicación tenga el mismo soporte ya sea para un sistema operativo u otro. Esto nos ha facilitado mucho las cosas, ya que lo que hemos tenido que programar para Android y para IOS ha sido mínimo. Desde el punto de vista tecnológico, .NET desarrolla aplicaciones y sistemas que son independientes de la arquitectura física y del sistema operativo sobre el que se ejecuta, gracias a esto se pueden realizar en distintos ámbitos, en nuestro caso en una aplicación móvil. Una de las principales ventajas de esta tecnología es el desarrollo multiplataforma que hace que la implementación se pueda utilizar en los distintos sistemas operativos de los teléfonos móviles. Gracias a este motivo apenas hemos tenido que programar en Android y en iOS. El lenguaje utilizado para el desarrollo del proyecto ha sido C#. El entorno de trabajo que proporciona .NET es un motor de ejecución que controla las aplicaciones en ejecución y la biblioteca de clases. Los componentes principales de .NET [1] son:  El Entorno Común de Ejecución para Lenguajes (CLR): Entorno de ejecución proporcionado por .NET Framework que ejecuta el código y proporciona servicios que facilitan el proceso de desarrollo.  La Biblioteca de Clases Base (BCL): La biblioteca de clases está orientada a objetos, lo que proporciona tipos que son fáciles de usar y reduce el tiempo asociado con el aprendizaje de nuevas características de .NET.  Conjunto de lenguajes de programación: soporta ya más de veinte lenguajes de programación y es posible desarrollar cualquiera de los tipos de aplicaciones soportados en la plataforma con cualquiera de ellos. Algunos de los lenguajes desarrollados son: C# (Utilizado en el proyecto), Visual Basic, C++, J#, Perl Python, Fortan y Cobol.NET. 3.2.2. Xamarin Xamarin es un entorno unificado, ya que ofrece un lenguaje, una biblioteca de clases y un entorno de ejecución que funciona en múltiples plataformas. En este sentido, Xamarin es único porque combina la potencia de las plataformas nativas y agrega una serie de características propias muy eficaces [2]:  Tiene funciones para invocar directamente a la biblioteca.  Utiliza C# que incluye las mejoras de Objetive-C y Java.  Usa Visual Studio como entorno de desarrollo, que es compatible para Mac en Mac OX y Visual Studio en Windows, nosotros hemos utilizado ambos programas para el desarrollo del proyecto.  Ofrece compatibilidad multiplataforma móvil, ofrece una compatibilidad multiplataforma sofisticada con las tres principales plataformas móviles: iOS, Android y Windows Phone Es posible escribir aplicaciones de modo que compartan hasta el 90% del código, como es en el caso del proyecto. La biblioteca Xamarin.Mobile ofrece una API unificada para tener acceso a los recursos comunes de las tres plataformas. Nosotros hemos desarrollado toda la aplicación en C# a excepción de los permisos de cámara que los hemos tenido que poner tanto en Android como en iOS. El funcionamiento de Xamarin nos muestra dos productos, Xamarin.iOS y Xamarin.Android. Ambos se basan en una versión de código abierto del entorno de trabajo de .NET que tiene en cuenta todas las normas de esta tecnología 3.2.2.1. Xamarin.Forms Representa todas las herramientas de interfaz de usuario multiplataforma para desarrolladores de .NET. Puedes compilar las aplicaciones en los distintos sistemas operativos, como ya hemos citado anteriormente, con C# en Visual Studio. Esta versión de código abierto puede ejecutarse en prácticamente todas las plataformas [3]. Las aplicaciones Xamarin usan un tiempo de ejecución que controla todo automáticamente. Cuando se compilan aplicaciones Xamarin, el resultado es un paquete de aplicación, ya sea un archivo para iOS o Android. El proyecto entero ha sido desarrollado con Xamarin.Forms y con las bibliotecas que proporciona. 3.3. Visual Studio La herramienta seleccionada para el desarrollo del proyecto ha sido Visual Studio, ya que el equipo de Pista Virtual es el programa que utiliza y en que Xamarin.Forms proporciona todas sus bibliotecas y con C# puedes ejecutar la aplicación en los distintos sistemas operativos para las aplicaciones móviles en sus simuladores. No nos ha sido difícil familiarizarnos con él ya que en la carrera desde primer curso nos han hecho trabajar con esta herramienta. 3.4. Licencias Las licencias de Software empleadas en este proyecto han sido las empleadas por Pista Virtual, utilizan una licencia con software propietario[4], es decir no existe forma de acceso al código fuente de la aplicación, y no se permite su libre modificación, adaptación o incluso lectura de terceros. En este software el autor, en nuestro caso, Pista Virtual, no transmite ninguno de los derechos, ha establecido las condiciones con nosotros de que el software puede ser utilizado, limitando los derechos de copia, modificación, cesión o redistribución, y nos ha especificado que el producto pertenece al propietario, y nos ha concedido el privilegio de utilizarlo[5] . 4. Requisitos A continuación, en esta sección vamos a explicar los requisitos que la Universidad Complutense de Madrid nos indicó para la realización de la aplicación. 4.1. Requisitos Iniciales Al inicio del verano de 2018, junto con un asesor del Vicerrectorado de Deportes de la Universidad Complutense, nuestro tutor y con el equipo de Pista Virtual, nos acercamos a las instalaciones de la piscina de verano de la universidad para ver personalmente cómo funcionaba el sistema de entrada y tener en cuenta ciertos requisitos iniciales. Tras reunirnos con el personal encargado, definimos los siguientes requisitos:  Aforo: El aforo de la piscina está limitado a 1500 personas. Esto es un requisito importante ya que el sistema de conteo actual es manual, es decir, cada vez que una persona accede a las instalaciones el personal apunta en un papel el número de personas que han accedido. Cabe decir que no se controlan las personas que salen de las instalaciones, simplemente se lleva un control visual aproximado del aforo en cierto momento, generando esto una incongruencia con respecto al conteo de entrada y un descontrol que puede generar grandes problemas.  Roles: Los usuarios con acceso a las instalaciones deben ser mayores de 18 años y deben tener uno de los siguientes roles: Estudiantes UCM, Estudiante NO UCM, Alumni y Trabajador. Estos roles limitan el acceso a cualquier persona ajena a la Universidad Complutense y/o que no esté cursando estudios universitarios. o Estudiantes UCM: Cualquier estudiante de la Universidad Complutense con su correspondiente carné universitario en vigor y disponible para ser presentado ante el personal de las instalaciones. o Estudiantes NO UCM: Cualquier estudiante de universidades de España con su correspondiente carné universitario en vigor y disponible para ser presentado ante el personal de las instalaciones. o Alumni: Cualquier persona que se haya graduado por la Universidad Complutense y en capacidad de demostrarlo. o Trabajador: Cualquier empleado de la Universidad Complutense con su correspondiente acreditación y disponible para ser presentado ante el personal de las instalaciones. Estos roles cobran especial importancia de cara al aforo y al tipo de público permitido, también en relación a la implementación del aplicativo siendo unos de los requisitos con mayor peso.  Tipo de Entrada: Teniendo en cuenta los dos requisitos anteriores, especialmente la pertenencia a uno de los roles definidos, podemos definir el tipo de entrada a la piscina el cual solo se puede realizar de tres únicas maneras: o Entrada Individual: Entrada de un único uso y de validez limitada al día en que se adquiere. Este ticket es comprado en la misma entrada de las instalaciones siempre que el aforo no se vea superado y puedas acreditar tu pertenencia a uno de los roles definidos previamente. Una vez se abandonen las instalaciones, ese ticket no podrá volver a ser utilizado. o Entrada Abono 10: Abono de 10 entradas individuales y de validez limitada al fin de la temporada de verano. Este abono también es adquirido en la entrada de las instalaciones y quedará limitado tanto al aforo de la piscina como a la acreditación de uno de los roles definidos previamente excluyendo al rol de Alumno NO UCM el cual no tendrá acceso a este tipo de entrada. Una vez se abandonen las instalaciones se deberá gastar otro uso del bono. o Entrada anual: Tarjeta anual de acceso. Este tipo de entrada también está directamente relacionada con el aforo de las instalaciones, así como con el rol al que se pertenezca excluyendo al rol de Alumno NO UCM el cual no tendrá acceso a este tipo de entrada.  Precio: El precio de entrada depende tanto del rol al que pertenezcas como del tipo de entrada que se adquiera. La siguiente tabla presenta todas las combinaciones posibles de roles y tipos de entradas. Quedando los requisitos iniciales previos a la primera implementación definidos, podemos describir el método de entrada a la piscina:  Encontrándose el usuario en la entrada de las instalaciones, deberá presentar su abono anual al personal allí presente, el cual le daría acceso inmediato siempre y cuando el aforo lo permita. Si no dispone de abono anual, deberá o bien comprar una entrada individual o un abono de 10 usos (si no tiene ya uno en su poder). Una vez realizada la adquisición (cumpliendo siempre los requisitos) el usuario podrá acceder a las instalaciones. Como se puede observar, este sistema es bastante rudimentario y anticuado, lo que provoca que tenga carencias de todos los niveles como la inexactitud del aforo al no ser controlada la salida de las instalaciones o la posible formación de colas para poder acceder a la piscina. Incluso podría llegar a existir la suplantación de identidad a la hora de presentar la acreditación que INDIVIDUAL ABONO 10 ABONO ANUAL NO UCM 5€ - - UCM 4€ 25€ 50€ ALUMNI 4€ 25€ 75€ PERSONAL 4€ 25€ 30€ verifica la pertenencia a cualquiera de los roles debido a que la exigencia que se observó en estas situaciones no era de gran nivel. 4.2. Requisitos Posteriores Una vez concluimos con la observación del proceso de entrada y conociendo los requisitos previos existentes, procedimos a contemplar los casos de uso y requisitos de la nueva implementación. Se definieron dos casos de uso: obtener ticket y acceder al recinto.  Obtener Ticket: El presente caso de uso permite al usuario obtener un ticket de acceso a la piscina a través de la nueva aplicación. La precondición a tener en cuenta en este primer escenario es que el usuario esté registrado en la aplicación de Pista Virtual. Flujo principal 1. El usuario se valida en el sistema. 2. El sistema comprueba que tipo de descuento tiene el cliente en relación al rol al que pertenece. 2.1. Si el cliente ya posee un tipo de entrada como un abono de 10 o un abono anual, le permite adquirir un ticket a precio 0 €. 2.2. En caso de que el cliente no posea ningún tipo de abono, le permite la adquisición de un ticket sencillo aplicando la tarifa establecida en la tabla en relación a su rol. 3. Cuando el cliente vaya a realizar la adquisición de la entrada, se le ofrece la posibilidad de adquirir hasta 2 tickets extra para acompañantes. 3.1. El usuario deberá indicar para cada entrada si los acompañantes están vinculados a la UCM o no, asociándose así la correspondiente tarifa a las entradas extra. 4. Se valida el número de tickets que el usuario está solicitando y posteriormente se procede a su adquisición y al pago en su caso. 5. El sistema contabiliza los tickets emitidos. Flujos alternativos A. El sistema no encuentra el usuario o no tiene acceso a descuentos de ningún tipo. I. Muestra un mensaje informado al usuario y le permite el acceso como usuario general. B. El sistema no tiene disponibilidad de tickets a la venta, mostrando en este caso un mensaje informando al usuario que no existen entradas para la fecha seleccionada. Las postcondiciones establecidas son: la disposición de uno o varios tickets por parte del usuario que le permiten el acceso al recinto y la notificación de los tickets vendidos. Cabe decir que la adquisición de un ticket es obligatoria. Siempre que se quiera acceder a la piscina. Estos tickets pueden tener un coste de 0 € si se posee un abono anual o un abono de 10 usos. El abono anual no es posible adquirirse a través de la aplicación (decisión del cliente) mientras que el abono de 10 usos sí lo es. En caso de no poseer ninguno de estos descuentos, siempre se podrá adquirir un ticket al precio establecido. Al tratarse de una primera especificación de requisitos y definición de caso de uso, ambos flujos fueron modificados con ciertos detalles que mejoraron el proceso de adquisición de entradas. Estas modificaciones fueron consultadas y aprobadas por el cliente respetando siempre la idea final del producto. En particular , la localización del tipo de descuento asociado al usuario se realizará como paso previo a la compra final de las entradas y una vez localizado (si lo hubiese), si este fuera un abono de 10, se le restaría un uso a dicho descuento eliminándolo finalmente si este se quedara sin usos. Se añadirá un flujo alternativo al punto A, limitando al usuario que ha accedido sin identificación a la compra única de tickets de acceso excluyéndolo de la compra de abonos de 10 usos. Se añadirá un caso de uso posterior, contemplado la compra de un abono de 10 usos.  Acceder al recinto: El presente caso de uso describe el acceso del usuario a las instalaciones de la piscina. Las precondiciones para este caso de uso son: La llegada del cliente a las instalaciones con el ticket de acceso previamente obtenido a través de la aplicación, el dispositivo de acceso/lectura está funcionando y no se permite el acceso si se ha llegado al aforo máximo. Flujo principal 1. El usuario presenta un código QR generado en la compra del ticket frente al dispositivo de lectura. 2. El sistema comprueba la validez del ticket presentado. 2.1. En caso de que el ticket esté caducado (la adquisición de dicho ticket es sólo válida para el mismo día de la compra) o sea inválido, muestra un mensaje visual y un sonido de error. 2.2. En caso de que el ticket sea válido, si el usuario es personal NO vinculado a la UCM mostrará un mensaje de aceptación emitiendo un sonido diferente para que el administrador del lugar compruebe su validez. 2.3. En caso de que el ticket sea válido, si el usuario es personal vinculado a la UCM mostrará un mensaje de aceptación. 3. El sistema aumenta en 1 la ocupación por cada ticket válido presentado. Flujos alternativos A. El sistema no reconoce como válido el ticket presentado. i. Muestra por pantalla un mensaje y emite un aviso sonoro informando del resultado erróneo, KO. B. El sistema ha alcanzado el límite máximo del aforo. ii. Muestra por pantalla un mensaje informando del límite alcanzado emitiendo un aviso sonoro. Las postcondiciones en este caso son: la entrada del usuario al recinto y la notificación del número de entradas que se producen. Es importante tener en consideración que en un primer momento se planteó el sistema de acceso a través de la aplicación con un código QR y unos tornos que controlasen tanto la entrada como la salida de las personas, llevando así un conteo exacto del aforo. A posteriori, el cliente nos comunicó la imposibilidad de instalar los tornos. Esto supuso el cambio en los flujos principales de los dos casos de uso anteriores. El usuario ya no se encontrará con la imposibilidad de entrar habiendo comprado su ticket para ese día por un escenario de aforo máximo, ya que la compra de entradas se limitará a ese mismo día controlando el aforo de la piscina en el mismo momento de la compra. Por otro lado, al no poder controlar con los tornos la salida de los usuarios, este control de aforo quedará en manos del administrador de las instalaciones disminuyendo manualmente el foro actual en el sistema. 4. Implementación En este apartado se va a explicar el diseño y estructura completa del aplicativo. En primer lugar, se explicará la estructura general, clases, subclases, así como los plugins añadidos para completar la funcionalidad. Como hemos explicado en la sección 2 de esta memoria, se ha utilizado esta tecnología debido a la facilidad que plantea a la hora de implementar código multiplataforma. Esto nos permite desarrollar el código básicamente solo en un lenguaje combinado C# y Xaml para todas las plataformas existentes: IOS, Android y UWP (Universal Windows Platform). Cabe mencionar que en ciertos casos sí que es necesario especificar y desarrollar código para cada plataforma debido a las diferencias en ciertas características, como por ejemplo en las notificaciones o los permisos, como por ejemplo el de la cámara de fotos [6]. 4.1. Diseño La estructura que se genera cuando se crea un proyecto de Xamarin es la siguiente: Como se puede observar se crean 4 proyectos. El proyecto principal y donde se va a desarrollar la mayor parte del código es en el primero, ModuloPiscina. Aquí es donde se implementa el código nativo, es decir, el código que va a ser útil para las 3 plataformas. También se crean otros 3 proyectos con propiedades específicas de cada plataforma como se ha comentado en la introducción de este apartado. La estructura resultante de ModuloPiscina es la siguiente: En esta estructura se observan varias carpetas para una mejor organización del proyecto. Por ejemplo, podemos diferenciar entre la parte de acceso a la piscina en la carpeta Entrada y la parte de control de acceso en LecturaQR o la parte de conexión del contenido visual y la lógica en ViewModel o incluso un conjunto de clases básicas con atributos de identificación. Todas ellas serán explicadas a continuación. 4.2. Explicación de la implementación. En la carpeta de “Classes”, como comentamos anteriormente, encontramos clases simples implementadas en C# con atributos importantes y de los cuales se va a hacer uso en la parte visual. Algunas clases son proporcionadas por el equipo de Pista Virtual para facilitar la integración en sus sistemas como por ejemplo la clase Descuento. Esta clase ya es usada en su aplicación para otros tipos de deportes y alquiler de pistas, por tanto nos pidieron que tuviésemos de base esta clase, la cual cuenta con atributos como Id_Descuento, Nombre Id_Gestor, Cantidad, Fecha_Ini, Fecha_Fin, etc., para la realización de nuestra aplicación. En la parte relacionada con los usuarios encontramos la clases User en la cual se definen los atributos básicos a tener en cuenta en un usuario como el Nombre, Apellidos, DNI… y otros importantes como son: public virtual List Descuentos { get; set; } public virtual List HistoricoEntradas { get; set; } Nos encontramos ante dos listas de Descuento y Entradas las cuales van a permitir localizar, asignar y eliminar un descuento o una entrada al usuario correspondiente. Estas listas son inicializadas a través de la clase UsuariosPrueba, la cual es la encargada de inicializar los atributos básicos de la clase User y estas listas tan importantes de la siguiente manera public class UsuariosPrueba { public static User UsuarioEstudiante() { User usuario = new User { Id_Usuario = 1, Nombre = "carlos", Apellidos = "martin gutierrez", Email_Preferido = "camart12@ucm.es", Fecha_Nacimiento = new DateTime(1995, 8, 14), Sexo = true, DNI = "51229181T", Descuentos = new List(), Gestores = new List(), HistoricoEntradas = new List() }; Usuario.Descuentos.Add(new Descuento { Id_Descuento = 2, Nombre = "Abono de 10 usos", Descripcion = "Este bono de 10 baños es para uso individual, no transferible. El uso de este abono esta limitado a usuarios de la UCM mayores de edad.", Precio = 25, Num_Usos = 8, Fecha_Inicio = DateTime.Now, }); usuario.HistoricoEntradas.Add(new Entradas(2.ToString(), usuario.Id_Usuario, 2, 9, new DateTime(2009, 08, 25), new DateTime(2018, 08, 26), null )); return usuario; } } La clase EntrarCódigoBidi se encarga de generar a través del plugin instalado ZXingBarcodeImageView [7]el código QR para el servicio de escaner identifique una entrada. Se ha realizado de la siguiente manera: barcode = new ZXingBarcodeImageView { HorizontalOptions = LayoutOptions.FillAndExpand, VerticalOptions = LayoutOptions.FillAndExpand, }; barcode.BarcodeFormat = ZXing.BarcodeFormat.QR_CODE; barcode.BarcodeOptions.Width = 250; barcode.BarcodeOptions.Height = 250; barcode.BarcodeValue = id_usuario + " " + id_entrada + " " + id_descuento + " " + num_usos + “ ” + fecha_adquisicion.ToShortDateString() + " " + fecha_fin.ToShortDateString(); Como se puede observan en las 3 últimas líneas de este fragmento de código, a partir de varios atributos de la clase Entrada se identifica y se crea el código QR el cual podrá ser leído posteriormente y localizar así el ID del usuario al que pertenece, el propio ID de la entrada, etc. Además de la generación del código, muestra información de interés de la entrada. La clase IQrCodeScanningService es simplemente una interfaz encargada de inicializar la cámara y el plugin encargado de la lectura de códigos QR. public interface IQrCodeScanningService { Task ScanAsync(); } Por último, podemos definir a las clases AcompanantesList, Desc_Usuario y Usuario_Gestor como clases de conexión tanto para el contenido visual con la lógica como entre otras clases. Por ejemplo Usuario_Gestor crea una relación entre un usuario (Id_Usuario) y el tipo de rol al que pertenece y AcompanantesList nos proporciona a través de un objeto de tipo Entrada una lista de precios para los vinculados a la UCM y los NO vinculados lo cual cobrará sentido en la parte visual. Continuamos con la carpeta “Entrada” en la cual se definen las clases relacionadas con la parte del cliente a la hora de realizar la compra, la reserva o acceso a las instalaciones. En esta carpeta encontramos uno de los esquemas característicos de este lenguaje, la conexión entre la lógica en C# y la parte visual en Xaml, un lenguaje basado en HTML y XML con ciertos atributos que nos permiten esa conexión. En la Imagen 2 se observa el desglose de una página de contenido (C# + Xaml). El esquema resultante sería el siguiente: Cada una de estas páginas de contenido representa una ventana en la aplicación móvil. A continuación, se explicarán una a una todas estas páginas, su funcionalidad principal y alguna referencia al código en sí. Se explicarán en orden de acceso a la aplicación. En primer lugar, la página App es creada automáticamente en un proyecto de Xamarin. Es la página por defecto que se crea en el proyecto nativo para poder lanzar la aplicación. Como se ha comentado con anterioridad, tenemos la parte de contenido visual, y la parte lógica en C#. A continuación, se muestra la parte lógica App.Xaml.Cs: namespace ModuloPiscina { public partial class App : Application { public App() { InitializeComponent(); MainPage = new NavigationPage(new MainPage()); } } } En la constructora se observan dos líneas. La primera, InitializeComponent(), es una función interna que permite el lanzamiento del contenido visual de propia página la cual vamos a encontrar en el resto de páginas de contenido. La segunda, es la inicialización de la navegación entre páginas que nos permitirá navegar entre las diferentes partes de la aplicación. A continuación, el flujo de navegación continuaría hasta MainPage. En esta página ya podemos decir que la parte visual cobra importancia, situando dos botones que van a dividir la parte de control de acceso y la parte de entrada, compra, etc. El código Xaml que encontramos en MainPage.xaml es el siguiente: