Arteco Radis - Trabajo Proyecto fin de Máster

Aplicación SaaS para la

Administración de Fincas

Ramón Arnau GómezMiquel Mascaró Portells

Universidad de las Islas Baleares

Este documento corresponde a la memoria de las tareas realizadassobre de desarrollo de un aplicativo accesible desde Internet, en lamodalidad Software como Servicio, como trabajo de final de Másterde Tecnologías de la Información de la Universidad de las IslasBaleares. Dicho aplicativo tiene como objetivo desarrollar un modelode negocio basado en el pago por uso de un aplicativo destinado a lagestión online de comunidades de vecinos, que permita controlar ydistribuir el gasto originado por el mantenimiento y mejora de lasfincas comunitarias o condominios. Este trabajo pondrá de manifiestolas acciones realizadas en las fases de análisis, diseño, implementacióny despliegue en producción de un aplicativo que está abierto a Internetpara cualquier usuario. Se describirán las medidas tecnológicasnecesarias para que la información sea consistente, segura y fiable,mientras se mantiene la privacidad requerida por el tratamiento dedatos personales en un sistema multi-usuario.

Palabras clave: Aplicación SaaS, Alta disponibilidad, Multi-usuario.

© 2013 Universitat de les Illes BalearsMàster Universitari en Tecnologies de la Informació (MTIN)http://postgrau.uib.cat/es/master/MTIN/

1. INTRODUCCIÓN

Motivación

La aparición de Internet y el Cloud Computing o Computación enla Nube, ha abierto la puerta a nuevos modelos de negocio basadosen el alquiler de recursos y pago por uso. De la tradicional venta desoftware empaquetado en CD o DVD con una determinada licenciade uso, se ha pasado a un modelo de negocio en donde el softwareestá accesible por el usuario a través de Internet, dispuesto en losrecursos propios de fabricante o vendedor. Es el vendedor quien sehace responsable de la disponibilidad de las funcionalidades y lacustodia de la información.

Este nuevo modelo de negocio alojado en la nube ha permitido queempresas con pocos recursos dispusieran de una infraestructuradonde ofrecer servicio al público general en sistemas abiertos enInternet en muy corto espacio de tiempo. Donde el coste quesoporta el fabricante o proveedor de software es proporcional alvolumen o tamaño del sistema que gestiona.

Ante este nuevo marco tecnológico aparecen una multitud deaplicaciones apoyadas en infraestructuras Cloud con la idea decubrir necesidades y sacar al mercado nuevos serviciosrápidamente en un ciclo corto de innovación y mejora continua. Eneste entorno aparece la aplicación de este trabajo, Arteco Radis,en modalidad SaaS (Software as a Service, Software comoServicio) o llamado de forma llana pago por uso.

Arteco Radis: una innovadora plataforma de gestión decomunidades de vecinos o condominios, 100% online. Donde lospropietarios o administradores de fincas pueden gestionar losgastos de la comunidad derivados del mantenimiento yrehabilitación. Los usuarios pueden distribuir los gastos de maneramuy flexible para adaptarse a los acuerdos plasmados en losestatutos comunitarios con el sistema general de distribución porcoeficientes por propiedad.

Es un sistema accesible por Internet desde cualquier conexión ainternet, computadora personal o dispositivo móvil que dispongade un navegador web compatible con los estándares de la WorldWide Web Consortium (W3C).

https://radis.artecoapps.com

Actualmente el sistema se encuentra en producción después de unproceso que ha durado cerca de 3 años desde su inicio, con más de500 visitas únicas semanales. En un total de 20.000 páginasservidas por semana y distribuidas entre 54 comunidadesadministradas. Se puede encontrar en las primeras páginas deresultados de Google en búsquedas con las palabras clave“Software Administración Fincas” y “Administración FincasOnline”.

Objetivo

Informado al lector sobre el entorno y el objeto de la memoria, lafinalidad del trabajo realizado es demostrar cómo se puedeconsolidar un proyecto de iniciativa personal con una inversióneconómica reducida, usando las Tecnologías de la Información yherramientas innovadoras y la programación orientada a objetos[1] para solventar una necesidad existente. Llevado a cabo con unainversión mucho menor que la que puede darse en otros sectoresempresariales que típicamente conllevan barreras de entrada concostes muy superiores.

Se describirá a lo largo del documento los puntos que han hechoposible la puesta en marcha de Arteco Radis en donde se hanrealizados las siguientes tareas principales:

• Se ha definido los procedimientos y requisitosfuncionales que ha de cubrir el aplicativo para el marcode trabajo de los Administradores de fincas.

• Escrito los requisitos adicionales derivados de unsistema multi-usuario y multi-empresa [2].

• Creado un plan con mecanismos de seguridad eintegridad para asegurar el control del flujo deinformación y los accesos no autorizados. Y,

• Elaborado procedimientos de despliegue en entornosCloud y de alta disponibilidad. Con adaptación flexible ala carga de trabajo [3].

Máster Universitario en Tecnologías de la Información, Universidad de les Islas Baleares, 2013.

http://postgrau.uib.cat/es/master/MTIN/

2 • Ramón Arnau Gómez

Contenido

Este proyecto resume las tareas realizadas en la elaboración de unproducto desde la etapa de diseño hasta el despliegue enproducción de una herramienta de software, ejecutándose en unentorno tecnológico flexible como ofrece el Cloud Computing.

Se nombrarán los principales puntos de interés en cada una de lasetapas de la producción. Este documento no pretende ser una guíacompleta del proceso, si no una memoria que refleje los problemasencontrados y las soluciones adoptadas en la puesta en marcha delSistema de Información, desde el punto de vista de la formaciónadquirida en el Máster de Tecnologías de la Información.

Para completar los objetivos del proyecto se siguieron los procesosgenéricos de desarrollo de aplicaciones Web [4], sobre los cuales sehan incorporado adaptaciones específicas por el ámbito y alcancedel proyecto:

• Definición de la Misión y Visión de la iniciativa.• Definición de los procesos de negocio requeridos por los

Administradores de fincas:◦ Gestión de los propietarios.◦ Gestión de los gastos.◦ Liquidación de los gastos entre propietarios.◦ Entrega de informes periódicos.◦ Generación y entrega de recibos.◦ Facturación de honorarios y material de oficina.◦ Portal del propietarios.

• Elección de la tecnología del desarrollo. Lenguaje deprogramación, framework de programación web, yservidor de aplicaciones.

• Implementación de las funcionalidades. Consideracionesde rendimiento y seguridad aplicadas en la metodologíade desarrollo.

• Y, despliegue en el proveedor Cloud Amazon WebServices Elastic Cloud Computing.

2. NACIMIENTO DE LA IDEA

A través de circunstancias personales, en 2009 apareció laposibilidad de formar parte en una empresa con mucha historia enel sector de administradores de fincas, con más de 30 años deexperiencia. Gracias a esa participación, se adquirieron losconocimientos necesarios de los métodos y de los procesos querigen el día a día de los Administradores de Fincas. Además con laaparición del modelo de negocio pago por uso, rápidamentecreciente, se dio lugar a la posibilidad de crear una plataforma querenovara los procesos internos de la administradora de fincas comoparte de su evolución interna y mejora respecto a la competenciacomo elemento diferenciador.

Uno de los principales puntos fuertes de las aplicaciones de pagopor uso en herramientas de gestión dando el salto a Internet ytrasladando los datos a la nube, es que se dispone de un aplicativoque prácticamente está siempre Online, con informaciónactualizada y consistente en tiempo real y con un coste demantenimiento mínimo. Los usuarios se vuelven más productivosya que hay menos fuentes de problemas o incidentes que puedenaparecer derivados del mantenimiento de los equipos informáticosde sobre mesa.

