Software para la gestión de servicios de Internet comunitario

Grado en Ingeniería Informática

SOFTWARE PARA LA GESTIÓN DE SERVICIOS DE INTERNET

COMUNITARIO

Memoria

RAUL VILLAFRANCA ARCENEGUI

PONENT: EDUARD DE BRU DE SALA CASTELLS

Dedicatoria

Dedico el proyecto a mis padres José Antonio y María José por haberme animado a cursar el Grado y por su paciencia durante estos años.

Agradecimientos

Me gustaría dar las gracias a Eduard de Bru de Sala por la tutorización del proyecto. Por último agradecer a todos los docentes del Tecnocampus por sus enseñanzas durante todos estos años, ya que de manera directa o indirecta han hecho posible que este trabajo vea la luz.

Resumen

Este proyecto tiene como objetivo el desarrollo de una aplicación web para la gestión económica de un servicio de Internet Comunitario en una comunidad de propietarios. La aplicación permitirá la gestión de los usuarios del servicio, los costes del servicio y la emisión de recibos. La aplicación se desarrolla en lenguaje Java y haciendo uso de Spring Framework.

Resum

Aquest projecte té com a objectiu el desenvolupament d’una aplicació web per a la gestió econòmica d’un servei d’Internet Comunitari en una comunitat de propietaris. L’aplicació permetrà la gestió dels usuaris del servei, els costos del servei y l’emissió de rebuts. L’aplicació està desenvolupada en llenguatge Java fent ús de Spring Framework.

Abstract

The aim of this project is de development of a web application for the economic management of a Shared Internet service in a community of owners. The application will allow the management of the users, the management of the service cost and the emission of bills. The application is developed in Java language using Spring Framework.

Índice.

Índice de figuras. ... VII

Índice de tablas. ... XI

Glosario de términos. ... XIII

1. Objetivos. ... 1

2. Estudio previo. ... 3

2.1. Uso de Internet en los hogares. ... 3

2.2. Concepto de Internet Comunitario. ... 4

2.3. Aspectos legales. ... 4

2.4. Estudio de mercado. ... 5

2.4.1 Sondeo de mercado. ... 5

2.4.2 Encuesta realizada a particulares... 5

2.4.3 Encuesta realizada a administradores de fincas ... 10

2.4.4 Valoración resultados ... 13

2.5. Estudio de los diferentes software existentes actualmente. ... 13

3.1 Introducción ... 17

3.2 Resumen de características principales ... 17

3.3 Spring Core Container ... 18

3.3.1 Beans ... 19 3.3.2 Core Container ... 19 3.3.3 Inversión de control ... 19 3.4 Spring Boot ... 20 3.4.1 Introducción ... 20 3.4.2 Ventajas ... 21

3.5 Inyección de dependencias en Spring ... 23

3.5.1 Ventajas de la inyección de dependencias ... 23

3.6 Formas de inyección de dependencias ... 23

3.6.1 Código sin inyección de dependencias ... 24

3.6.2 Código usando inyección de dependencias ... 25

3.6.2.1 Inyección de dependencias mediante constructor ... 25

3.6.2.2 Inyección de dependencias mediante en setters ... 26

3.6.2.3 Inyección de dependencias mediante inyección de campo ... 27

3.6.2.4 Uso de interfaces en la inyección de dependencias ... 28

3.6.2.5 Uso de dependencias en este proyecto ... 29

3.7 Configuración de dependencias mediante anotaciones ... 31

3.7.2 Otras anotaciones ... 32 3.6.3 Conexión de dependencias ... 33

4 Entorno de desarrollo ... 35

4.2 Tecnologías usadas en el desarrollo ... 39

4.2.1 Spring Boot ... 39

4.2.1.1 Buenas prácticas en Spring Boot ... 40

4.2.1.2 Estructura del código: ... 40

4.2.1.3 Configuración ... 41 4.2.1.4 Inyección de dependencias ... 42 4.2.1.5 @SpringBootApplication ... 42 4.2.3 Maven ... 42 4.2.4 MySQL ... 43 4.2.5 HTML, CSS, Bootstrap, jQuery ... 44 4.2.6 Thymeleaf... 44 4.3 Despliegue de la aplicación ... 46 4.3.1 Despliegue local ... 46

5 Análisis de requisitos de la aplicación ... 53

5.1 Especificación ... 53

5.1.1. Usuarios ... 53

5.1.2. Roles de usuario ... 54

5.1.3. Cálculo importe de Internet comunitario por vecino ... 54

5.2. Requerimientos ... 54

5.2.1 Login ... 54

5.2.2 Gestión de comunidades ... 55

5.2.3 Gestión de residentes ... 55

5.2.4 Gestión de proveedores ... 55

5.2.5 Gestión de contratos con proveedores ... 55

5.2.6 Gestión recibos ... 56

5.3 Requisitos no funcionales: ... 56

5.4 Diagramas de casos de uso ... 57

5.4.1 Diagrama de casos uso de gestión de comunidades ... 57

5.4.2 Diagrama de casos de uso de gestión de residentes ... 58

5.4.3 Diagrama de casos de uso de gestión de contratos ... 58

5.4.4 Diagrama de casos de uso de gestión de recibos ... 59

5.5 Casos de uso ... 59

5.5.1 Inicio de sesión ... 59

5.5.3 Listar comunidades ... 62

5.5.4 Alta Comunidad ... 63

5.5.5 Modificación de una comunidad ... 64

5.5.6 Listar residentes... 64

5.5.7 Alta residente... 65

5.5.8 Modificación de residente ... 67

5.5.9. Listar proveedores de Internet ... 67

5.5.10 Alta proveedor de Internet... 68

5.5.11 Modificar proveedor de servicios de Internet ... 69

5.5.12 Listar contratos de Internet ... 69

5.5.13 Alta contrato con proveedor de Internet. ... 70

5.5.14 Modificación contrato con proveedor de servicios de Internet. ... 71

5.5.15 Listar recibos ... 72

5.5.16 Emisión de recibos. ... 73

5.5.17 Pago de recibos... 75

5.6 Diagrama de clases ... 77

6. Estructura de la aplicación ... 79

6.1 Configuración archivo pom y dependencias usadas ... 79

6.2 Estructura del código ... 81

7. Estudio económico ... 83

7.1.1 Coste de material necesario para el desarrollo de la aplicación ... 83

7.1.2 Costes de recursos humanos ... 84

7.1.3 Amortización de equipos y software ... 85

7.1.4 Coste del desarrollo de la aplicación ... 85

7.2 Precio de venta del software ... 86

7.2.1 Cálculo del coste por unidad ... 86

7.2.1 Cálculo del precio de venta ... 87

8. Conclusión. ... 89

Índice de figuras.

Fig. 1 Evolución del equipamiento TIC en las viviendas ... 3

Fig. 2 Respuestas pregunta 1 encuesta a particulares ... 5

Fig. 3 Respuestas pregunta 2 encuesta a particulares ... 6

Fig. 4 Respuestas pregunta 3 encuesta a particulares ... 6

Fig. 5 Respuestas pregunta 4 encuesta a particulares ... 7

Fig. 6 Respuestas pregunta 5 encuesta a particulares ... 7

Fig. 7 Respuestas pregunta 6 encuesta a particulares ... 8

Fig. 8 Respuestas pregunta 7 encuesta a particulares ... 8

Fig. 9 Respuestas pregunta 8 encuesta a particulares ... 9

Fig. 10 Respuestas pregunta 9 encuesta a particulares ... 9

Fig. 11 Respuestas pregunta 1 encuesta a administradores de fincas ... 10

Fig. 12 Respuestas pregunta 2 encuesta a administradores de fincas ... 10

Fig. 13 Respuestas pregunta 3 encuesta a administradores de fincas ... 11

Fig. 14 Respuestas pregunta 4 encuesta a administradores de fincas ... 11

Fig. 15 Respuestas pregunta 5 encuesta a administradores de fincas ... 12

Fig. 16 Respuestas pregunta 6 encuesta a administradores de fincas ... 12

Fig. 17 Resumen de los principales módulos que constituyen Spring Framework ... 18

Fig. 18 Situación de Spring Boot dentro del ecosistema de Spring [3] ... 20

Fig. 20 Hello World codificado usando Spring Framework ... 22

Fig. 21 Ejemplo de código sin inyección de dependencias ... 24

Fig. 22 Inyección de dependencias mediante constructor ... 26

Fig. 23 Inyección de dependencias mediante setter ... 26

Fig. 24 Inyección de dependencias mediante inyección de campo ... 27

Fig. 25 Interfaz ServiceExample ... 28

Fig. 26 Implementación de la Interfaz ServiceExample ... 29

Fig. 27 Se inyecta el servicio en el controlador ... 29

Fig. 28 Fragmento de código de la interfaz ProviderService ... 30

Fig. 29 Fragmento de código donde se implementa la clase ProviderService ... 30

Fig. 30 Inyección de dependencia mediante constructor de ProviderService ... 30

Fig. 31 Anotacion @Component en realacion a @Controller, @Service y @Repository . 32 Fig. 32 Función autocompletar en IntelliJ ... 35

Fig. 33 Ejemplo autocompletar clases estáticas IntelliJ ... 36

Fig. 34 Función autocompletar sugiriendo el uso de de casting ... 36

Fig. 35 Refactorizando con IntelliJ ... 37

Fig. 36 Navegación por el código de un proyecto Spring ... 38

Fig. 37 Imagen del menú phpMyAdmin de Mamp ... 39

Fig. 38 Herramienta Spring Initializr para iniciar proyectos Spring Boot ... 40

Fig. 39 Estructura típica de un proyecto Spring Boot ... 41

Fig. 41 Bucle definido con Thymeleaf ... 45

Fig. 42 Código HTML de un bucle generado por Thymeleaf ... 45

Fig. 43 Menú de nueva configuración para el despliegue ... 46

Fig. 44 Configuración para desplegar la aplicación ... 47

Fig. 45 Aplicación Mamp con un servidor MySQL desplegado en local ... 47

Fig. 46 Imagen del login de la aplicación ejecutándose en local ... 48

Fig. 47 Menú Create New App ... 49

Fig. 48 Subir la aplicación desde repositorio GitHub ... 49

Fig. 49 Selección de rama del proyecto a desplegar y despliegue del proyecto... 50

Fig. 50 Add-on servidor MySQL de Heroku ... 50

Fig. 51 Acceso a la aplicación desplegada en la nube ... 51

Fig. 52 Diagrama casos de uso de gestión de comunidades ... 57

Fig. 53 Diagrama de casos de uso de gestión de residentes ... 58

Fig. 54 Diagrama de casos de uso de gestión de contratos... 58

Fig. 55 Diagrama de casos de uso de gestión de recibos ... 59

Fig. 56 Pantalla de login con los correspondientes números del flujo principal anotados .. 60

Fig. 57 Inicio de caso del caso de uso Logout ... 61

Fig. 58 Flujo principal listar comunidades ... 62

Fig. 59 Flujo principal alta comunidad ... 63

Fig. 60 Flujo principal de listar residentes ... 65

Fig. 62 Flujo principal alta contrato ... 71

Fig. 63 Caso de uso listar recibos ... 73

Fig. 64 Punto 3 del flujo principal del caso de uso emisión de recibos ... 74

Fig. 65 Punto 3.1 del flujo alternativo del caso de uso emisión de recibos ... 75

Fig. 66 Se muestra el paso 1 del caso de uso pago de recibo ... 76

Fig. 67 Se muestra el paso 3 del caso de uso pago de recibo ... 76

Fig. 68 Diagrama de clases del proyecto ... 77

Fig. 69 Estructura de del proyecto ... 79

Fig. 70 Dependencia parent del fichero POM ... 80

Fig. 71 Especificación de la versión Java usada en el proyecto ... 80

Índice de tablas.

Tabla 1 Costes materiales ... 83

Tabla 2 Costes recursos humanos ... 84

Tabla 3 Amortización ... 85

Tabla 4 Coste del desarrollo de la aplicación ... 85

Tabla 5 Coste mantenimiento anual por licencia... 86

Glosario de términos.

API Application Programming Interface

Bootstrap Framework para el diseño de sitios y aplicaciones web

Cloud computing Es un paradigma que permite ofrecer servicios de computación a través de Internet

Coc Convention Over Configuration

CRUD Create, read, update and delete

CSS Cascading Style Sheets

DI Dependency Injection

Framework Marco de trabajo que consta de librerías y un flujo de trabajo pensado para facilitar el desarrollo de aplicaciones.

GIT Sistema de control de versiones

HTML HyperText Markup Language

IDE Integrated Development Environment

IntelliJ IDEA Entorno de desarrollo desarrollado por JetBrains

IoC Inversion of Control

Java Lenguaje de programación orientado a objetos JDBC Java Database Connectivity

JPA Java Persistence Api

Maven Herramienta de software para la gestión y construcción de proyectos Java. La asignación de dependencias se realiza mediante XML.

ORM Object-Relational mapping

POJO Plain Old Java Object

Spring Framework Framework de código abierto para el desarrollo de aplicaciones en plataforma Java.

Thymeleaf Librería Java que implementa un motor de plantillas HTML5/XML

URI Uniform Resource Identifier

URL Uniform Resource Locator

1. Objetivos.

1.1. Propósito.

Una comunidad de vecinos desea contratar a un operador de telecomunicaciones el servicio de acceso a internet para posteriormente distribuirlo entre todos los vecinos. El propósito es desarrollar un software que permita llevar la contabilidad y las necesidades de gestión pertinentes.

1.2. Finalidad.

La finalidad del proyecto es el estudio de la casuística de compartir internet en una comunidad de vecinos, y la valoración de las necesidades de gestión y contabilidad que se derivan de ello, así como el desarrollo de una aplicación web que solucione tales necesidades.

1.3. Objeto.

Al finalizar el proyecto se habrá desarrollado una aplicación web que permitirá la gestión de la contabilidad de un servicio de Internet comunitario en una comunidad de vecinos. A la aplicación se accederá mediante login y password, y la información así como las funcionalidades a las que cada usuario puede acceder estarán restringidas según su rol.

1.4. Abastecimiento.

El desarrollo de la aplicación se realiza en lenguaje Java y haciendo uso de Spring Framework, el cual es un Framework muy potente y que actualmente goza de popularidad. Para la interfaz de usuario se ha elegido que sea web, de forma que se pueda acceder a la aplicación desde diferentes dispositivos sin necesidad de ninguna instalación.

2. Estudio previo.

2.1. Uso de Internet en los hogares.

En los últimos años el número de personas que utilizan Internet está aumentando a una gran velocidad. Internet no se limita hoy en día a usos profesionales ni a la gente joven, sino que como podemos comprobar, su uso se está extendiendo a todas las edades y segmentos de la población.