En el sector de la administración de fincas, tradicionalmente lasaplicaciones de gestión usadas han sido aplicaciones de escritoriocon poca o ninguna integración cliente/servidor y con altos costesen licencias por uso o por instalación, cuya falta de actualizaciónha obligado en muchos casos a mantener equipos informáticosobsoletos en funcionamiento.

Aprovechando el mercado emergente y considerando laslimitaciones de las aplicaciones de escritorio, se consolidaba laidea de desarrollar una plataforma propia. Al mismo tiempo se diola posibilidad de realizar una inversión adicional en esfuerzo paraque otras Administraciones de Fincas también pudieran usar estanueva herramienta. Generalizando el alcance a un mercado másglobal y abriendo la puerta incluso a cualquier posible usuario delterritorio nacional o internacional.

Por lo tanto, uno de los primeros pasos era determinar el alcancedel aplicativo en donde quedaran reflejadas las funcionalidadesnecesarias para que cualquier Administrador de Fincas del ámbitonacional pudiera ver útil el aplicativo. Y determinar así, si elalcance del proyecto era asumible por la dirección dados losrecursos disponibles tanto financieros como humanos.

Para facilitar la puesta en marcha de la iniciativa, se determinaron3 fases o hitos que permitirían realizar un análisis detalladomarcando objetivos más concretos y que permita validar la correctaimplementación de los requisitos funcionales y la continuidad delproyecto según el avance.

Las fases determinadas en el alcance fueron:

1. Gestión de los datos de la comunidad y propietarios.

2. Realización de liquidaciones de gasto vencido y de presupuesto.

3. Implementar un Portal del Propietario.

En la fase 1, el objetivo era realizar una primera aproximación alfuncionamiento de inserción de datos protegidos por la LOPD yapuntes contables de forma segura en un entorno Web, donde losusuarios internos de la Administración de Fincas pudieranexperimentar en la gestión de la información contenida, en formade altas, bajas de propietarios, propiedades, grupos de distribucióny demás conceptos que formarían la base del proceso deliquidación.

En este punto, el usuario interno debía validar el método deintroducción de datos dentro de un grupo de trabajo con variosgestores de comunidades. Pasar de un entorno mono puesto, a unaaplicación online. La aceptación del cambio desde un entorno detrabajo con software local a un entorno distribuido y dispersogeográficamente serviría como apoyo para la realización delproyecto, no sólo en la formalización de la viabilidad del proyecto,sino también para la toma de impresiones de los usuarios externos(otros Administradores), que aparecerían a la hora de plantearse elcambio de plataforma de gestión.

Una vez superada la gestión del cambio, el siguiente paso es operarcon lo datos de forma fiable. Se incorpora entonces al aplicativo elproceso de liquidación. La liquidación de gastos es un procesocomplejo que requiere de cálculos concretos en las cuentasasociadas a la comunidad y a la de los saldos de los propietarios.Se resume como el proceso que distribuye el gasto de lacomunidad entre los diferentes propietarios. Esta distribución tienedos variantes según la modalidad en que los propietarios deseanpagar:

• Las liquidaciones de gasto vencido, en donde se repartepor propietarios el total del montante de gastospendientes por pagar. O,

• Las liquidaciones por presupuesto, en donde lospropietarios pagan un importe fijo (normalmentemensual) y se ajusta la diferencia entre lo presupuestadoy lo realmente gastado al final del período.

Al haber dos modalidades el proceso de liquidación se ubicó en elsegundo hito en donde está el grueso del trabajo en el aplicativo. El

Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013.

Aplicación SaaS para la Administración de Fincas • 3

proceso de liquidación, con sus dos modalidades, se identificaclaramente como el Factor Crítico de Éxito del proyecto.

La tercera y última de las fases, tiene como objetivo cerrar el ciclode vida de los datos que el sistema gestiona. En donde en primerlugar los Administradores de Fincas ingresan los datos necesarios,estos datos son operados y distribuidos entre las propiedades, ypara finalizar son presentados a los propietarios vía informes.Habitualmente en el sector los informes resultantes de lasliquidaciones se han presentado de forma impresa en listados ybalances a los propietarios mediante cartas físicas en correo postal.Dentro del alcance del proyecto se determinó que dichos datosdeberían estar siempre accesibles para los propietarios una vez quela liquidación se da por calculada, y que la consulta de lainformación sea actualizada al día, sin necesidad de solicitar denuevo una impresión o la realización de una junta de propietariospara la entrega de nuevos informes.

La motivación para mantener la información siempre online serefuerza con el hecho de que las juntas de vecinos requieren laconvocatoria de los propietarios en un determinado lugar y a unmismo tiempo, y materializar una reunión en una finca con decenasde propietarios supone un coste considerable. Ademáshistóricamente Mallorca ha sido un destino turístico de ciudadanostanto nacionales como internacionales, por lo que reducir en granmedida los desplazamientos geográficos que los propietarios debansufrir dota más peso al objetivo principal de favorecer el acceso ala información.

Con esta visión se abordó finalmente el desarrollo del proyecto enuna aventura personal sin saber muy bien cómo iban a responderlos usuarios ante una herramienta de estas características.

3. DESCRIPCIÓN DEL TRABAJO REALIZADO

La aplicación Arteco Radis se ha realizado íntegramente por elautor del documento en forma de una aplicación Web desarrolladaen Java [5]. Se han utilizado tecnologías modernas con librerías yframeworks de programación para su desarrollo.

El cómo se ha organizado la estructura lógica, qué componentes sehan utilizado, cuáles se han tenido que desarrollar y demásacciones relacionadas se explican a lo largo de este punto 3.

3.1 Definición del alcance

Dada las visión explicada en el punto 2, el siguiente paso es definirel alcance. Para ello se ha de determinar qué perfiles de usuario sonlos potenciales de la aplicación. Y sobre cada uno de los conjuntosde usuarios se ha de especificar qué procesos podrán ejecutar.

Por lo tanto los perfiles que tenemos en el aplicativo, pensando enque la aplicación estará abierta a Internet sin reducirse a losusuarios internos de la propia Administración de Fincas que dasustento a la iniciativa del proyecto, son los siguientes:

• Usuarios anónimos.• Usuarios administradores de fincas.• Usuarios propietarios.• Súper administrador.

Usuarios anónimos

Los usuarios anónimos son aquellos que acceden a la URLhttps://radis.artecoapps.com sin proporcionar ninguna credencial oidentificación.

Estos usuarios han de tener un rango de acciones muy limitado. Sípodrán consultar las páginas públicas informativas e iniciar elproceso de auto registro que les permitirá obtener el rol de usuarioadministrador de fincas, con el cual podrán dar de altacomunidades y generar las liquidaciones de estas.

Los contenidos públicos que los usuarios anónimos podránconsultar son:

• Información del sistema de gestión de comunidades:funcionalidades, tarifas, manual de usuario, políticas deprivacidad y de uso, enlaces de interés y datos decontacto.

• Acceso al blog con las últimas novedades yactualizaciones sobre el uso del programa.

• Acceso a las noticias relacionadas con la economíadoméstica y el sector de la administración de fincas.

• Búsqueda de inmuebles, con el catálogo de todos losinmuebles en venta y alquiler que hayan introducidotodos los administradores de fincas y marcados estoscomo visibles desde la parte pública.

• Iniciar el proceso de auto-registro.• Recuperar las credenciales de acceso, en caso de que el

usuario haya olvidado su clave para identificarse en elsistema.

El proceso de auto registro, es un procedimiento de 3 pasos que lesotorgará el rol de administrador de fincas en caso de que losusuarios anónimos cumplan correctamente con los formulariosrequeridos, en donde se le solicitan los datos personales y deacceso, información sobre la persona física y los datosrelacionados con la persona jurídica (en caso de que sea unprofesional del sector). En el último paso, se valida la cuenta decorreo electrónico que el usuario ha introducido. En casoafirmativo se da de alta el usuario con el rol de administrador defincas y el usuario puede a partir de entonces dar de alta lascomunidades, propietarios, personas, etc... que requiera para llevarlos gastos de la comunidad.

Al mismo tiempo se ha de ofrecer al usuario anónimo el proceso derecuperación de contraseña el cual le permitirá redefinir una nuevaclave después de validar su cuenta de correo.

Usuarios propietarios

Cuando un usuario administrador de fincas ingrese una propiedad,ha de tener la opción de asociar un propietario a dicho inmueble. Sise realiza el enlace, la persona gana automáticamente el rol depropietario, tuviera acceso o no previamente. Si ya lo tuviera elsistema ha de reutilizar el mismo usuario en base alemparejamiento de usuario y propietario según el email. Si no, sele ha de crear el usuario con ese dicho email y generarle una claveautomática que le será enviada a su buzón de correo electrónicopara notificarle la concesión del acceso. Por lo tanto un usuariopuede tener cualquier uno o los dos roles permitidos: propietario yadministrador de fincas.

Un propietario identificado en el sistema podrá acceder a todas lassecciones ofrecidas al usuario anónimo más a las accionesespecíficas para su propiedad o propiedades. Estas opciones son:

• Consulta de informes de los resultados de liquidaciones.• Consultas de las actas de reunión y orden del día.• Consulta de documentos ofrecidos por el administrador.• Notificar incidencias de la comunidad.

Usuarios administrador de fincas

El usuario principal de la aplicación es el administrador de fincas.Este rol ha de permitir a los usuarios gestionar el condominio


https://radis.artecoapps.com/


desde su creación hasta la presentación de recibos de lasliquidaciones de los gastos.

La mayor parte de la funcionalidad del aplicativo reside en estosusuarios y son los que determinarán si el desarrollo es adecuado ono a su necesidad diaria en la gestión, por lo tanto son designadoscomo el stakeholders de la iniciativa.

Principalmente las funcionalidades que los administradores puedenrealizar son aquellas que contempla el ciclo de vida unaliquidación y se resumen a continuación:

1. Crear las comunidades de vecinos en el sistema,indicando propiedades y propietarios.

2. Dar de alta los gastos que surjan en la comunidad,normalmente actividades de mantenimiento asociadas aproveedores.

3. Repartir el coste de las actividades de mantenimientoentre los diferentes propietarios.

4. Informar a los propietarios del coste a incurrir ygestionar el cobro de cada uno de ellos.

Súper-administrador.

El súper administrador, es el usuario de administración del sistemade información, con capacidad de realizar tareas de mantenimiento,conlleva acceso a los paneles de monitorización, y puede crear lascopias de seguridad, revisar datos maestros y controlar losprocesos de facturación mensual hacia los usuarios administradoresde fincas según su volumen de información gestionada.

El súper administrador es el único usuario que tiene acceso acualquier dato del sistema, con lo que puede ver cualquiercomunidad, cualquier movimiento económico o registro derivado,para asesorar o corregir situaciones en las que el usuario(administrador de fincas) no puede o no sabe continuar con elproceso pertinente, facilitando las tareas de ayuda y soporte que seofrece a los clientes de pago por uso.

3.2 Funcionamiento de negocio

Los usuarios definidos en el alcance serán los que intervendrán enla aplicación y podrán lanzar procesos que alterarán los datosalmacenados en el sistema de información. Prácticamente latotalidad de los procesos son iniciados interactivamente por losusuarios salvo uno: el proceso de facturación. Este último serálanzado con vencimiento mensual para contabilizar el consumo derecursos por parte de los usuarios en función del número depropiedades administradas en el aplicativo.

Obviando el proceso de facturación, el resto de procesos einteracciones puede interpretarse como que el administrador es elorigen de los datos y los demás usuarios son consumidores.

En resumen, los administradores se encargan de introducir yejecutar las acciones necesarias para llevar a cabo laadministración de la finca o fincas como usuarios activos, y losotros son sujetos pasivos en cuanto al sistema de información. Porejemplo, el proveedor recibirá las facturas pendientes de pago, ylos propietarios recibirá los informes de desglose de gastos, cuotas,obligaciones de pagos, juntas y demás.

El administrador puede ser al mismo tiempo uno de lospropietarios de la finca, en tal caso, deberá cumplir también con lasobligaciones de los propietarios en los procesos de gestión de lainformación, y por lo tanto será un sujeto pasivo porque recibirálos mismos informes que cualquier otro propietario que formeparte de la comunidad.

En definitiva el usuario clave es el administrador de fincas que seráque perfil que cubra una utilización estimada del 95% del tiempode uso del programa enfrente al escaso 5% de utilización imputableal consumo de recursos necesarios para ofrecer los informes en elportal del propietario.

Al ser el administrador un usuario clave es necesario que a la horade implementar los procesos de negocio se tenga siempre presentecomo máxima prioridad el punto de vista en cuanto número depasos, clicks, pantallas a navegar y datos a introducir que eladministrador de fincas deberá afrontar.

Siempre se ha de tener presente las limitaciones que una aplicaciónweb conlleva ante una aplicación típica de escritorio. Donde lainformación reside en el servidor y la página web muestra unainstantánea de la información perteneciente al momento en que elusuario solicitó dichos datos, que no tiene porqué estar tanactualizada como la contenida en el sistema gestor de bases dedatos.

Para reducir el impacto que será para el usuario el trabajar con unaaplicación web, el proyecto se apoya en tecnologías modernas queayudan a mitigar lo máximo posible las diferencias entreaplicaciones web y las de escritorio.

3.3 Marco tecnológico del desarrollo

El proyecto se ha desarrollado usando Java y diversas librerías decomponentes disponibles en la red [6]. La justificación del uso deesta plataforma tecnológica viene en las siguientes líneas:

Es el lenguaje de programación orientado a objetos más usado ymaduro en el entorno empresarial, la diferencia en el número deusuarios con otros lenguajes aumenta considerablemente enentornos Web. Como consecuencia del gran uso, cada vez es másfácil encontrar librerías para solventar problemas específicos oencontrar documentación y código fuente de referencia [7].

Dispone de una plataforma muy amplia de APIs y herramientaspara el desarrollo Web denominado JDK EE (Java DevelopmentKit Enterprise Edition) en el que abarcan Servicios Web, Ajax,persistencia de objetos, serialización, llamadas a procedimientosremotos a través de RMI, EJB, SOAP, WS, y demás. Tambiéndispone de otras librerías para el manejo de Xml, integración conotros lenguajes y motores de plantillas como las JSP parageneración dinámica de textos (normalmente Html), etc... [8]

Técnicamente es bastante eficiente consiguiendo tiempos deejecución comparables a C/C++ a pesar de ser código máquinainterpretado por una máquina virtual que ofrece una granportabilidad entre sistemas. Las nuevas versiones de la máquinavirtual incluyen optimizadores en tiempo de ejecución quecompilan el código en código máquina nativo y por lo tantoaumenta considerablemente su rendimiento. Y, al ser un lenguaje


Ilustración 1: Actores del sistema


orientado a objetos forma parte de la familia de lenguajes de altonivel y fácilmente extensible. Además queda garantizada lacontinuidad del producto desde que en diciembre del 2006 SunMicrosystems liberara el código fuente de la máquina virtual ycompilador bajo la licencia GPL v2 y posteriormente Oraclecompró a Sun siendo el mantenedor oficial de las nuevasrevisiones juntamente con la iniciativa Open Jdk y la asociaciónJava Community Process.