Diferentes opciones de ocio online están apareciendo a una velocidad vertiginosa. Un ejemplo de esto son las redes sociales, las cuales están cambiando la forma en que nos relacionamos con otras personas, familiares o amigos. Otras opciones de ocio en expansión son la prensa digital, y el consumo de contenidos multimedia (youtube, spotify, etc.). El uso de Internet no se limita al ocio, sino que por el contrario hay otros sectores que también están creciendo. Ejemplos de sectores en expansión incluyen el comercio electrónico y la realización de gestiones con administración en modo online. Podemos decir por tanto que actualmente el acceso a internet permite mejorar la calidad de vida de sus usuarios.

Según el instituto Nacional de Estadística [1], el 81.9% de los hogares del Estado Español disponen de conexión a Internet, y según se puede ver en el siguiente gráfico, la tendencia es que este porcentaje continúe aumentando hasta llegar casi al 100%.

2.2. Concepto de Internet Comunitario.

En los últimos tiempos, se puede observar una tendencia hacia la economía colaborativa y el ahorro. Actualmente por parte de las compañías distribuidoras de Internet se comercializan conexiones para el hogar con un gran ancho de banda, este ancho de banda es habitualmente mucho más amplio del que el usuario medio necesita para un uso cotidiano.

Esto abre la puerta a que comunidades de vecinos contraten una conexión a Internet y la repartan entre los vecinos. Existe un mercado para explotar en este sentido; y ya hay empresas instaladoras que lo están aprovechando, y ofrecen la infraestructura necesaria para compartir Internet de forma comunitaria.

2.3. Aspectos legales.

La legalidad sobre el hecho de compartir una conexión entre vecinos es un asunto que tiempo atrás estuvo envuelto de cierta polémica e indefinición. No obstante, en la actualidad la legislación deja bien claro que compartir una conexión de internet es legal. Según la legislación vigente desde 2010 [2], una comunidad de propietarios puede ofrecer una conexión de Internet comunitario a los vecinos sin necesidad de inscribirse como operadora de servicios de telecomunicaciones en el registro de la CNMT siempre que se cumplan los siguientes requisitos:

 La comunidad no obtiene un beneficio y cobrará a los vecinos el coste del servicio. En los recibos mensuales de la comunidad ha de estar desglosada la cuota que corresponde al servicio de acceso a Internet.

 En los contratos ha de constar el operador con el que se subscribe el contrato y el cual presta el servicio.

2.4. Estudio de mercado.

2.4.1 Sondeo de mercado.

Para conocer que opinión tiene el gran público respecto a los servicios de internet comunitario y sus posibilidades de expansión he realizado dos encuestas. Una dirigida a administradores profesionales de fincas, y otra dirigida a residentes de comunidades de vecinos que no tienen contratado un administrador de fincas, y son ellos mismos los que gestionan la contabilidad.

Para la realización de la encuesta se ha usado la herramienta Google Forms, la cual permite enviar un link a los encuestados y que ellos puedan responderlo online de forma confidencial. En total se han obtenido 126 respuestas de particulares y 20 de administradores de fincas.

2.4.2 Encuesta realizada a particulares

1. ¿Actualmente disponen en su edificio de un servicio de Internet comunitario?

2. En caso de que no disponer de este servicio, ¿Se han planteado la opción de un servicio de Internet comunitario en el futuro?

Fig. 3 Respuestas pregunta 2 encuesta a particulares

3. ¿Conoce alguna comunidad de vecinos de su entorno que disponga de Internet comunitario?

4. ¿Qué porcentaje de vecinos disponen actualmente de Internet en su hogar?

Fig. 5 Respuestas pregunta 4 encuesta a particulares

5. Valore de 1 a 5 el interés que los vecinos podrían tener en contratar un servicio de Internet comunitario.

6. ¿Cómo valoraría disponer de un software que realizara el cálculo de los costes, las cuotas por vecino y el ahorro por vecino que supondría el usar un servicio de Internet Comunitario en su edificio?

Fig. 7 Respuestas pregunta 6 encuesta a particulares

7. ¿Qué importancia tendría para usted la facilidad de uso a la hora de escoger un software de gestión de Internet comunitario?

8. ¿Qué importancia tendría para usted el precio de un software de gestión a la hora de elegir uno?

Fig. 9 Respuestas pregunta 8 encuesta a particulares

8. ¿A la hora de elegir un software de gestión de Internet comunitario que importancia daría usted al hecho de que fuera popular y lo usaran otras comunidades de vecinos?

2.4.3 Encuesta realizada a administradores de fincas

1. ¿Actualmente ofrece algún servicio de Internet comunitario en alguna comunidad de vecinos?

Fig. 11 Respuestas pregunta 1 encuesta a administradores de fincas 2. ¿Se ha planteado en alguna ocasión ofrecer un servicio de este tipo?

3. Valore de 1 a 5 el interés que cree que las comunidades pueden tener acerca de contratar un servicio de Internet comunitario.

Fig. 13 Respuestas pregunta 3 encuesta a administradores de fincas

4. ¿Cómo valoraría disponer de un software que automáticamente realizara un cálculo de los costes, las cuotas por vecino y el ahorro por vecino que supondría utilizar un servicio de Internet comunitario?

5. Valore el interés que puede tener en utilizar un módulo de gestión que se integre a su software de contabilidad y le permita gestionar las cuotas de Internet comunitario de forma automática.

Fig. 15 Respuestas pregunta 5 encuesta a administradores de fincas

6. Valore si estaría dispuesto a adquirir un software de este tipo.

2.4.4 Valoración resultados

En ambos casos los resultados obtenidos han sido muy satisfactorios dado que indican que este tipo de servicios despiertan un interés en los usuarios, y mayoritariamente estarían dispuestos a plantearse la contratación de un servicio de internet comunitario. Además, al ser preguntados por la posibilidad de usar un software que les facilite la gestión de los costes y la gestión de los recibos del servicio comunitario también se observa que hay interés en este sentido.

2.5. Estudio de los diferentes software existentes actualmente.

Actualmente no hay ninguna aplicación que se comercialice específicamente para gestionar el cálculo de costes que supone la compartición de Internet entre vecinos.

Hay diferentes aplicaciones de software que están destinadas a la gestión de comunidades, u otras más informales para compartir gastos entre amigos o vecinos, y que podrían ser usadas para realizar un cálculo básico de costes. Pero en todo caso debería ser el propio usuario el que configurara todos los cálculos sin que la aplicación proporcione una ayuda concreta en este sentido.

Desde el punto de vista de amigos que quieren compartir gastos de una forma informal, encontramos diversas apps que están disponibles para usar como aplicación de escritorio o bien desde el teléfono móvil. Ejemplos de estas aplicaciones són Settle Up, Splitwise o Billpin, las cuales, aunque no permiten un cálculo complejo de gastos, tienen una buena usabilidad y permiten a vecinos o compañeros de piso compartir gastos, recibos, etc. Sin embargo, estas aplicaciones no son adecuadas más allá del uso informal, ya que carecen de las posibilidades de configuración y flexibilidad necesarias para realizar cálculos más complejos.

Por otro lado, desde un punto de vista de gestión de comunidades de vecinos encontramos que hay bastantes software diferentes que permiten llevar la contabilidad de comunidades de vecinos. Se trata de programas de tipo más técnico, que necesitan un mayor tiempo de adaptación y aprendizaje por parte del usuario.