Dispone de los entornos integrados de desarrollo más avanzadosque existen, Eclipse, Intelli Idea y Netbeans, mantenidos por unaimportante comunidad de usuarios y desarrolladores en los quecontinuamente se evalúan e implementan mejoras para mantenerestos IDE. Éstos disponen de una sencilla interfaz para ampliar lasfuncionalidades, con un par de clics de ratón se pueden añadirnuevos módulos mediante la instalación de plugins desderepositorios en Internet.

Por último, al ser un lenguaje compilado y fuertemente tipado, eldesarrollador ayudado por el entorno de programación, obtendráuna productividad [9] mayor minimizando errores y aprovechandola posibilidad de automatizar algunas de las tareas repetitivas a lasque se ve sometido diariamente con el uso de scripts aceptados porel editor.

Con las ventajas citadas y sobre todo el gran abanico de librerías yframeworks disponibles sin coste de licencia e incluso open source[10 y 11], hace que la comunidad de usuarios sea muy elevada, ypor consiguiente una de las opciones más maduras del sector.

Las principales librerías en las que se basa el aplicativo tras ladecisión del marco tecnológico son unas ampliamente conocidas yespecializadas en ofrecer la lógica de presentación, la lógica denegocio y la lógica de persistencia. Por este orden son SpringFramework MVC juntamente con Java Server Pages. Spring IoCpara la lógica de negocio e Hibernate para la lógica depersistencia .

Spring Framework MVC

Spring MVC permite la separación conceptual y de diseño declases entre clases principales que simplifican el desarrollo ymantenimiento [12]. Al separar claramente las funcionalidades endiferentes entidades se desacopla la lógica necesaria en el procesode gestión de la información. Estas entidades son:

• M - Modelo, es el conjunto de clases Java que permitentrasladar la información de las pantallas a la base dedatos. Son clases que únicamente almacenaninformación y no tienen lógica dentro de ellas, seutilizan como mensajes y se denominan frecuentementePlain Old Java Object (POJO) puesto que todos susatributos son privados y sólo tienen métodos paraobtener dichos datos o para fijarles valor.

• V – Vista, corresponde con las clases JSP que seencargan de pintar la información que les llega a travésde las clases M. Se puede decir que únicamente pintan yno ejecutan ninguna lógica de negocio.

• C – Controlador, es el punto de entrada de una peticiónde usuario. Se encargan de llamar a la lógica de negocioque sea necesaria para obtener todos los objetos M quela vista va a necesitar para pintar la pantalla, queposteriormente le será mostrada al usuario.

Una nota importante a tener en cuenta es que la lógica de negociono ha de estar directamente dentro del controlador. El controladorla invoca, pero esta ha alojarse en unidades funcionalesindependientes puesto que la lógica de negocio suele ser usada porvarios controladores. Es recomendable que sea un componente

compartido entre varios controladores, o incluso entre diferentesaplicaciones.

Spring Framework IoC

Spring IoC nos permite encapsular la lógica de negocio encomponentes reutilizables y compartidos por los controladores[13]. También se encarga de resolver las dependencias que puedahaber entre unas unidades funcionales y otras que implementan lalógica de negocio, de manera que si un controlar necesita uncomponente, Spring IoC se encarga de inicializar todos lossubcomponentes por debajo, para que el controlador únicamentehaga referencia al componente que ha de utilizar.

Hibernate

Hibernate es un conjunto de librerías que simplificanconsiderablemente el mapeo de tablas y registros de base de datosen objetos Java [14]. Su funcionamiento es estableciendorelaciones entre objetos y clases entre tablas y registros de la formaen que cada tabla de base de datos corresponde con una clase, ycada objeto de una de estas clases corresponde con un registro. Demanera que se puede solicitar a Hibernate que guarde un registrocon una simple llamada 'guardar objeto x' sin necesidad de escribirni una sola línea de SQL. Hibernate se encarga de generar elcomando SQL apropiado como insert, select, update o delete.

Tecnologías en el lado del cliente

Las tres librerías anteriores se ejecutan dentro del servidor deaplicaciones. Son librerías muy potentes y ampliamente usadas,pero no abarcan todo el ciclo de una aplicación. Con ellas se puedegenerar todo el HTML necesario para interactuar con lainformación, pero no son suficiente para ofrecer un agradableexperiencia al usuario. Para mejorar la usabilidad y la apariencia esrecomendable dotar de interactividad a los elementos HTML que elusuario verá en su navegador, como mensajes emergentes,animaciones, validaciones y otros efectos gráficos que le ayuden aenfrentarse intuitivamente a la aplicación [15].

Para dotar dinamismo a los elementos en pantalla se ha utilizadoJavascript en el lado del navegador conjuntamente con una libreríamuy utilizada en el sector jQuery, que proporciona un ampliocatálogo de sencillas funcionalidades que los programadorespueden usar cómodamente como esconder o mostrar objetos,desplazarlos por la pantalla, cambiar el color, etc.

En cuanto al estilismo se han utilizado diversas fuentes de hojas deestilo CSS que ofrecen estilos predefinidos agradables a losusuarios con bonitos colores, espacios y fuentes. Una de las hojasmás importantes del aplicativo es el denominado Twitter Bootstrapque ofrece un abanico de botones, alertas, tablas, campos paraformularios, etc. con una linea base común y adaptado para poderser visto desde navegadores web dentro de estaciones de escritorioo en dispositivos móviles.

Todas las librerías anteriores son Open Source y puedenencontrarse fácilmente en Internet. También pueden serdistribuidas y utilizadas en aplicaciones sin coste alguno para eldesarrollador. Éstas están mantenidas por una gran comunidad deusuarios y se las consideran lo suficientemente maduras y establesen el sector como para poder ser usada sin riesgos de seguridad ofiabilidad. El uso de todas ellas es muy recomendable puesto quealivia en gran medida el trabajo del desarrollador y es posibleconstruir sofisticadas aplicaciones web sobre sus servicios. Almismo tiempo en las comunidades de usuarios y desarrolladorespuede encontrarse componentes gráficos muy ricos para laexperiencia del usuario que se construyen por encima de dichaslibrerías y que también pueden reutilizarse.



3.4 Diseño del aplicativo

Basándose en los principios presentados de Modelo - Vista –Controlador [9], el aplicativo está compuesto a base decomponentes con responsabilidades concretas que interaccionanentre ellos.

Muchos componentes son (re)utilizados por otros [2], de forma queel funcionamiento de ellos debe ser preciso y determinista, por loque las modificaciones han de evaluarse previamente paraasegurarse de que el resto de componentes que le llaman no severán afectados.

Arquitectura lógica

La división del aplicativo en componentes es esencial paraverificar el funcionamiento del código escrito mediante testunitarios y para la re-utilización de código.

Los componentes principales pueden clasificarse según su tipo deresponsabilidad al que ofrecen lógica [16]:

• Diálogo con el usuario dependiente de la presentación:Controladores.

• Lógica de negocio: Servicios.• Capa de persistencia: DAOs (Data Access Object).• Mensajes de entrada y salida de los Servicios y DAOs

conformando la capa de Modelo: POJOs (Plain OldJava Objects)

• Vistas que generan el Html dinámico, JSPs.

El proceso aplicable en la práctica totalidad de las funcionalidadessigue el siguiente flujo:

1. El navegador del cliente hará una petición Http quellegará al punto de entrada de la aplicación: elcontrolador. La capa de abstracción de SpringFramework MVC se encargará de varios servicios comodecodificar los parámetros del URL, gestión de losThreads, inicializar los subcomponentes necesarios yotras funcionalidades de seguridad. El controlador,distingue qué tipo de petición es, normalmente por elpath de la URL. Por ejemplo una URL posible sería“idApplicación/personas/nueva”. Descomponiendo laURL tenemos que “/personas” sirve para localizar elcontrolador. Y “/nueva” para localizar la acción(método) del controlador a ejecutar. El método sabe cuales su propósito, así que accede a los componentes deServicio (donde está la lógica de incluir una persona)indicándole que ha de añadir una nueva persona en elsistema: por ejemplo: PersonasSerice. addPersona(nuevaPersona). Siendo nuevaPersona una instancia dePersona con los atributos rellenados según losparámetros que puedan venir en la petición Http.

2. El Servicio realizará las comprobaciones necesarias,como validar el NIF, verificar que tiene un nombre y almenos primer apellido, que el NIF no existapreviamente, etc.. Una vez realizadas todas lasvalidaciones llamará al DAO correspondiente para quela persona sea registrada.

3. El DAO recibe la nueva persona validada por elServicio, para que traduzca el objeto nuevaPersona aldialecto que el sistema de persistencia reconoce, en estecaso SQL, y haga efectivos los cambios a nivel de tablascolumnas.

4. El resultado de la conversión a SQL es almacenado en labase de datos.

5. Después de la inserción es devuelto un ACK al DAOpara ofrecerle un feedback de que la operación ha sidocorrecta.

6. El ACK se transmite al Servicio.7. El servicio contiene lógica de si la operación ha ido

correctamente o no. Puede ocurrir que deba echar atráslos cambios mediante la ejecución del rollback de latransacción si hubiera ocurrido algún error, si nopropagará el ACK al Controlador.

8. El controlador decide qué pantalla (JSP) mostrar alusuario según el resultado de la operativa. En el caso delejemplo mostrará un mensaje de inserción correcta alusuario pasando el control a un JSP denominadoinsercionCorrecta.jsp

9. El servidor Web resuelve el JSP generando HTMLdinámicamente que será devuelto al navegador delusuario que realizó la petición Http, cerrando el ciclo deuna operativa dentro del aplicativo.

Arquitectura de sistemas

El sistema ha de estar preparado para ser desplegado sobre lasinfraestructuras PaaS como las que proporciona un proveedorCloud semejante a Amazon Elastic Cloud Computing [17].

Los sistemas Cloud se caracterizan porque todo el hardware visiblepor el cliente es virtual simulando tener máquinas dedicadas consistema operativo, acceso a disco y memoria RAM como tendríacualquier servidor físico. La ventaja de ser virtual es que se puedencrear recursos adicionales si la carga del sistema lo requiere oliberar algunos de ellos si la utilización es baja. De ahí que tambiénse le denominen sistemas elásticos. El proveedor va contabilizandolos recursos utilizados según el período (normalmente mensual) yemite una factura al finalizar el período de facturación conteniendola suma del coste de los recursos utilizados.

A nivel de aplicación, un sistema elástico determina que lasinstancias se pueden crear o destruir en cualquier momento y elconjunto total de funcionalidades no debe verse afectado cara a lapercepción del usuario.


Ilustración 2: Componentes principales del aplicativo

Ilustración 3: Arquitectura Cloud


Que una instancia pueda ser creada o destruida afecta a laaplicación en varios motivos. Uno de ellos es que no se puedealmacenar información en el servidor (web) puesto que sepresupone que tarde o temprano esa instancia desaparecerá.También el número que identifica a la sesión de un usuario ha deser único para todo el grupo de servidores. Y otro punto es que lascachés que se utilicen debe estar preparadas para trabajar encluster, puesto que habrá presumiblemente más de una instancia dela aplicación en marcha. Por lo que el sistema deberá de añadir losnuevos nodos al cluster o quitarlos si el recurso virtual es liberado.

Los proveedores incluyen en sus servicios un balanceador quedistribuye por igual la carga de transacciones Http entre todos losnodos activos, por lo que la utilización es distribuidauniformemente entre todo el hardware virtual.

3.5 Implementación

Spring es un framework para el desarrollo de aplicaciones ycontenedor de inversión de control, de código abierto para laplataforma Java que se adapta perfectamente a este tipo dedespliegues. Si bien las características fundamentales de SpringFramework pueden ser usadas en cualquier aplicación desarrolladaen Java, existen diferentes extensiones para la construcción deaplicaciones web sobre la plataforma Java EE y orientados alCloud. Con características específicas para alta disponibilidad eintercambio de datos entre máquinas distribuidas. Se considera unaalternativa o sustituto al modelo tradicional de aplicaciones Javacon EJB. Hay que tener presente que entre sus ventajas destaca laidentificación de funcionalidades fácilmente reutilizables,aplicando la máxima de "divide, reutilizarás y vencerás".

Spring ha de verse como un gestor de componentes [18], un poolde objetos que presuponemos que están inicializados a la hora deser usados dentro de nuestra aplicación. Si un componente requierelos servicios de otro, Spring lo detectará e inicializará el subcomponente antes que el llamante, aplicando los principios de laInyección de Dependencias.

Extensión Spring para Modelo-Vista-Controlador

La extensión Web para Modelo-Vista-Controlador está diseñado entorno a un DispatcherServlet que envía solicitudes a la lógicaresponsable, con capa de seguridad, resolución de la vista,validación de parámetros, la configuración regional y la resoluciónel tema visual, así como soporte para cargar archivos.

Los controladores son objetos java anotados con @Controler y@RequestMapping, que ofrecen una amplia gama y flexible demétodos de configuración.

El módulo web de Spring incluye muchas características únicas desoporte Web :

• Clara separación de responsabilidades. Cada rol -controlador, validador, objeto de comando, objeto deformulario, modelo de objetos, asignación decontrolador, resolución de la vista, etc son resueltos porobjetos particulares.

• Configuración potente y directa por implementacionesofrecidas por el framework o implementaciones propiasde la aplicación.

• Lógica de negocio reutilizable, sin necesidad de laduplicación de código fuente.

• Validaciones personalizables que sirven de formageneral o especificar validaciones concretas paradeterminadas peticiones Http.

• Flexibilidad a la hora de definir el modelo y por lo tantolas clases que servirán como mensajes para transmitir lainformación entre componentes.

• Localización de mensajes multi idioma y resolución deltema visual personalizable por criterios de segmentaciónde los clientes web.

• Incluye una biblioteca de etiquetas JSP con soporte parafunciones como el enlace de datos y temas, formulariose inputs.

• También ofrece la gestión del ciclo de vida de loscomponentes, puesto que estos pueden ser "singletons" oque vida esté asociada al ámbito de la petición Http,sesión del usuario o contexto de aplicación.

Implementación de la aplicación - Controladores

El aplicativo se construye sobre la capa de servicios que ofreceSpring MVC, de manera que se han de definir controladores, elconjunto de clases que conformará modelo persistente contra labase de datos MySQL, a través de Hibernate, y se agrupa la lógicade negocio dentro de los beans gestionados por Spring IoC a travésde la definición de Services.

@Controllerpublic class HelloWorldController {

@Autowired HelloService service

@RequestMapping("/helloWorld") public String helloWorld(Model model) {

Object result = service.doSomeBusinessLogic(); model.addAttribute("message", result); return "selectedViewName"; }}

Tabla 1: Estructura general de un Controlador

En la construcción del aplicativo se han definido los controladoressegún la configuración Java y con anotaciones tal y como muestrael ejemplo de la Tabla 1: Estructura general de un Controlador,donde puede verse lo sencillo que es definir un controlador deSpring, asociarlo a una ruta URL mediante la anotación@RequestMapping. Al mismo tiempo queda reflejado cómodeclarar una inyección de un componente, que en este caso es unservicio con lógica de negocio dentro del controlador para atendera una petición Http. El resultado de la ejecución de la lógica sepuede hacer llegar a la vista mediante la inclusión de este objeto