Estos programas podemos encontrarlos en formato profesional para administradores de fincas, y de tipo más ‘amateur’ para comunidades que no disponen de administradores, y es el propio presidente de la comunidad el que se ocupa de las cuentas.

Dado que estos programas están diseñados de forma que sea posible realizar configuraciones para ejecutar cálculos complejos, estos programas podrían llegarse a utilizar para calcular los costes de compartición de una conexión a internet en una comunidad, pero sería una tarea tediosa y complicada, ya que estas aplicaciones no aportan ninguna ayuda en este sentido.

Se puede observar que prácticamente todas las compañías desarrolladoras de software de este tipo no se limitan a la clásica aplicación de escritorio sino que por el contrario, ofrecen versiones en la nube a las que poder acceder mediante ordenador, tablet o teléfono móvil. A continuación enumeraré algunos de los software más populares e interesantes:

 Gesfincas: Se trata de un software para la administración de comunidades de propietarios que cuenta con más de 20 años de trayectoria, y uno de los más utilizados. Empezó en sus inicios como una aplicación de escritorio, pero actualmente también ofrece versión web. Usando los portales web de Gesfincas el administrador puede enviar información para ser consultada por los administrados, y también podrá recibir y tratar la información que estos depositen en dichos portales (cambios de domiciliación de recibos, notificaciones, etc.).

 Fincasapro: Se trata de un Software de gestión totalmente web que permite llevar la contabilidad de comunidades de propietarios; permite acceder a la aplicación desde cualquier lugar con conexión a Internet y un navegador, sin límite de usuarios ni puestos, y sin tener que instalar ningún programa en el ordenador, tablet o móvil. Además ofrece un servicio de Oficina Virtual, en la que poder mostrar toda la información deseada a los propietarios, los cuales pueden hacer la mayoría de gestiones, sin necesidad de llamar al administrador o acercarse por el despacho. Se puede contratar este software a partir de 5€ /mes.

 Fincasoft: Se trata de un programa online para la administración de comunidades de propietarios. Es un programa de uso sencillo pero que dispone de todas las funcionalidades necesarias para realizar la gestión de comunidades. Está orientado principalmente a comunidades que no disponen de administrador profesional y a administradores de fincas que se inician en la profesión. La licencia de software básica es gratuita y permite gestionar hasta 50 propiedades (pisos, garajes, etc).

 NetFincas: Sofware para la gestión de fincas que dispone de dos versiones: versión de escritorio y versión Cloud. Con más de 15000 usuarios en activo, permite gestionar todas las tareas que de gestión de comunidades de una manera fácil y cómoda. Además dispone de un módulo web y apps que permiten exportar los datos de las comunidades a Internet, con el fin de que los propietarios puedan conocer el estado de la comunidad desde cualquier dispositivo con conexión a Internet. La versión cloud puede contratarse a partir de 36 €/mes.

3 Spring Framework

3.1 Introducción

Spring es un Framework de código libre para aplicaciones basadas en Java, de forma que las aplicaciones desarrolladas con Spring se pueden ejecutar en cualquier sistema operativo con una máquina virtual de Java. Se trata de un Framework modular, flexible y poco intrusivo.

Spring Framework es una plataforma Java que proporciona una infraestructura de soporte para el desarrollo de aplicaciones Java. Spring se encarga de la infraestructura del proyecto de manera que el desarrollador puede centrarse en el desarrollo de la lógica de negocio de la aplicación.

Se trata de un Framework poco intrusivo y con una estructura modular, de manera que desarrollador puede usar únicamente los módulos necesarios para su aplicación sin necesidad de incluir el resto.

3.2 Resumen de características principales

Spring Framework se compone de diversos módulos, los cuales, cada uno ellos aportan una variedad de servicios que facilitan el desarrollo de aplicaciones. A continuación explicaré brevemente los módulos utilizados en este proyecto:

 Core Container: contiene los módulos spring-core y spring-beans, los cuales proporcionan las partes fundamentales del Framework, incluyendo IoC y la Inyección de Dependencias.

 Convención sobre configuración (Coc): mediante el uso de Sprin Boot se permite generar proyectos con facilidad, limitando las decisiones de configuración que el desarrollador debe tomar, pero sin que ello suponga una pérdida de libertad.

 Spring MVC: contiene la implementación de Spring model-view-controller (MVC) y REST Web Services para aplicaciones web. El Framework MVC de Spring proporciona una separación clara entre la parte del dominio y los formularios web, y se integra con todas las otras características de Spring Framework.

 Acceso a datos: permite trabajar con bases de datos relacionales usando Object-Relational mapping y JBDC. Ofrece integración para las más populares API de ORM como JPA y JDO.

 Spring Security: se centra en proporcionar autenticación y autorización a aplicaciones Java. Permite ser configurado para cumplir con los requisitos personalizados de cada aplicación.

En los siguientes apartados procederé a explicar con más detalle las principales características y módulos de Spring Framework.

Fig. 17 Resumen de los principales módulos que constituyen Spring Framework

3.3 Spring Core Container

Spring Core Container constituye el núcleo de Sping Framework,y se compone entre otros, de los módulos Spring Core , Spring Beans y Spring Context.

Los módulos Spring Core y Spring Beans proporcionan las funcionalidades fundamentales del Framework, incluyendo la Inversión de Control (IoC) y la Inyección de Dependencias.

3.3.1 Beans

Son Objetos Java simples gestionados por el IoC de Spring, de manera que es el propio contenedor de IoC el que gestiona su ciclo de vida. Spring está diseñado para utilizar como beans a POJOs (Plain Old Java Objects), esto permite simplificar el código y reducir el acoplamiento entre el propio código y las diferentes librerías.

Los beans se pueden configurar mediante XML o bien mediante anotaciones, las cuales se indican en el propio código mediante el símbolo @.

3.3.2 Core Container

El Core Container es uno de los puntos centrales de Spring, se ocupa de crear los objetos, de conectarlos entre sí, de configurarlos, y además controla los ciclos de vida de cada objeto mediante el patrón de Inyección de Dependencias (DI).

El contenedor de Spring se puede personalizar mediante un archivo de configuración XML o mediante una configuración basada en anotaciones. La configuración mediante anotaciones se introdujo en la versión 2.5 de Spring.

En el contenedor de Spring se suelen crear y almacenar los objetos de servicios, y objetos que nos permitan conectarnos a otras partes del sistema como BBDDs, sistemas de colas de mensajes, etc.

3.3.3 Inversión de control

La Inversión de Control, también conocido como Inyección de Dependencias, es un principio de programación en el que el flujo de ejecución de un programa se invierte respecto a los métodos de programación tradicionales, ya que se otorga a un agente externo (en Spring este agente se denomina IoC Container) cierto control del flujo de la aplicación, el cual se encarga de realizar las conexiones necesarias entre las clases dependientes.

En el patrón de Inyección de Dependencias (DI, del inglés Dependency Injection) los componentes declaran sus dependencias, pero no se ocupan de crearlas ni conseguirlas. En el caso de Spring Framework, de la obtención e inyección de las dependencias se ocupa el Spring Container.

Las ventajas del uso de la Inyección de Dependencias es conseguir un código más desacoplado, lo cual facilita la realización de testeos, y mejora la mantenibilidad del código.

3.4 Spring Boot

3.4.1 Introducción

Spring Boot es un proyecto de Spring que busca facilitar la creación de proyectos Spring Framework facilitando la configuración y eliminando la necesidad de archivos de configuración XML.

Fig. 18 Situación de Spring Boot dentro del ecosistema de Spring [3]

Un inconveniente de Spring Framework es el tiempo que se pierde realizando configuraciones de los distintos módulos de Spring. Se trata de configuraciones que a menudo son repetitivas, y pueden resultar especialmente complicadas de realizar para los programadores con poca experiencia en Spring. Spring Boot soluciona este inconveniente mediante la introducción del paradigma Convención sobre Configuración o CoC.

El paradigma de programación CoC consiste en minimizar el número de decisiones que han de tomar los desarrolladores, de manera que ahorra tiempo y permite a los desarrolladores dedicarse a la lógica de negocio de las aplicaciones.

Con esto se consigue evitar una repetición de tareas básicas a la hora de realizar las configuraciones más comunes. No obstante Spring Boot no hace perder flexibilidad, ya que en caso de necesitar una configuración específica, se podrán añadir las configuraciones necesarias sin ningún tipo de limitación.

3.4.2 Ventajas

Spring Boot permite crear aplicaciones independientes basadas en Spring, de manera rápida, y listas para ejecutarse en entornos de producción. Incorpora librerías propias y de terceros que permiten empezar a trabajar con un mínimo esfuerzo. La mayor parte de aplicaciones de Spring Boot necesitan muy poca configuración.

Funciones que aporta Spring Boot:

 Permite crear aplicaciones Spring independientes.

 Incorpora Tomcat incrustado: al realizar un deploy del proyecto se arranca un servidor Tomcat automáticamente. Esto nos evita la necesidad de utilizar un servidor Tomcat externo y nos facilita el despliegue de aplicaciones en servidores Cloud .

 Proporciona un archivo POM por defecto para facilitar la configuración de Maven.  Siempre que es posible configura Spring automáticamente.

 No genera absolutamente ningún tipo de código extra.

Fig. 19 Ejemplo de fichero POM creado por Spring Boot

3.5 Inyección de dependencias en Spring

Habitualmente una aplicación no consiste de un único objeto (o bean si hablamos de Spring). Incluso las aplicaciones más simples tienen objetos que interaccionan entre sí para presentar lo que el usuario percibe como una aplicación coherente. En este apartado se explica cómo a partir de unas beans que en principio están definidas sin estar relacionadas las unas con las otras, podemos crear una aplicación donde los objetos colaboran entre sí. La inyección de dependencias trata de un proceso por el cual los objetos definen sus dependencias (es decir los objetos con los que trabaja) solo mediante argumentos en un constructor, argumentos en un patrón factoría, o propiedades que se añaden a una instancia de un objeto después de ser construido por un patrón factoría. Posteriormente el contenedor inyecta las dependencias cuando crea el bean.

Este proceso es fundamentalmente el inverso, de ahí el nombre Inversión de Control (IoC), del propio bean controlando la instanciación o localización de sus dependencias mediante la construcción directa de clases.

3.5.1 Ventajas de la inyección de dependencias

Usando el principio de Inyección de dependencias se consigue un código más limpio, y un menor acoplamiento ya que los objetos están provistos de sus dependencias. Además las clases son más fáciles de testear, especialmente cuando las dependencias están en interfaces o clases abstractas, lo cual permite realizar implementaciones tipo mock para ser usadas en los test.

3.6 Formas de inyección de dependencias

En este apartado se detalla cómo se realiza la inyección de dependencias, y las diferentes formas de inyectar dependencias. Primero se muestra un código en el que no se usa inyección de dependencias, posteriormente se muestra como será ese mismo código aplicando la inyección de dependencias.

3.6.1 Código sin inyección de dependencias

A continuación se muestra un ejemplo de código sin inyección de dependencias:

Fig. 21 Ejemplo de código sin inyección de dependencias

En este ejemplo tenemos una clase llamada NotUsingDependencyInjectionExample en la cual la lógica de negocio se ha movido a dos servicios: Uno llamado ServiceA y otro ServiceB.

De esta forma, cada vez que se crea un objeto NotUsingDependencyInjectionExample, en el controlador de esta misma clase, se necesitan instancias de ServiceA y ServiceB, y estas instancias se obtienen mediante la realización de un new para cada uno de los dos servicios dentro del controlador.

Esto produce un acoplamiento entre el controlador y los dos servicios, es decir, no podríamos crear una instancia de NotUsingDependencyInjectionExample sin disponer de una instancia de ServiceA y ServiceB.

Este acoplamiento dificulta la realización de pruebas y test, ya que en caso de desconocer el contenido de los servicios (por ejemplo si se conectan a una base de datos, y su contenido es cambiante), esto dificulta la realización de pruebas unitarias sobre el controlador de la clase NotUsingDependencyInjectionExample.

3.6.2 Código usando inyección de dependencias

Según lo indicado anteriormente, la inyección de dependencias es un patrón en el que los objetos dependientes se inyectan en la clase. Spring framework se ocupa de realizar esta inyección, pero el desarrollador es quien ha de codificar las clases para que Spring pueda realizar la inyección.

Básicamente hay 2 tipos de inyección: una basada en constructor, y otra basada en setters. También hay una tercer tipo llamado field injection, pero su uso se desaconseja por estar considerado una mala práctica.

3.6.2.1 Inyección de dependencias mediante constructor

El equipo de Spring recomienda como norma general el uso de inyección de dependencias basada en constructor, tal y como se refleja en las documentaciones de Spring a partir de la versión 4.x. [4]

La inyección de dependencias basada en constructor permite asegurar que al instanciar un objeto, sus dependencias se inyectarán y por tanto no serán null; se garantiza además que las instancias en el momento de ser instanciadas estarán en un estado totalmente inicializado y listo para ser usado, cosa que por el contrario en inyecciones de dependencias basadas en setters no se garantiza.

Otra consecuencia del uso de constructor para inyectar dependencias es que se impide la dependencia circular entre dos objetos (en la inyección mediante setter sí es posible la dependencia circular). De hecho esto es positivo ya que las dependencias circulares se deben evitar y generalmente son muestra de un mal diseño. De esta manera se evita el uso de una práctica de este tipo.

Fig. 22 Inyección de dependencias mediante constructor

3.6.2.2 Inyección de dependencias mediante en setters

Si bien la recomendación que venía reflejada en la documentación de Spring en las versiones 3.x alentaba el uso de la Inyección basada en setters [5], en actuales versiones de Spring se recomienda evitar su uso, en la medida que sea posible, para la inyección en dependencias obligatorias (mandatory).

Se recomienda reservar la inyección de dependencias mediante setter para la inyección de dependencias opcionales. Es decir, en casos en los que la clase es capaz de funcionar aun cuando estas dependencias opcionales no le han sido inyectadas.

3.6.2.3 Inyección de dependencias mediante inyección de campo

Se basa en inyectar las dependencias directamente en los atributos de una clase, sin hacer uso de setters ni de constructor, en inglés se denomina Field Injection. Si bien a simple vista puede parecer muy tentador por la simplicidad del código, esta forma de inyección de dependencias está totalmente desaconsejada, y se considera una mala práctica [6].

Fig. 24 Inyección de dependencias mediante inyección de campo

Uno de los problemas del DI mediante inyección de campo es que es muy fácil agregar nuevas dependencias. Demasiado fácil, no hay ningún problema en añadir, diez o incluso más dependencias. Cuando se utilizan constructores para DI, en ocasiones, el número de parámetros del constructor se vuelve demasiado alto, esto permite detectar que el diseño del constructor o de la clase son mejorables. Tener demasiadas dependencias generalmente significa que la clase tiene demasiadas responsabilidades. Esto puede provocar una violación de los principios de diseño de responsabilidad única y de la separación de intereses.