Ilustración 4: Arquitectura lógica de Spring MVC


dentro del objeto Model que se recibe como parámetro del método,parámetro que también se encarga Spring de dotarle de valor.

La lógica de negocio se ejecuta dentro de una misma transacciónde base de datos, con lo que si ocurriera alguna excepción en suejecución no se procedería a la realización del commit SQL. Springgestiona el ciclo de vida de la transacción y se asegura de crear oofrecer una transacción existente a los beans gestionados dentro deuna misma petición Http. Al finalizar la petición, si no ha ocurridoninguna situación no esperada se ejecutará el finalizado correcto deuna transacción y los cambios serán efectivos en base de datos paralas sucesivas operaciones.

El esquema general de un controlador no difiere demasiado en todoel conjunto de controladores disponibles en la aplicación. Pero sípuede verse un segundo esquema muy utilizado aplicado cuando serequiere validación de datos introducidos por el usuario siguiendola estructura de la Tabla 2: Estructura de Controlador convalidación de datos.

@Controllerpublic class HelloWorldController {

@RequestMapping("/helloWorld") public String helloWorld( @ModelAttribute("person") Person person, BindingResult result) {

if (result.hasErrors()) { return "formViewName"; } // ... return "okViewName"; }}

Tabla 2: Estructura de Controlador con validación de datos

Para la validación de los datos de usuario también se usa la capa deservicio de validación y mapeos de datos de Spring. En donde losdatos son convertidos de String (tal y como vienen en el request) aotros tipos como Long, Date, Boolean, Integer, etc... según unasreglas de conversión predefinidas. Aunque como siempre en Springesas reglas pueden sobrescribirse. Esto permite mapear los datos derequest en un objeto de tipo Person como aparece en el ejemplo.

Implementación de la aplicación - Modelo

Los controladores, y el resto de la aplicación intercambiaránobjetos Java (POJOS) como mensajes que contienen los datos quela aplicación gestiona. En el caso que abarca, el modelo contienedatos que han de ser duraderos en el tiempo y con reglas deintegridad relacional que se han de satisfacer. Para ello se usaHibernate como mecanismo de persistencia de estos objetos.

@Entity@Table(name="tbl_person”, uniqueConstraints= { @UniqueConstraint( columnNames={"nif"})})public class Person implements Serializable { @Id @GeneratedValue( strategy=GenerationType.SEQUENCE, generator="seq_person_id") private Long id;}

Tabla 3: Definición tipo de modelo persistente

Véase en la Tabla 3: Definición tipo de modelo persistente cómo sedefine un objeto persistente mediante Hibernate.

Existen otras anotaciones adicionales de Hibernate con las cualespodemos parametrizar el cómo será almacenada la información a laque hace ámbito. Normalmente la mayoría de anotaciones vanaplicadas a nivel de atributo y vienen definidas según el estándarJava Persistence Api (JPA-2). Es Hibernate la implementación dereferencia de dicho estándar, que es de obligado cumplimiento delos servidores de aplicaciones J2EE 5.0 y posteriores [19].

Las anotaciones más importantes son las que se refieren a lasrelaciones entre objetos que definirán la integridad relacional yconsistencia a nivel de base de datos:

• javax.persistence.ManyToMany• javax.persistence.ManyToOne• javax.persistence.OneToMany• javax.persistence.OneToOne

El modelo de la aplicación va acompañado con anotacionesadicionales a las definidas en JPA-2 que ayudan a la validación delos objetos del modelo antes de ser utilizados en la lógica denegocio. Estas anotaciones para validación de datos vienendefinidas en el JSR-303 y la implementación de referencia esHibernate Validator.

Spring MVC reconoce dichas anotaciones y las usará como reglasque se han de cumplir a la hora de mapear los parámetros quellegan del request, dejando las restricciones no satisfechas dentrode BindingResult, en donde la aplicación puede consultar si lasvalidaciones han ido bien o no y actuar en consecuencia. Ejemplosde restricciones disponibles para usar en el modelo:

• javax.validation.constraints.NotNull• javax.validation.constraints.Size• javax.validation.constraints.Pattern• javax.validation.constraints.Email

Dichas anotaciones introducen las dependencias de Hibernate yBean Validations dentro del modelo [14], con lo que si queremosdistribuir el modelo a otras aplicaciones, éstas deberán incluirtambién las dos librerías para poder compilar correctamente elproyecto. Esto es una situación no deseable, pero lasfuncionalidades que aportan son suficientemente significativascomo para aceptar dicha limitación. Al mismo tiempo no hayprevistas integraciones tan fuertes mediante el modelo con otrasaplicaciones, pero sí a futuro interconexiones con él medianteservicios web que requerirán definir un modelo público específicocomo subconjunto del modelo interno del proyecto, en dónde sóloaparezca información no sensible y que pueda ser distribuido haciafuera del sistema.

Implementación de la aplicación – Vista

Dados el modelo y los controladores que determinan el flujo denavegación del usuario por diferentes diálogos, las vistas son elúltimo paso en la resolución de las peticiones Http y para ello elcontrolador deberá alojar en el objeto Model todos los objetos delmodelo que contienen información a representar por la vista, porejemplo Person. En el proyecto que se abarca las vistas son JSPque generan HTML dinámicamente.

Los JSP pueden ejecutar pequeñas sentencias lógicas, comocondicionales o bucles para elaborar tablas o listas dentro de unapágina web. Estos códigos lógicos y cómo imprimir atributos delmodelo se invocan mediante librerías de etiquetas Tags. Javaproporciona un surtido suficiente de Tags agrupados en doslibrerías - Standar Tags y JST - que aceptan expresiones sencillaspara mantener la lógica muy limitada en los JSP y que los grandescálculos se realicen en los componentes de servicio de la lógica denegocio. A parte Spring Tags proporciona otro conjunto de Tags



para definir formularios acorde a como la validación yrecuperación de los datos que se hará en el controlador.

<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>

<form:form modelAttribute=”person”> <table> <tr> <td>First Name:</td> <td><form:input path="firstName" /></td> </tr> <tr> <td>Last Name:</td> <td><form:input path="lastName" /></td> <td><form:error path="lastName" /></td> </tr> …</form:form>

Tabla 4: Formularios usando Tags JSP

Los formularios de la aplicación siguen la estructura de la Tabla 4:Formularios usando Tags JSP, en donde puede verse que los Tagsde Spring se encargan de crear el HTML asociado para los camposInput Texts con el valor proveniente del modelo, mostrando o nomensajes de error si no han cumplido las validaciones indicadas enlas anotaciones del modelo.

Implementación de la aplicación – Servicio

Los componentes con el código fuente correspondiente a la lógicade negocio se agrupan en servicios en forma de Beans gestionadospor Spring IoC para la inyección de dependencias, principalmenteen los controladores que los usen. Generalmente, los controladoresrecogerán la acción de negocio a ejecutar con sus parámetros ydelegarán la operación en los servicios, los cuales se encargarán deejecutar la operación dentro de un contexto transaccional. Véasetabla Tabla 5: Estructura de un Servicio.

@Service@Transactionalpublic class PersonServiceImpl implements PersonService {

@Autowired PersonDAO personDao;

Person getPersonById(Long id){ … }

void savePerson(Person p){ // ... personDao.save(p); } ….. }

Tabla 5: Estructura de un Servicio

Con la ayuda de la anotación transaccional se consigue que todoslos métodos públicos estén encapsulados en al menos unatransacción SQL. Puesto que unos métodos de un servicio puedenllamar a otros métodos del mismo servicio, Spring sólo creará unatransacción salvo que se indique lo contrario.

Si se desea puede configurarse que cada método tenga unatransacción diferente o si queremos que la misma transacción sepropague a los métodos internos de la llamada. Este parámetro yotros más se pueden configurar añadiendo la anotacióntransaccional en el método en vez de la clase.

A su vez, la anotación permite otras configuraciones como: elmodo de aislamiento, si será o no sólo lectura, tiempo máximo deespera, etc…

Para completar la descripción de los servicios resta decir que enellos se ejecutan las validaciones correspondientes a la lógica denegocio, como rangos de fechas o períodos de facturación.Posteriormente se realizan los cálculos correspondientes y losresultados se transmiten a los DAOs para que estos haganpermanentes los cambios en la base de datos.

Implementación de la aplicación – Persistencia

En el último eslabón de la cadena de elementos de la aplicación,está el objeto responsable de almacenar los objetos del modelo enbase de datos. Descontando la capa ofrecida por Hibernate [14],estos últimos elementos se les denomina DAOs y su objetivo esaislar el sistema de persistencia usado a la capa de lógica denegocio para desacoplarla. De esta manera sería posible cambiar desistema de persistencia aprovechando la lógica de negocio.

Los DAOs a su vez son también Beans gestionados por SpringIoC, y mantienen la transacción SQL que el servicio lesproporcionó. Spring tiene funcionalidades específicas paraHibernate por lo que se encarga de hacer llegar la transacción alpunto de entrada de los DAO, que es mediante la sesión deHibernate a través del SessionFactory.

@Repositorypublic class PersonDAOImpl implements PersonDAO {

@Autowired private SessionFactory sessionFactory; public void savePerson(Person p){ // … Session session = factory.currentSession(); session.save(p); }}

Tabla 6: Estructura de un DAO

La Tabla 6: Estructura de un DAO resume esquemáticamente elformato que tendrá cualquier DAO implementado que se alojan enel aplicativo.

3.6 Despliegue y evaluación del lanzamiento

El aplicativo se despliega sobre sistemas virtualizados dentro de lanube, donde se pone a disposición un número de instanciasdependientes de la carga de trabajo. En concreto se ha utilizadoAmazon Elastic Cloud Computing para desplegar el conjunto deelementos necesarios. Hay dos tipos de instancias, una de ellasdestinadas a alojar la base de datos MySQL denominado instanciade base de datos, mientras que hay otras destinadas a procesar lalógica de la aplicación dentro de servidores Apache Tomcat,instancias web.

Las instancias son máquinas virtuales que se comportan como lasreales y contienen un sistema operativo basado en linuxcorrespondientes a una distribución específica para servidoresvirtualizados de Amazon. Los dos tipos de instancias se diferencianentre ellas por el software que contienen, así que cada una de ellastendrá el software instalado que se necesite: unas para el gestor debase de datos y las otras para arrancar un servidor web.



Aunque las dos instancias se basen en la misma distribución linux,las dos contienen configuraciones diferentes, por lo que hay quecrear imágenes preconfiguradas a partir de la distribución. Unaimagen (o AMI en términos de Amazon) corresponde a unaconfiguración pre-establecida y congelada de una distribución consistema operativo y el software necesario para el fin de la instancia.Como tenemos dos tipos de instancia, una contendrá la base dedatos y la configuración de MySQL y la otra el servidor deaplicaciones Java Apache Tomcat y la configuración de éste.

Se puede configurar el comportamiento de cada una de lasmáquinas virtuales. Cada proveedor determina los parámetros quepueden ajustarse, como capacidad de la CPU, cantidad de memoriaRAM, disco duro volátil o no, etc… y el coste por uso vendrádeterminado por estos parámetros.

Para este proyecto, la instancia web es una instancia volátil, noalmacena nada en el disco duro de la máquina virtual, pero en elscript de arranque se ha configurado unos pasos para que acceda alrepositorio del código fuente del aplicativo, construya la aplicacióncompilándola y empaquetándola en un fichero desplegable por elservidor de aplicaciones Web Tomcat.

La otra instancia de base de datos es diferente a la Web respecto aque es una instancia no volátil, lo que escriba en el disco duro sí hade ser durable en el tiempo, así que se le configura una unidad dered (al estilo NFS) donde será almacenado el contenido de lastablas de MySQL. Además, sólo una de las instancias de este tipopuede ser el maestro, dejando las demás como esclavas. Estoquiere decir que las escrituras sólo deben realizarse sobre lamáquina maestro, y las demás replicar las operaciones en localdespués de que el maestro haya confirmado dichas operaciones.

Así que la creación y destrucción de instancias tipo base de datosno es tan trivial como en el lado web, en este caso se requiere queel nombre de las máquinas se mantenga entre instancias porqueserá utilizado por los diferentes drivers Jdbc y un script adicionalque active a uno y sólo uno de los nodos de base datos comomáster, mediante la sentencia de SQL CHANGE MASTER [20].

Según la arquitectura en cloud descrita, las peticiones web entranen los sistemas de Amazon mediante un balanceador que distribuyedicha petición hacia los servidores Web virtuales. Puede verse unresumen del número de peticiones en la Ilustración 5: Resumen desesiones Http para una instancia Web. Cada uno de los servidoresWeb delega la petición en la aplicación desarrollada. De ahí a lalógica de negocio y posteriormente a la base de datos a través delos DAOs.

4. RESULTADOS

Una vez puesto en producción, el sistema se mantiene activo deforma estable aceptando peticiones Http de los diferentesnavegadores web de los clientes.

Los usuarios administradores de fincas pueden registrarselibremente sobre el sistema desde la página principal (Ilustración 6:Página principal del proyecto) y realizar pruebas gratuitas siutilizan pocos recursos, o pagando de forma mensual si el númerode propiedades administradas supera la decena. En cuanto elusuario ha validado su correo electrónico, automáticamente se leshabilita las funciones para crear las propiedades y propietarios delas diversas comunidades que deseen gestionar.

Al la finalización del proyecto las funcionalidades descritas porcada uno de los perfiles de usuario están accesible desde un puntoúnico y compartido, en donde los usuarios pueden accedersimultáneamente a los resultados de las liquidaciones y a los saldosde sus movimientos en tiempo real.

El feedback proporcionado por los administradores de fincas esbastante satisfactorio, marcando un nivel de implantaciónaceptable a pesar del esfuerzo que requiere a estos la migración detodos los datos entre su posible sistema anterior y el nuevo.

Por otro lado, los propietarios han declarado en diversas ocasionesmediante entrevistas personales, que la información a la que tienenacceso vía online (Ilustración 7: Vista parcial del Portal delPropietario) representa su fuente de información principal y másfiable, recurriendo únicamente a los listados impresos cuando no sedispone de una conexión a internet, marcando como exitoso uno delos objetivos principales del aplicativo.

Actualmente el sistema se encuentra en producción después de unproceso que ha durado cerca de 3 años desde su creación, con más


Ilustración 5: Resumen de sesiones Http para una instancia Web

Ilustración 6: Página principal del proyecto

Ilustración 7: Vista parcial del Portal del Propietario


de 500 visitas únicas semanales. En un total de 20.000 páginasservidas por semana y distribuidas entre 54 comunidadesadministradas. Se puede encontrar en las primeras páginas deresultados de Google en búsquedas con las palabras clave“Software Administración Fincas” y “Administración FincasOnline”.

5. CONCLUSIÓN

Se han satisfecho los objetivos marcados. Se ha diseñado ydesarrollado un sistema de administradores de fincas para usuariosdomésticos y profesionales denominado Arteco Radis, adaptado alentorno Cloud, disponible en producción para cualquier usuarioque desee administrar el control contable de su comunidad ocomunidades de vecinos.

Arteco Radis cumple todos los requisitos de usuario tanto a nivelfuncional como a nivel técnico. Por un lado permite la realizacióncorrecta y consistente de las operaciones requeridas por el perfil deusuario y por otro lado cumple con las normas de accesibilidad,seguridad y usabilidad que marca el consorcio W3C, garantizandoque el aplicativo se ejecutará correctamente en la mayoría denavegadores Web disponibles.

La elaboración del portal ha implicado el estudio y elaboración dediferentes tareas:

1. Definir las infraestructuras necesarias para lasoperativas. En donde se han citado aquellos elementosque forman parte de las comunicaciones y sistemasadaptadas a un entorno Cloud.

2. Se ha realizado un análisis y elección de las alternativastecnológicas. Para reducir riesgos minimizandoesfuerzos en la elaboración se han estudiado lasprincipales tecnologías más importantes del panoramaWeb, escogiendo la plataforma Java como el productomás maduro y con la mayor comunidad de usuarios detodos los disponibles.

3. Se ha evaluado la elección del proveedor del entornoCloud. Siguiendo las pautas las pruebas realizadas sobresistemas de carga, despliegue y servicios adicionales deseguridad para la contención y backups.

4. Descripción de los estándares de compatibilidad Web.Para llegar al máximo número de usuariosindependientemente del navegador que se use o deldispositivo de visualización, ya sea un dispositivo móvilo fijo, se han incluido los principales estándares HTML,ECMAScript y WCAI en la generación del código devisualización.

5. Análisis y definición de los mensajes de entrada ysalida de cada proceso de negocio. Una vez definida latecnología y los elementos de información a gestionar,se han establecido los procesos y actividades paraabordar el desarrollo por fases con hitos alcanzablesinvolucrando al usuario desde el primer momento.

6. Definición de la arquitectura física y lógica delaplicativo. Dados los elementos que se han deinterconectar en este punto se han establecido unidadesfuncionales tanto físicas (hardware virtual) como lógicas(software) para la división y simplificación de cada unade las tareas a realizar en los módulos descritos.

7. Separación de la capa de negocio y de presentación.En la fase de diseño de software se ha separado el

código fuente en función del modelo de programaciónModelo Vista Controlador que facilita la división eindependencia de cada una de las capas a implementar.

8. Selección de las herramientas para la construcción.Para dar cuerpo a los módulos definidos se han escogidoherramientas de programación con inserción de códigoautomático, gestores de versiones y softwarecolaborativo para todo el equipo de desarrollo quefacilitan el trabajo en grupo y la colaboración.

9. Definición del entorno de desarrollo y metodología deprogramación. Establecidas la tecnología deprogramación y las herramientas de construcción se hanescrito las pautas del desarrollo para conseguir uncódigo homogéneo, mantenible y fácil de probar antesde pasar a producción.

10. Definición de la metodología de pruebas y pase aproducción. El pase a producción es un procesocomplejo ya que debe mantenerse el servicio siempredisponible sin que el usuario note ninguna interrupción,por lo que en este punto se establecieron losprocedimientos de pase a producción y control delcódigo fuente.

11. Definición e implementación de cada uno de losmódulos del aplicativo que dan soporte alfuncionamiento completo. Por último y para cadamódulo funcional se han descrito las características yparticularidades para la construcción de cada uno deellos dejando explicaciones de las solucionesincorporadas para cada problemática aparecida.

Estos 11 puntos resumen todo el conjunto de actividades que hansido necesarias realizar para poner en marcha la aplicación,partiendo únicamente del conocimiento de negocio que transmitidoa personal formado en nuevas tecnologías, ha sido capaz dereescribir los procesos de gestión diarios adaptándolos a un entornoCloud y de alta disponibilidad en forma de una aplicación rentabley disponible al gran público.

5.1 Mejoras

Arteco Radis no es un producto cerrado, es un primer paso quesirve para continuar el desarrollo de nuevos servicios y operativasa los administradores de fincas destinados a crear un sistema depago por uso de calidad, que permita mejorar la gestión interna yadministrativa de cada usuario con y para su comunidad.

También puede especializarse o añadir código adicional paramejorar la adaptación de las nuevas generaciones de dispositivosmóviles, integraciones con otras plataformas existentes para laadministración de comunidades e incluso con aplicacionescontables para la importación y exportación de datos.

La aparición de tecnologías que mejoran la visualización y lainteracción de los usuarios con las interfaces gráficas son unobjetivo a tener presente cara al futuro, tecnologías como JavaFX,Silverligth y Flex o el hermano mayor de todas ellas HTML5pueden mejorar en un alto grado todos los conceptos de análisistécnico y toma de decisiones con cuadros de mando integrados quecentralicen toda la información que cualquier administrador opropietario pueda necesitar.



Un portal Web debe ser un servicio que evoluciona con el tiempoadaptándose continuamente a las nuevas tecnologías y requisitosde los usuarios que exigen un alto compromiso por las entidadesque las soportan, sobre todo cuando la información que gestionaeste tipo de portales es tan importante como el capital económicode las personas.

REFERÈNCIAS

[1] Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Autor: Craig Larman (Hardcover - 2004).

[2] Design Patterns: Elements of Reusable Object-Oriented Software (Hardcover)

[3] Information Architecture for the World Wide Web: Designing Large-Scale Web Sites. Autores: Peter Morville y Louis Rosenfeld (Paperback – 2006)

[4] Information Architecture: Blueprints for the Web. Autores: Christina Wodtke y Austin Govella (Paperback,2006)

[5] Web Application Architecture: Principles, Protocols and Practices. Autor: Leon Shklar y Rich Rosen (Paperback, 2007)

[6] Java Web Services Architecture (The Morgan Kaufmann Series in Data Management Systems). Autores: James McGovern, Sameer Tyagi, Michael Stevens, y Sunil Mathew (Paperback, 2003)

[7] Expert One-on-One Programmer). J2EE Design and Development (Programmer to Autor: Rod Johnson (Paperback, 2002)

[8] Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition). Autores: Deepak Alur, Dan Malks, and John Crupi (Hardcover, 2003)

[9] Designing Enterprise Applications with the J2EE(TM) Platform (2nd Edition). Autores: Inderjeet Singh, Beth Stearns, Mark Johnson, and Enterprise Team The (Paperback, 2002)

[10] J2EE: The complete Reference. Autor: James Keogh (Paperback, 2002)

[11] J2EE Web Services: XML SOAP WSDL UDDI WS-I JAX-RPC JAXR SAAJ JAXP. Autor: Richard Monson-Haefel (Paperback, 2003)

[12] Spring MVC Referencehttp://docs.spring.io/spring/docs/3.0.x/reference/mvc.html

[13] Spring IOC Reference http://docs.spring.io/spring/docs/3.0.x/reference/beans.html

[14] Hibernate 3.x. Mapping Java SQL http://hibernate.org/

[15] Comunidad OWASP para la seguridad de aplicaciones.http://www.owasp.com

[16] Escalona, Maria José., Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta. http://www.lsi.us.es/docs/informes/EstadoActual.pdf.

[17] Amazon Elastic Compute Cloud http://aws.amazon.com/es/ec2/

[18] Comunidad Java Open Source para el desarrollo de componentes reutilizables http://jakarta.apache.org/.

[19] Oracle Java Doc Site J2EE http://docs.oracle.com/javaee/6/tutorial/doc/

[20] MySQL Documentation: MySQL Reference Manualshttp://dev.mysql.com/doc/


http://docs.oracle.com/javaee/6/tutorial/doc/

http://aws.amazon.com/es/ec2/

Arteco Radis - Trabajo Proyecto fin de Máster

Technology

Transcript of Arteco Radis - Trabajo Proyecto fin de Máster