Otro inconveniente de DI mediante inyección de campo es que se omite el modo por el cual se inyectan las dependencias. Es decir, cuando se usa la inyección de dependencias, significa que la clase ya no es responsable de administrar sus propias dependencias. La responsabilidad de obtener las dependencias corresponde al propio Spring DI container. Cuando una clase ya no es responsable de obtener sus dependencias, debe comunicarlo claramente usando métodos o constructores. De esta manera queda claro las dependencias que la clase requiere y también si la dependencia es opcional (setters) o obligatoria (constructor).

Por otro lado, indicar que la DI mediante inyección de campo produce un acoplamiento entre las dependencias, y el DI container, contraviniendo así, una de las ideas principales de la Inyección de dependencias, la cual indica que la clase administrada no debe tener ninguna dependencia del contenedor DI utilizado.

En otras palabras, la clase administrada debe ser sólo un POJO simple, que puede ser instanciado de forma independiente, siempre que se le pasen todas las dependencias requeridas. De esta manera se puede instanciar en un test unitario sin iniciar el contenedor DI y probarlo por separado. Cosa que no se puede hacer con DI mediante inyección de campo, ya que queda acoplada con el DI container, y no se puede testear fuera de él.

Por último indicar que con este método de inyección de dependencias, no se indica una forma directa de instanciar una clase con sus requeridas dependencias, esto implica que si se llama al constructor por defecto cuando algunas de las dependencias necesarias no está correctamente instanciada, se producirá un error de NullPointerException.

3.6.2.4 Uso de interfaces en la inyección de dependencias

El uso de interfaces a la hora de realizar la inyección de dependencias es muy recomendable, ya que proporciona una gran flexibilidad y facilita las tareas de testing. Se trata de definir una instancia de tipo interfaz como dependencia que se va a inyectar en una clase, así se consigue que cualquier objeto que implemente la interfaz se pueda inyectar en esa clase.

A continuación se muestra un ejemplo en donde el objeto que se va a inyectar es de la clase ServiceExample. En la figura se puede ver la creación de la interfaz.

Se crea una clase ServiceExampleImpl la cual implementa la interfaz.

Fig. 26 Implementación de la Interfaz ServiceExample

Por último inyectamos la dependencia usando el constructor de la clase, nótese que se realiza la inyección de una instancia de tipo interfaz, pero en tiempo de ejecución se instanciará el objeto de la clase que la implementa.

Fig. 27 Se inyecta el servicio en el controlador

3.6.2.5 Uso de dependencias en este proyecto

Siguiendo las buenas prácticas recomendadas por el equipo de desarrolladores de Spring, en este proyecto se ha usado la inyección de dependencias mediante constructor para realizar la inyección de los Servicios. Además la inyección de dependencias de los servicios se realiza usando una interfaz, lo que permite mayor flexibilidad.

A continuación se muestran dos fragmentos de códigos: por un lado tenemos la interfaz ProviderService en la que se declaran 2 métodos, y por otro la clase ProviderServiceImp que implementa la interfaz ProviderService.

Fig. 28 Fragmento de código de la interfaz ProviderService

Fig. 29 Fragmento de código donde se implementa la clase ProviderService

Por último tenemos la inyección de una instancia tipo interfaz ProviderService en el controlador ProviderController. Nótese que en tiempo de ejecución se instanciará un objeto de la clase que implementa la interfaz, esto es: un objeto de la clase ProviderServiceImp.

3.7 Configuración de dependencias mediante anotaciones

En este apartado se trata el uso de la configuración de las dependencias; hay dos maneras de realizar la configuración de dependencias: mediante un fichero XML o mediante anotaciones. Dado que la configuración XML está cada vez más en desuso, nos centraremos en la configuración mediante anotaciones.

La configuración mediante anotaciones es una manera muy útil e interesante para configurar aplicaciones Spring, ya que no únicamente se facilita el proceso de configuración, sino que además la configuración resultante es clara y fácil de interpretar.

3.7.1 Anotación de Spring beans

Los beans son el núcleo de nuestra aplicación, son los componentes que se cargarán en el contenedor de Spring (aplicationContext), y será el propio Spring el que se ocupe de su carga, unión (wire) y administración.

Los principales componentes de Spring son los 4 siguientes:  Component

 Service  Repository  Controller

A continuación se procede a explicar las características de cada uno de ellos: 1. @Component

Esta anotación es un indicador genérico para Spring beans, e indica que el objeto sobre el cual se anota es un componente gestionado por Spring. Es la anotación más genérica de un componente Spring.

No es una anotación muy usada habitualmente, ya que en vez de ello suele usarse alguna de sus especializaciones: @Repository, @Service y @Controller son especializaciones de @Component para casos concretos (persistencia, servicios y presentación).

Fig. 31 Anotacion @Component en realacion a @Controller, @Service y @Repository

2.@Repository

Se trata de una especialización de @Component para la indicación de Objetos de Acceso a Datos (DAO), en otras palabras, para indicar que clases se utilizan para persistencia. 3. @Service

Es otra especialización de @Component que se usa para informar a Spring de como cargar las clases de Servicio. Según las recomendaciones de Spring la lógica de negocio de las aplicaciones se debe implementar en las clases de Servicio.

4. @Controller

Se usa para indicar que las clases con la anotación @Controller son usadas como Controlador. Esta anotación es muy utilizada en aplicaciones que usan Spring MVC.

3.7.2 Otras anotaciones

@RequestMapping

Se trata de una de las anotaciones importantes en el desarrollo de aplicaciones web en Spring. Se usa para definir las peticiones URLs que invocan a métodos del controlador. Adicionalmente se puede especificar el método de petición HTTP que se espera (GET, POST). Esta anotación se puede definir tanto para la clase en sí como para métodos concretos.

@PathVariable

Se trata de una anotación que sirve para indicar a Spring que un parámetro de un método está enlazado a un patrón determinado en el path del URI. Se usa en métodos de controlador que estén anotados con @RequestMapping.

3.6.3 Conexión de dependencias

@Autowired

En versiones previas de Spring, las dependencias debían ser especificadas en archivos XML, actualmente las dependencias pueden ser automáticamente detectadas y unidas (wired) por Spring usando la anotación @Autowired. Esto elimina la necesidad de realizar configuraciones XML.

@SpringBootApplication

Esta anotación es núcleo de las aplicaciones que usan Spring Boot. La clase anotada con @SpringBootAplication será la clase principal de la aplicación, en otras palabras ‘el main’ de la aplicación. La anotación @SpringBootAplication sustituye el uso de las anotaciones @Configuration, @ComponentScan y @EnableAutoConfiguration simplificando así el código.

4 Entorno de desarrollo

4.1 Plataforma de desarrollo

4.1.1 IntelliJ IDEA

El IDE que he utilizado para el desarrollo de la aplicación es IntelliJ IDEA, el cual está desarrollado por la empresa JetBrains. El motivo de elegir este IDE es su buena integración con Spring Framework y las facilidades que aporta a la hora del desarrollo. A continuación explico algunas de sus características más interesantes.

Inspección exhaustiva del código: IntelliJ IDEA analiza el código del proyecto, buscando conexiones entre símbolos entre todos los archivos. Usando esta información proporciona ayuda de codificación en profundidad y navegación rápida.

Función autocompletar inteligente: al presionar Ctrl + Shift + Space se obtiene una lista de los símbolos más relevantes en el contexto concreto. Estas y otras acciones de autocompletar están continuamente aprendiendo de las preferencias del usuario, de esta forma en la lista de sugerencias se muestran primero los objetos, métodos de las clases y paquetes más comúnmente usados por el usuario.

Función autocompletar en clases estáticas: Permite usar métodos estáticos o constantes de manera sencilla. Aun no teniendo las clases importadas, IntelliJ ofrece símbolos pertenecientes a esas clases en la función autocompletar. Además IntelliJ se ocupa de añadir automáticamente todos los imports necesarios.

Fig. 33 Ejemplo autocompletar clases estáticas IntelliJ

Inspección de flujo del código: al ofrecer opciones de autocompletar, IntelliJ IDEA analiza el flujo del código para investigar las características que cada símbolo tendrá en tiempo de ejecución. De esa manera es capaz de afinar aún más las sugerencias e incluso, añadir automáticamente castings en caso de ser necesarios.

Refractorización avanzada: dado que IntelliJ inspecciona todo el código y conoce la función de cada objeto y clase utilizado, al hacer una refactorización de una clase, método u objeto, utiliza esta información para aplicar la refactorización de manera correcta en todo el código.

Fig. 35 Refactorizando con IntelliJ

Detección automática de errores: si en cualquier momento IntelliJ detecta que está cometiendo un error te avisa de ello y te ofrece las mejores alternativas para solucionar el error.

Interfaz de usuario basada en el editor: la mayor parte de su tiempo el editor (y el código) es lo único visible en su pantalla, y no es necesario salir del editor para realizar tareas no relacionadas con el editor.

Depurador avanzado: Cuando se usa el depurador de código IntelliJ nos indica el valor de las variables en cada línea y nos muestra el valor de las variables que se modifican sin necesidad de realizar ninguna configuración adicional.

Integración con Control de Versiones: proporciona integración con los principales sistemas de control de versiones: GIT, Mercurial, SVN.

Herramientas de Bases de datos: herramientas para trabajar con MySQL, Oracle, PostgreSQL, Microsoft SQL Server.

Control de dependencias: IntelliJ soporta Maven y Gradle.

Integración con Spring Framework: ofrece una buena inspección de código y asistencia a la codificación usando Spring Framework.

Fig. 36 Navegación por el código de un proyecto Spring

4.1.2 Java 1.8

En el desarrollo de este proyecto utilizo la versión 1.8 de Java, que es la versión más reciente de JDK disponible actualmente. Algunas de las mejoras que aporta esta versión frente a JDK 1.7 son la incorporación de expresiones Lambda y una seguridad mejorada.

4.1.3 Mamp

Dado que para la persistencia de la aplicación hago uso de una base de datos MySQL, se hace necesario el uso de un servidor de MySQL. Me he decantado por el uso de Mamp porque es un servidor ligero y sencillo de configurar.

Se trata de una aplicación desarrollada por la compañía Appsolute, y además del servidor MySQL ofrece un servidor Apache Tomcat.

Fig. 37 Imagen del menú phpMyAdmin de Mamp

4.2 Tecnologías usadas en el desarrollo

4.2.1 Spring Boot

Spring Boot es un proyecto de Spring que nos ayuda a iniciar proyectos de Spring de una manera ágil y evitando, en gran medida, la necesidad de configuración. Esto permite mejorar en gran medida la experiencia del desarrollador, ya que puede dedicar su tiempo al desarrollo de la aplicación.

Las características más interesantes de Spring son las siguientes:

Convención sobre configuración: en lugar de escribir manualmente la configuración necesaria y validar si es correcta, Spring Boot nos aporta las configuraciones necesarias para diferentes escenarios. Así se evita al desarrollador de esta tarea repetitiva.

Autoconfiguración: Spring Boot realiza la autoconfiguración del proyecto siempre que sea posible.

Administración de dependencias: No es necesario indicar la versión de las dependencias. Spring Boot se ocupa de administrar las versiones de las dependencias, añadiendo las dependencias estables más recientes en cada caso.

Servidor incrustado: soporta un servidor Tomcat incrustado. Con ello se permite la ejecución del proyecto sin necesidad de desplegar archivos .war.

Fig. 38 Herramienta Spring Initializr para iniciar proyectos Spring Boot

4.2.1.1 Buenas prácticas en Spring Boot

Siguiendo la documentación de Spring Boot voy a explicar ciertas prácticas que el equipo de Spring considera ‘Best Practices’[7]:

4.2.1.2 Estructura del código:

Si bien Spring Boot no requiere una estructura determinada las siguientes prácticas son recomendables [4]:

 Las clases han de estar dentro de un package. Cuando no se especifica un package para una clase, se considera que está en el paquete por defecto (‘default

package’), y esto puede dar problemas en aplicaciones que usan las anotaciones @SpringBootApplication, @ComponentScan o @EntityScan

 Localización del main: Se recomienda que el main esté en la raíz del proyecto por encima de las demás clases. En esa clase se usará la anotación @SpringBootAplication.

Fig. 39 Estructura típica de un proyecto Spring Boot

4.2.1.3 Configuración

 El equipo de Spring Boot recomienda el uso de la configuración basada en anotaciones Java en detrimento de las configuraciones mediante archivos XML.  Se recomienda que la clase principal se defina como una clase de configuración

principal (@Configuration).

 Habitualmente la clase que se define como main es una buena candidata para ser la clase de configuración principal.

4.2.1.4 Inyección de dependencias

Aunque cualquier técnica estándar de inyección de dependencias se considera correcta, el equipo de Spring recomienda usar @ComponentScan para encontrar las beans, en combinación con una inyección de dependencias mediante constructor, anotando además al constructor con @Autowired.

En los proyectos que siguen la estructura recomendada anteriormente, se puede añadir la notación @ComponentScan sin argurmentos. Y todos los componentes de la aplicación (@Component, @Service, @Repository, @Controller, etc.) se registrarán automáticamente como Spring Beans.

4.2.1.5 @SpringBootApplication

Si se siguen las buenas prácticas mencionadas anteriormente, es muy probable que la clase principal de cada proyecto esté anotada con las anotaciones @Configuration, @EnableConfiguration y @ComponentScan.

Teniendo esto en cuenta, Spring Boot ha creado la anotación @SpringBootApplication la cual es equivalente al uso de las anotaciones @Configuration, @EnableConfiguration y @ComponentScan con sus atributos por defecto.

4.2.3 Maven

Maven es una herramienta de software para la gestión y desarrollo de proyectos Java actualmente desarrollada por Apache Software Foundation y distribuida bajo licencia open source apache.

Maven permite facilitar la gestión de las dependencias de los proyectos, ya que al definirlas en el archivo POM el propio núcleo de Maven es capaz de descargarlas de un repositorio público de Maven que provee acceso a gran cantidad de proyectos Open Source.

Cada proyecto Maven cuenta con un archivo XML llamado pom.xml (Project Object Model) en el cual se describe el proyecto, sus dependencias con otros módulos y componentes externos.

Un detalle muy interesante en la gestión de dependencias de Maven es que también resuelve las dependencias transitivas. Es decir, si a un proyecto le añadimos una dependencia A, que a su vez contiene una dependencia a un proyecto B y éste otra dependencia a un proyecto C, Maven automáticamente descargará las dependencias A, B y C.

Fig. 40 Fichero POM del proyecto Internet-Manager

4.2.4 MySQL

MySQL es un sistema de gestión de bases de datos relacional multihilo y multiusuario distribuida por Oracle. Está considerado como el gestor de bases de datos de código abierto más popular del mercado.

Por su velocidad, fiabilidad y facilidad de uso se trata de una base de datos muy utilizada en proyectos web, siendo la base de datos elegida por ejemplo por facebook, Twiter y youtube.

4.2.5 HTML, CSS, Bootstrap, jQuery

Para el diseño de la interfaz web, dado que el coste en tiempo de realizar un diseño HTML y CSS desde cero es muy alto, he optado por trabajar sobre un template predefinido. Hay gran cantidad de empresas y diseñadores que ofrecen templates tanto en versiones open source como versiones personalizadas de pago.

He optado por la utilización del template Admin LTE disponible en la página https://adminlte.io, se trata de un template open source distribuido bajo licencia MIT. Este template hace uso de las librerías Bootstrap3 y jQuery1.11+, y ofrece variedad de componentes y estilos que se pueden utilizar para la interfaz del proyecto.

4.2.6 Thymeleaf

Se trata de una librería de Java que actúa como un motor generador de plantillas web. Thymeleaf es capaz de aplicar un conjunto de transformaciones a las plantillas para mostrar datos y textos producidos por las aplicaciones.

Está especialmente diseñado para funcionar con aplicaciones web diseñadas con XHTML y HML5, pero también puede procesar cualquier archivo XML tanto en web como en aplicaciones independientes.

Thymeleaf dispone de un módulo que se integra perfectamente con Spring MVC y permite sustituir totalmente el uso de JSP (JavaServer Pages). Con Thymeleaf la creación de plantillas dinámicas es más sencilla ya que solo es necesario etiquetar el código de los archivos HTML donde irán los datos dinámicos.

A continuación voy a poner un ejemplo de código de mi proyecto generado por Thymeleaf y su comparación con la plantilla HTML para que se vean las diferencias.

En la plantilla residents.html de mi proyecto, se define un bucle con Thymeleaf mediante la etiqueta th:each. Una vez procesado por Thymeleaf se creará una fila por cada residente que se envíe desde el controlador.

Fig. 41 Bucle definido con Thymeleaf

Una vez Thymeleaf procesa el código, se crea una fila con sus correspondientes columnas con los datos de cada residente. El fichero que genera y el cual se envía al navegador es HTML5 estándar sin ningún tipo de anotación extra:

.

4.3 Despliegue de la aplicación

En este capítulo explico como realizar la ejecución de la aplicación en un entorno local y como desplegarla en un servidor Cloud.

4.3.1 Despliegue local

Para el despliegue en local de nuestra aplicación se necesitan las siguientes características de software:

 IntelliJ IDEA  JDK 1.8

 Un servidor local MySQL

El primer paso que tenemos que realizar para desplegar la aplicación es configurar el entorno de desarrollo. En IntelliJ se configura de la siguiente forma:

 Se agrega una nueva configuración de Run/Debug:

Fig. 43 Menú de nueva configuración para el despliegue

 Se añade una nueva configuración de Application, y se despliega un menú donde hay que seleccionar la clase principal y el path al jre local:

Fig. 44 Configuración para desplegar la aplicación

Dado que en el proyecto se usa MySQL para persistencia, es necesario tener un servidor MySQL ejecutándose en local para que al ejecutar la aplicación funcione correctamente. Cualquier servidor es válido, si bien en mi caso he utilizado Mamp por su sencillez de configuración.

Una vez hayamos desplegado la aplicación en local, se podrá acceder a la interfaz de la aplicación mediante el navegador, como se aprecia en la siguiente imagen.

Fig. 46 Imagen del login de la aplicación ejecutándose en local

4.3.2 Despliegue de en servidor Cloud (Heroku)

Heroku es una empresa subsidiaria de Salesforce, que ofrece servicios Cloud Paas (platform-as-a-service). Heroku ofrece las herramientas necesarias para facilitar el despliegue de aplicaciones en la nube.

Una característica muy interesante de Heroku es que si lo deseamos, se puede subir la aplicación desde una rama de un repositorio Git y permitir deploys automáticos. Es dedir que cada vez que hagamos un push de la rama seleccionada en Git automáticamente se desplegará la aplicación con el código actualizado en Heroku.

El despliegue de aplicaciones en Heroku es gratuito si se opta por un servicio básico. Si se opta por un servicio avanzado se ofrecen diferentes planes de precios según los servicios que se necesiten. Entre las limitaciones del servicio gratuito está que las aplicaciones desplegadas en Heroku se pondrán en modo sleep tras 30 minutos de inactividad.

El proceso para desplegar una aplicación en Heroku es muy sencillo e intuitivo, a continuación lo detallo:

 Para dar de alta una aplicación en Heroku tenemos que registrarnos en la página www.heroku.com.

 Una vez registrados con nuestro usuario seleccionamos la opción Create New App y se nos despliega un menú en el que debemos indicar el nombre de la aplicación y la región, y presionar Create App:

Fig. 47 Menú Create New App

 El siguiente paso es seleccionar el método para subir el código de la aplicación. En mi caso tengo el código en un repositorio de GitHub así que elijo la opción subir desde GitHub, y selecciono el nombre del repositorio donde tengo la aplicación.

 En el siguiente paso se selecciona la rama desde la cual subir el proyecto y seleccionar deploy manual o deploys automáticos y se desplegará la aplicación.

Fig. 49 Selección de rama del proyecto a desplegar y despliegue del proyecto

 Dado que este proyecto necesita de un servidor MySQL, activaremos un add-on que Heroku ofrece, y que proporciona un servidor MySQL a la aplicación.

 Dado que tenemos la aplicación desplegada en la nube, podemos acceder a ella desde la URL que nos proporciona Heroku:

5 Análisis de requisitos de la aplicación

5.1 Especificación

Se va a desarrollar una aplicación web para la gestión y administración de los gastos de servicios de internet comunitario en comunidades de vecinos. La aplicación permitirá la administración de los residentes, las comunidades, los contratos con proveedores así como la emisión de facturas. Se establecerán 3 tipos de usuarios: administrador, presidente de comunidad y residente con roles diferenciados.

El desarrollo del prototipo de la aplicación se realizará en inglés, dado que se ha considerado que esto facilitaría su futura traducción a distintos idiomas.

5.1.1. Usuarios

A continuación se describen las características de cada tipología de usuario:

Administrador: este usuario es el administrador total de la aplicación. Únicamente se usará para la administración de la aplicación. Este usuario lo usará el administrador de fincas (si lo hubiere).

Presidente: este usuario es el presidente de la comunidad de copropietarios, o en su defecto la persona responsable del Servicio de Internet Comunitario en la comunidad de copropietarios. A su vez también es un usuario de Internet Comunitario. Puede haber más de un presidente por comunidad.

Residente: Por cada vivienda dada de alta en el servicio de Internet Comunitario hay una persona responsable de la vivienda. A esta persona se le otorga un usuario de la aplicación de tipo residente. Es decir, por cada vivienda dada de alta en el servicio hay un único usuario residente.

Dado que la aplicación es únicamente para la gestión del servicio de Internet Comunitario de comunidades de vecinos, la consigna de uso de la aplicación es dar de alta únicamente a los residentes que son usuarios del servicio de Internet Comunitario. Así si en una comunidad de propietarios hay algún vecino que no participa en este servicio, no se le daría de alta en la aplicación.