AplicaciónSaaS parala
AdministracióndeFincas
RamónArnauGómez
Miquel MascaróPortells
UniversidaddelasIslasBaleares
Este doc...
2 • Ramón Arnau Gómez
Contenido
Este proyecto resume las tareas realizadas en la elaboración de un
producto desde la etapa...
AplicaciónSaaSparala AdministracióndeFincas • 3
proceso de liquidación, con sus dos modalidades, se identifica
claramente ...
4 • Ramón Arnau Gómez
desde su creación hasta la presentación de recibos de las
liquidaciones de los gastos.
La mayor part...
AplicaciónSaaSparala AdministracióndeFincas • 5
orientado a objetos forma parte de la familia de lenguajes de alto
nivel y...
6 • Ramón Arnau Gómez
3.4 Diseñodel aplicativo
Basándose en los principios presentados de Modelo - Vista –
Controlador [9]...
AplicaciónSaaSparala AdministracióndeFincas • 7
Que una instancia pueda ser creada o destruida afecta a la
aplicación en v...
8 • Ramón Arnau Gómez
dentro del objeto Model que se recibe como parámetro del método,
parámetro que también se encarga Sp...
AplicaciónSaaSparala AdministracióndeFincas • 9
para definir formularios acorde a como la validación y
recuperación de los...
10 • Ramón Arnau Gómez
Aunque las dos instancias se basen en la misma distribución linux,
las dos contienen configuracione...
AplicaciónSaaSparala AdministracióndeFincas • 11
de 500 visitas únicas semanales. En un total de 20.000 páginas
servidas p...
12 • Ramón Arnau Gómez
Un portal Web debe ser un servicio que evoluciona con el tiempo
adaptándose continuamente a las nue...
Próxima SlideShare
Cargando en…5
×

Arteco Radis - Trabajo Proyecto fin de Máster

905 visualizaciones

Publicado el

Trabajo de fin de Máster en Tecnologías de la Información para la Universidad de las Islas Baleares sobre el desarrollo de una aplicación web para la gestión de comunidades de vecinos, liquidaciones, gastos y saldos de propietarios

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
905
En SlideShare
0
De insertados
0
Número de insertados
392
Acciones
Compartido
0
Descargas
4
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Arteco Radis - Trabajo Proyecto fin de Máster

  1. 1. AplicaciónSaaS parala AdministracióndeFincas RamónArnauGómez Miquel MascaróPortells UniversidaddelasIslasBaleares Este documento corresponde a la memoria de las tareas realizadas sobre de desarrollo de un aplicativo accesible desde Internet, en la modalidad Software como Servicio, como trabajo de final de Máster de Tecnologías de la Información de la Universidad de las Islas Baleares. Dicho aplicativo tiene como objetivo desarrollar un modelo de negocio basado en el pago por uso de un aplicativo destinado a la gestión online de comunidades de vecinos, que permita controlar y distribuir el gasto originado por el mantenimiento y mejora de las fincas comunitarias o condominios. Este trabajo pondrá de manifiesto las acciones realizadas en las fases de análisis, diseño, implementación y despliegue en producción de un aplicativo que está abierto a Internet para cualquier usuario. Se describirán las medidas tecnológicas necesarias para que la información sea consistente, segura y fiable, mientras se mantiene la privacidad requerida por el tratamiento de datos personales en un sistema multi-usuario. Palabras clave: Aplicación SaaS, Alta disponibilidad, Multi-usuario. © 2013 Universitat de les Illes Balears Mà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 en la Nube, ha abierto la puerta a nuevos modelos de negocio basados en el alquiler de recursos y pago por uso. De la tradicional venta de software empaquetado en CD o DVD con una determinada licencia de uso, se ha pasado a un modelo de negocio en donde el software está accesible por el usuario a través de Internet, dispuesto en los recursos propios de fabricante o vendedor. Es el vendedor quien se hace responsable de la disponibilidad de las funcionalidades y la custodia de la información. Este nuevo modelo de negocio alojado en la nube ha permitido que empresas con pocos recursos dispusieran de una infraestructura donde ofrecer servicio al público general en sistemas abiertos en Internet en muy corto espacio de tiempo. Donde el coste que soporta el fabricante o proveedor de software es proporcional al volumen o tamaño del sistema que gestiona. Ante este nuevo marco tecnológico aparecen una multitud de aplicaciones apoyadas en infraestructuras Cloud con la idea de cubrir necesidades y sacar al mercado nuevos servicios rápidamente en un ciclo corto de innovación y mejora continua. En este entorno aparece la aplicación de este trabajo, Arteco Radis, en modalidad SaaS (Software as a Service, Software como Servicio) o llamado de forma llana pago por uso. Arteco Radis: una innovadora plataforma de gestión de comunidades de vecinos o condominios, 100% online. Donde los propietarios o administradores de fincas pueden gestionar los gastos de la comunidad derivados del mantenimiento y rehabilitación. Los usuarios pueden distribuir los gastos de manera muy flexible para adaptarse a los acuerdos plasmados en los estatutos comunitarios con el sistema general de distribución por coeficientes por propiedad. Es un sistema accesible por Internet desde cualquier conexión a internet, computadora personal o dispositivo móvil que disponga de un navegador web compatible con los estándares de la World Wide Web Consortium (W3C). https://radis.artecoapps.com Actualmente el sistema se encuentra en producción después de un proceso que ha durado cerca de 3 años desde su inicio, con más de 500 visitas únicas semanales. En un total de 20.000 páginas servidas por semana y distribuidas entre 54 comunidades administradas. Se puede encontrar en las primeras páginas de resultados de Google en búsquedas con las palabras clave “Software Administración Fincas” y “Administración Fincas Online”. Objetivo Informado al lector sobre el entorno y el objeto de la memoria, la finalidad del trabajo realizado es demostrar cómo se puede consolidar un proyecto de iniciativa personal con una inversión económica reducida, usando las Tecnologías de la Información y herramientas innovadoras y la programación orientada a objetos [1] para solventar una necesidad existente. Llevado a cabo con una inversión mucho menor que la que puede darse en otros sectores empresariales que típicamente conllevan barreras de entrada con costes muy superiores. Se describirá a lo largo del documento los puntos que han hecho posible la puesta en marcha de Arteco Radis en donde se han realizados las siguientes tareas principales: • Se ha definido los procedimientos y requisitos funcionales que ha de cubrir el aplicativo para el marco de trabajo de los Administradores de fincas. • Escrito los requisitos adicionales derivados de un sistema multi-usuario y multi-empresa [2]. • Creado un plan con mecanismos de seguridad e integridad para asegurar el control del flujo de información y los accesos no autorizados. Y, • Elaborado procedimientos de despliegue en entornos Cloud y de alta disponibilidad. Con adaptación flexible a la carga de trabajo [3]. Máster Universitario en Tecnologías de la Información, Universidad de les Islas Baleares, 2013.
  2. 2. 2 • Ramón Arnau Gómez Contenido Este proyecto resume las tareas realizadas en la elaboración de un producto desde la etapa de diseño hasta el despliegue en producción de una herramienta de software, ejecutándose en un entorno tecnológico flexible como ofrece el Cloud Computing. Se nombrarán los principales puntos de interés en cada una de las etapas de la producción. Este documento no pretende ser una guía completa del proceso, si no una memoria que refleje los problemas encontrados y las soluciones adoptadas en la puesta en marcha del Sistema de Información, desde el punto de vista de la formación adquirida en el Máster de Tecnologías de la Información. Para completar los objetivos del proyecto se siguieron los procesos genéricos de desarrollo de aplicaciones Web [4], sobre los cuales se han incorporado adaptaciones específicas por el ámbito y alcance del 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 de programación, framework de programación web, y servidor de aplicaciones. • Implementación de las funcionalidades. Consideraciones de rendimiento y seguridad aplicadas en la metodología de desarrollo. • Y, despliegue en el proveedor Cloud Amazon Web Services Elastic Cloud Computing. 2. NACIMIENTODELAIDEA A través de circunstancias personales, en 2009 apareció la posibilidad de formar parte en una empresa con mucha historia en el sector de administradores de fincas, con más de 30 años de experiencia. Gracias a esa participación, se adquirieron los conocimientos necesarios de los métodos y de los procesos que rigen el día a día de los Administradores de Fincas. Además con la aparición del modelo de negocio pago por uso, rápidamente creciente, se dio lugar a la posibilidad de crear una plataforma que renovara los procesos internos de la administradora de fincas como parte de su evolución interna y mejora respecto a la competencia como elemento diferenciador. Uno de los principales puntos fuertes de las aplicaciones de pago por uso en herramientas de gestión dando el salto a Internet y trasladando los datos a la nube, es que se dispone de un aplicativo que prácticamente está siempre Online, con información actualizada y consistente en tiempo real y con un coste de mantenimiento mínimo. Los usuarios se vuelven más productivos ya que hay menos fuentes de problemas o incidentes que pueden aparecer derivados del mantenimiento de los equipos informáticos de sobre mesa. En el sector de la administración de fincas, tradicionalmente las aplicaciones de gestión usadas han sido aplicaciones de escritorio con poca o ninguna integración cliente/servidor y con altos costes en licencias por uso o por instalación, cuya falta de actualización ha obligado en muchos casos a mantener equipos informáticos obsoletos en funcionamiento. Aprovechando el mercado emergente y considerando las limitaciones de las aplicaciones de escritorio, se consolidaba la idea de desarrollar una plataforma propia. Al mismo tiempo se dio la posibilidad de realizar una inversión adicional en esfuerzo para que otras Administraciones de Fincas también pudieran usar esta nueva herramienta. Generalizando el alcance a un mercado más global y abriendo la puerta incluso a cualquier posible usuario del territorio nacional o internacional. Por lo tanto, uno de los primeros pasos era determinar el alcance del aplicativo en donde quedaran reflejadas las funcionalidades necesarias para que cualquier Administrador de Fincas del ámbito nacional pudiera ver útil el aplicativo. Y determinar así, si el alcance del proyecto era asumible por la dirección dados los recursos disponibles tanto financieros como humanos. Para facilitar la puesta en marcha de la iniciativa, se determinaron 3 fases o hitos que permitirían realizar un análisis detallado marcando objetivos más concretos y que permita validar la correcta implementación de los requisitos funcionales y la continuidad del proyecto 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 al funcionamiento de inserción de datos protegidos por la LOPD y apuntes contables de forma segura en un entorno Web, donde los usuarios internos de la Administración de Fincas pudieran experimentar en la gestión de la información contenida, en forma de altas, bajas de propietarios, propiedades, grupos de distribución y demás conceptos que formarían la base del proceso de liquidación. En este punto, el usuario interno debía validar el método de introducción de datos dentro de un grupo de trabajo con varios gestores de comunidades. Pasar de un entorno mono puesto, a una aplicación online. La aceptación del cambio desde un entorno de trabajo con software local a un entorno distribuido y disperso geográficamente serviría como apoyo para la realización del proyecto, 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 el cambio de plataforma de gestión. Una vez superada la gestión del cambio, el siguiente paso es operar con lo datos de forma fiable. Se incorpora entonces al aplicativo el proceso de liquidación. La liquidación de gastos es un proceso complejo que requiere de cálculos concretos en las cuentas asociadas a la comunidad y a la de los saldos de los propietarios. Se resume como el proceso que distribuye el gasto de la comunidad entre los diferentes propietarios. Esta distribución tiene dos variantes según la modalidad en que los propietarios desean pagar: • Las liquidaciones de gasto vencido, en donde se reparte por propietarios el total del montante de gastos pendientes por pagar. O, • Las liquidaciones por presupuesto, en donde los propietarios pagan un importe fijo (normalmente mensual) y se ajusta la diferencia entre lo presupuestado y lo realmente gastado al final del período. Al haber dos modalidades el proceso de liquidación se ubicó en el segundo 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.
  3. 3. AplicaciónSaaSparala AdministracióndeFincas • 3 proceso de liquidación, con sus dos modalidades, se identifica claramente como el Factor Crítico de Éxito del proyecto. La tercera y última de las fases, tiene como objetivo cerrar el ciclo de vida de los datos que el sistema gestiona. En donde en primer lugar los Administradores de Fincas ingresan los datos necesarios, estos datos son operados y distribuidos entre las propiedades, y para finalizar son presentados a los propietarios vía informes. Habitualmente en el sector los informes resultantes de las liquidaciones se han presentado de forma impresa en listados y balances a los propietarios mediante cartas físicas en correo postal. Dentro del alcance del proyecto se determinó que dichos datos deberían estar siempre accesibles para los propietarios una vez que la liquidación se da por calculada, y que la consulta de la información sea actualizada al día, sin necesidad de solicitar de nuevo una impresión o la realización de una junta de propietarios para la entrega de nuevos informes. La motivación para mantener la información siempre online se refuerza con el hecho de que las juntas de vecinos requieren la convocatoria de los propietarios en un determinado lugar y a un mismo tiempo, y materializar una reunión en una finca con decenas de propietarios supone un coste considerable. Además históricamente Mallorca ha sido un destino turístico de ciudadanos tanto nacionales como internacionales, por lo que reducir en gran medida los desplazamientos geográficos que los propietarios deban sufrir dota más peso al objetivo principal de favorecer el acceso a la información. Con esta visión se abordó finalmente el desarrollo del proyecto en una aventura personal sin saber muy bien cómo iban a responder los usuarios ante una herramienta de estas características. 3. DESCRIPCIÓNDELTRABAJOREALIZADO La aplicación Arteco Radis se ha realizado íntegramente por el autor del documento en forma de una aplicación Web desarrollada en Java [5]. Se han utilizado tecnologías modernas con librerías y frameworks de programación para su desarrollo. El cómo se ha organizado la estructura lógica, qué componentes se han utilizado, cuáles se han tenido que desarrollar y demás acciones relacionadas se explican a lo largo de este punto 3. 3.1 Definicióndel alcance Dada las visión explicada en el punto 2, el siguiente paso es definir el alcance. Para ello se ha de determinar qué perfiles de usuario son los potenciales de la aplicación. Y sobre cada uno de los conjuntos de usuarios se ha de especificar qué procesos podrán ejecutar. Por lo tanto los perfiles que tenemos en el aplicativo, pensando en que la aplicación estará abierta a Internet sin reducirse a los usuarios internos de la propia Administración de Fincas que da sustento a la iniciativa del proyecto, son los siguientes: • Usuarios anónimos. • Usuarios administradores de fincas. • Usuarios propietarios. • Súper administrador. Usuariosanónimos Los usuarios anónimos son aquellos que acceden a la URL https://radis.artecoapps.com sin proporcionar ninguna credencial o identificación. Estos usuarios han de tener un rango de acciones muy limitado. Sí podrán consultar las páginas públicas informativas e iniciar el proceso de auto registro que les permitirá obtener el rol de usuario administrador de fincas, con el cual podrán dar de alta comunidades y generar las liquidaciones de estas. Los contenidos públicos que los usuarios anónimos podrán consultar son: • Información del sistema de gestión de comunidades: funcionalidades, tarifas, manual de usuario, políticas de privacidad y de uso, enlaces de interés y datos de contacto. • Acceso al blog con las últimas novedades y actualizaciones sobre el uso del programa. • Acceso a las noticias relacionadas con la economía doméstica y el sector de la administración de fincas. • Búsqueda de inmuebles, con el catálogo de todos los inmuebles en venta y alquiler que hayan introducido todos los administradores de fincas y marcados estos como 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 el sistema. El proceso de auto registro, es un procedimiento de 3 pasos que les otorgará el rol de administrador de fincas en caso de que los usuarios anónimos cumplan correctamente con los formularios requeridos, en donde se le solicitan los datos personales y de acceso, información sobre la persona física y los datos relacionados con la persona jurídica (en caso de que sea un profesional del sector). En el último paso, se valida la cuenta de correo electrónico que el usuario ha introducido. En caso afirmativo se da de alta el usuario con el rol de administrador de fincas y el usuario puede a partir de entonces dar de alta las comunidades, propietarios, personas, etc... que requiera para llevar los gastos de la comunidad. Al mismo tiempo se ha de ofrecer al usuario anónimo el proceso de recuperación de contraseña el cual le permitirá redefinir una nueva clave después de validar su cuenta de correo. Usuariospropietarios Cuando un usuario administrador de fincas ingrese una propiedad, ha de tener la opción de asociar un propietario a dicho inmueble. Si se realiza el enlace, la persona gana automáticamente el rol de propietario, tuviera acceso o no previamente. Si ya lo tuviera el sistema ha de reutilizar el mismo usuario en base al emparejamiento de usuario y propietario según el email. Si no, se le ha de crear el usuario con ese dicho email y generarle una clave automática que le será enviada a su buzón de correo electrónico para notificarle la concesión del acceso. Por lo tanto un usuario puede tener cualquier uno o los dos roles permitidos: propietario y administrador de fincas. Un propietario identificado en el sistema podrá acceder a todas las secciones ofrecidas al usuario anónimo más a las acciones especí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. Usuariosadministradordefincas El usuario principal de la aplicación es el administrador de fincas. Este rol ha de permitir a los usuarios gestionar el condominio Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013.
  4. 4. 4 • Ramón Arnau Gómez desde su creación hasta la presentación de recibos de las liquidaciones de los gastos. La mayor parte de la funcionalidad del aplicativo reside en estos usuarios y son los que determinarán si el desarrollo es adecuado o no a su necesidad diaria en la gestión, por lo tanto son designados como el stakeholders de la iniciativa. Principalmente las funcionalidades que los administradores pueden realizar son aquellas que contempla el ciclo de vida una liquidació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 a proveedores. 3. Repartir el coste de las actividades de mantenimiento entre los diferentes propietarios. 4. Informar a los propietarios del coste a incurrir y gestionar el cobro de cada uno de ellos. Súper-administrador. El súper administrador, es el usuario de administración del sistema de información, con capacidad de realizar tareas de mantenimiento, conlleva acceso a los paneles de monitorización, y puede crear las copias de seguridad, revisar datos maestros y controlar los procesos de facturación mensual hacia los usuarios administradores de fincas según su volumen de información gestionada. El súper administrador es el único usuario que tiene acceso a cualquier dato del sistema, con lo que puede ver cualquier comunidad, 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 el proceso pertinente, facilitando las tareas de ayuda y soporte que se ofrece a los clientes de pago por uso. 3.2 Funcionamientodenegocio Los usuarios definidos en el alcance serán los que intervendrán en la aplicación y podrán lanzar procesos que alterarán los datos almacenados en el sistema de información. Prácticamente la totalidad de los procesos son iniciados interactivamente por los usuarios salvo uno: el proceso de facturación. Este último será lanzado con vencimiento mensual para contabilizar el consumo de recursos por parte de los usuarios en función del número de propiedades administradas en el aplicativo. Obviando el proceso de facturación, el resto de procesos e interacciones puede interpretarse como que el administrador es el origen de los datos y los demás usuarios son consumidores. En resumen, los administradores se encargan de introducir y ejecutar las acciones necesarias para llevar a cabo la administración de la finca o fincas como usuarios activos, y los otros son sujetos pasivos en cuanto al sistema de información. Por ejemplo, el proveedor recibirá las facturas pendientes de pago, y los 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 los propietarios de la finca, en tal caso, deberá cumplir también con las obligaciones de los propietarios en los procesos de gestión de la información, y por lo tanto será un sujeto pasivo porque recibirá los mismos informes que cualquier otro propietario que forme parte 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 tiempo de uso del programa enfrente al escaso 5% de utilización imputable al consumo de recursos necesarios para ofrecer los informes en el portal del propietario. Al ser el administrador un usuario clave es necesario que a la hora de implementar los procesos de negocio se tenga siempre presente como máxima prioridad el punto de vista en cuanto número de pasos, clicks, pantallas a navegar y datos a introducir que el administrador de fincas deberá afrontar. Siempre se ha de tener presente las limitaciones que una aplicación web conlleva ante una aplicación típica de escritorio. Donde la información reside en el servidor y la página web muestra una instantánea de la información perteneciente al momento en que el usuario solicitó dichos datos, que no tiene porqué estar tan actualizada como la contenida en el sistema gestor de bases de datos. Para reducir el impacto que será para el usuario el trabajar con una aplicación web, el proyecto se apoya en tecnologías modernas que ayudan a mitigar lo máximo posible las diferencias entre aplicaciones web y las de escritorio. 3.3 Marcotecnológicodel desarrollo El proyecto se ha desarrollado usando Java y diversas librerías de componentes disponibles en la red [6]. La justificación del uso de esta plataforma tecnológica viene en las siguientes líneas: Es el lenguaje de programación orientado a objetos más usado y maduro en el entorno empresarial, la diferencia en el número de usuarios con otros lenguajes aumenta considerablemente en entornos Web. Como consecuencia del gran uso, cada vez es más fácil encontrar librerías para solventar problemas específicos o encontrar documentación y código fuente de referencia [7]. Dispone de una plataforma muy amplia de APIs y herramientas para el desarrollo Web denominado JDK EE (Java Development Kit Enterprise Edition) en el que abarcan Servicios Web, Ajax, persistencia de objetos, serialización, llamadas a procedimientos remotos a través de RMI, EJB, SOAP, WS, y demás. También dispone de otras librerías para el manejo de Xml, integración con otros lenguajes y motores de plantillas como las JSP para generación dinámica de textos (normalmente Html), etc... [8] Técnicamente es bastante eficiente consiguiendo tiempos de ejecución comparables a C/C++ a pesar de ser código máquina interpretado por una máquina virtual que ofrece una gran portabilidad entre sistemas. Las nuevas versiones de la máquina virtual incluyen optimizadores en tiempo de ejecución que compilan el código en código máquina nativo y por lo tanto aumenta considerablemente su rendimiento. Y, al ser un lenguaje Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013. Ilustración 1: Actores del sistema
  5. 5. AplicaciónSaaSparala AdministracióndeFincas • 5 orientado a objetos forma parte de la familia de lenguajes de alto nivel y fácilmente extensible. Además queda garantizada la continuidad del producto desde que en diciembre del 2006 Sun Microsystems liberara el código fuente de la máquina virtual y compilador bajo la licencia GPL v2 y posteriormente Oracle compró a Sun siendo el mantenedor oficial de las nuevas revisiones juntamente con la iniciativa Open Jdk y la asociación Java Community Process. Dispone de los entornos integrados de desarrollo más avanzados que existen, Eclipse, Intelli Idea y Netbeans, mantenidos por una importante comunidad de usuarios y desarrolladores en los que continuamente se evalúan e implementan mejoras para mantener estos IDE. Éstos disponen de una sencilla interfaz para ampliar las funcionalidades, con un par de clics de ratón se pueden añadir nuevos módulos mediante la instalación de plugins desde repositorios en Internet. Por último, al ser un lenguaje compilado y fuertemente tipado, el desarrollador ayudado por el entorno de programación, obtendrá una productividad [9] mayor minimizando errores y aprovechando la posibilidad de automatizar algunas de las tareas repetitivas a las que se ve sometido diariamente con el uso de scripts aceptados por el editor. Con las ventajas citadas y sobre todo el gran abanico de librerías y frameworks disponibles sin coste de licencia e incluso open source [10 y 11], hace que la comunidad de usuarios sea muy elevada, y por consiguiente una de las opciones más maduras del sector. Las principales librerías en las que se basa el aplicativo tras la decisión del marco tecnológico son unas ampliamente conocidas y especializadas en ofrecer la lógica de presentación, la lógica de negocio y la lógica de persistencia. Por este orden son Spring Framework MVC juntamente con Java Server Pages. Spring IoC para la lógica de negocio e Hibernate para la lógica de persistencia . Spring Framework MVC Spring MVC permite la separación conceptual y de diseño de clases entre clases principales que simplifican el desarrollo y mantenimiento [12]. Al separar claramente las funcionalidades en diferentes entidades se desacopla la lógica necesaria en el proceso de gestión de la información. Estas entidades son: • M - Modelo, es el conjunto de clases Java que permiten trasladar la información de las pantallas a la base de datos. Son clases que únicamente almacenan información y no tienen lógica dentro de ellas, se utilizan como mensajes y se denominan frecuentemente Plain Old Java Object (POJO) puesto que todos sus atributos son privados y sólo tienen métodos para obtener dichos datos o para fijarles valor. • V – Vista, corresponde con las clases JSP que se encargan de pintar la información que les llega a través de las clases M. Se puede decir que únicamente pintan y no ejecutan ninguna lógica de negocio. • C – Controlador, es el punto de entrada de una petición de usuario. Se encargan de llamar a la lógica de negocio que sea necesaria para obtener todos los objetos M que la vista va a necesitar para pintar la pantalla, que posteriormente le será mostrada al usuario. Una nota importante a tener en cuenta es que la lógica de negocio no ha de estar directamente dentro del controlador. El controlador la invoca, pero esta ha alojarse en unidades funcionales independientes puesto que la lógica de negocio suele ser usada por varios controladores. Es recomendable que sea un componente compartido entre varios controladores, o incluso entre diferentes aplicaciones. Spring Framework IoC Spring IoC nos permite encapsular la lógica de negocio en componentes reutilizables y compartidos por los controladores [13]. También se encarga de resolver las dependencias que pueda haber entre unas unidades funcionales y otras que implementan la lógica de negocio, de manera que si un controlar necesita un componente, Spring IoC se encarga de inicializar todos los subcomponentes por debajo, para que el controlador únicamente haga referencia al componente que ha de utilizar. Hibernate Hibernate es un conjunto de librerías que simplifican considerablemente el mapeo de tablas y registros de base de datos en objetos Java [14]. Su funcionamiento es estableciendo relaciones entre objetos y clases entre tablas y registros de la forma en que cada tabla de base de datos corresponde con una clase, y cada objeto de una de estas clases corresponde con un registro. De manera que se puede solicitar a Hibernate que guarde un registro con una simple llamada 'guardar objeto x' sin necesidad de escribir ni una sola línea de SQL. Hibernate se encarga de generar el comando 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 de aplicaciones. Son librerías muy potentes y ampliamente usadas, pero no abarcan todo el ciclo de una aplicación. Con ellas se puede generar todo el HTML necesario para interactuar con la información, pero no son suficiente para ofrecer un agradable experiencia al usuario. Para mejorar la usabilidad y la apariencia es recomendable dotar de interactividad a los elementos HTML que el usuario verá en su navegador, como mensajes emergentes, animaciones, validaciones y otros efectos gráficos que le ayuden a enfrentarse intuitivamente a la aplicación [15]. Para dotar dinamismo a los elementos en pantalla se ha utilizado Javascript en el lado del navegador conjuntamente con una librería muy utilizada en el sector jQuery, que proporciona un amplio catálogo de sencillas funcionalidades que los programadores pueden 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 de estilo CSS que ofrecen estilos predefinidos agradables a los usuarios con bonitos colores, espacios y fuentes. Una de las hojas más importantes del aplicativo es el denominado Twitter Bootstrap que ofrece un abanico de botones, alertas, tablas, campos para formularios, etc. con una linea base común y adaptado para poder ser visto desde navegadores web dentro de estaciones de escritorio o en dispositivos móviles. Todas las librerías anteriores son Open Source y pueden encontrarse fácilmente en Internet. También pueden ser distribuidas y utilizadas en aplicaciones sin coste alguno para el desarrollador. Éstas están mantenidas por una gran comunidad de usuarios y se las consideran lo suficientemente maduras y estables en el sector como para poder ser usada sin riesgos de seguridad o fiabilidad. El uso de todas ellas es muy recomendable puesto que alivia en gran medida el trabajo del desarrollador y es posible construir sofisticadas aplicaciones web sobre sus servicios. Al mismo tiempo en las comunidades de usuarios y desarrolladores puede encontrarse componentes gráficos muy ricos para la experiencia del usuario que se construyen por encima de dichas librerías y que también pueden reutilizarse. Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013.
  6. 6. 6 • Ramón Arnau Gómez 3.4 Diseñodel aplicativo Basándose en los principios presentados de Modelo - Vista – Controlador [9], el aplicativo está compuesto a base de componentes con responsabilidades concretas que interaccionan entre ellos. Muchos componentes son (re)utilizados por otros [2], de forma que el funcionamiento de ellos debe ser preciso y determinista, por lo que las modificaciones han de evaluarse previamente para asegurarse de que el resto de componentes que le llaman no se verán afectados. Arquitecturalógica La división del aplicativo en componentes es esencial para verificar el funcionamiento del código escrito mediante test unitarios y para la re-utilización de código. Los componentes principales pueden clasificarse según su tipo de responsabilidad 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 Old Java Objects) • Vistas que generan el Html dinámico, JSPs. El proceso aplicable en la práctica totalidad de las funcionalidades sigue el siguiente flujo: 1. El navegador del cliente hará una petición Http que llegará al punto de entrada de la aplicación: el controlador. La capa de abstracción de Spring Framework MVC se encargará de varios servicios como decodificar los parámetros del URL, gestión de los Threads, inicializar los subcomponentes necesarios y otras funcionalidades de seguridad. El controlador, distingue qué tipo de petición es, normalmente por el path de la URL. Por ejemplo una URL posible sería “idApplicación/personas/nueva”. Descomponiendo la URL tenemos que “/personas” sirve para localizar el controlador. Y “/nueva” para localizar la acción (método) del controlador a ejecutar. El método sabe cual es su propósito, así que accede a los componentes de Servicio (donde está la lógica de incluir una persona) indicándole que ha de añadir una nueva persona en el sistema: por ejemplo: PersonasSerice. addPersona (nuevaPersona). Siendo nuevaPersona una instancia de Persona con los atributos rellenados según los pará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 al menos primer apellido, que el NIF no exista previamente, etc.. Una vez realizadas todas las validaciones llamará al DAO correspondiente para que la persona sea registrada. 3. El DAO recibe la nueva persona validada por el Servicio, para que traduzca el objeto nuevaPersona al dialecto que el sistema de persistencia reconoce, en este caso SQL, y haga efectivos los cambios a nivel de tablas columnas. 4. El resultado de la conversión a SQL es almacenado en la base de datos. 5. Después de la inserción es devuelto un ACK al DAO para ofrecerle un feedback de que la operación ha sido correcta. 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ás los cambios mediante la ejecución del rollback de la transacción si hubiera ocurrido algún error, si no propagará el ACK al Controlador. 8. El controlador decide qué pantalla (JSP) mostrar al usuario según el resultado de la operativa. En el caso del ejemplo mostrará un mensaje de inserción correcta al usuario pasando el control a un JSP denominado insercionCorrecta.jsp 9. El servidor Web resuelve el JSP generando HTML dinámicamente que será devuelto al navegador del usuario que realizó la petición Http, cerrando el ciclo de una operativa dentro del aplicativo. Arquitecturadesistemas El sistema ha de estar preparado para ser desplegado sobre las infraestructuras PaaS como las que proporciona un proveedor Cloud semejante a Amazon Elastic Cloud Computing [17]. Los sistemas Cloud se caracterizan porque todo el hardware visible por el cliente es virtual simulando tener máquinas dedicadas con sistema operativo, acceso a disco y memoria RAM como tendría cualquier servidor físico. La ventaja de ser virtual es que se pueden crear recursos adicionales si la carga del sistema lo requiere o liberar algunos de ellos si la utilización es baja. De ahí que también se le denominen sistemas elásticos. El proveedor va contabilizando los recursos utilizados según el período (normalmente mensual) y emite una factura al finalizar el período de facturación conteniendo la suma del coste de los recursos utilizados. A nivel de aplicación, un sistema elástico determina que las instancias se pueden crear o destruir en cualquier momento y el conjunto total de funcionalidades no debe verse afectado cara a la percepción del usuario. Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013. Ilustración 2: Componentes principales del aplicativo Ilustración 3: Arquitectura Cloud
  7. 7. AplicaciónSaaSparala AdministracióndeFincas • 7 Que una instancia pueda ser creada o destruida afecta a la aplicación en varios motivos. Uno de ellos es que no se puede almacenar información en el servidor (web) puesto que se presupone que tarde o temprano esa instancia desaparecerá. También el número que identifica a la sesión de un usuario ha de ser único para todo el grupo de servidores. Y otro punto es que las cachés que se utilicen debe estar preparadas para trabajar en cluster, puesto que habrá presumiblemente más de una instancia de la aplicación en marcha. Por lo que el sistema deberá de añadir los nuevos nodos al cluster o quitarlos si el recurso virtual es liberado. Los proveedores incluyen en sus servicios un balanceador que distribuye por igual la carga de transacciones Http entre todos los nodos activos, por lo que la utilización es distribuida uniformemente entre todo el hardware virtual. 3.5 Implementación Spring es un framework para el desarrollo de aplicaciones y contenedor de inversión de control, de código abierto para la plataforma Java que se adapta perfectamente a este tipo de despliegues. Si bien las características fundamentales de Spring Framework pueden ser usadas en cualquier aplicación desarrollada en Java, existen diferentes extensiones para la construcción de aplicaciones web sobre la plataforma Java EE y orientados al Cloud. Con características específicas para alta disponibilidad e intercambio de datos entre máquinas distribuidas. Se considera una alternativa o sustituto al modelo tradicional de aplicaciones Java con EJB. Hay que tener presente que entre sus ventajas destaca la identificació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 pool de objetos que presuponemos que están inicializados a la hora de ser usados dentro de nuestra aplicación. Si un componente requiere los servicios de otro, Spring lo detectará e inicializará el sub componente antes que el llamante, aplicando los principios de la Inyección de Dependencias. ExtensiónSpringparaModelo-Vista-Controlador La extensión Web para Modelo-Vista-Controlador está diseñado en torno a un DispatcherServlet que envía solicitudes a la lógica responsable, con capa de seguridad, resolución de la vista, validación de parámetros, la configuración regional y la resolución el 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 de métodos de configuración. El módulo web de Spring incluye muchas características únicas de soporte Web : • Clara separación de responsabilidades. Cada rol - controlador, validador, objeto de comando, objeto de formulario, modelo de objetos, asignación de controlador, resolución de la vista, etc son resueltos por objetos particulares. • Configuración potente y directa por implementaciones ofrecidas por el framework o implementaciones propias de la aplicación. • Lógica de negocio reutilizable, sin necesidad de la duplicación de código fuente. • Validaciones personalizables que sirven de forma general o especificar validaciones concretas para determinadas peticiones Http. • Flexibilidad a la hora de definir el modelo y por lo tanto las clases que servirán como mensajes para transmitir la información entre componentes. • Localización de mensajes multi idioma y resolución del tema visual personalizable por criterios de segmentación de los clientes web. • Incluye una biblioteca de etiquetas JSP con soporte para funciones como el enlace de datos y temas, formularios e inputs. • También ofrece la gestión del ciclo de vida de los componentes, puesto que estos pueden ser "singletons" o que vida esté asociada al ámbito de la petición Http, sesión del usuario o contexto de aplicación. Implementacióndela aplicación- Controladores El aplicativo se construye sobre la capa de servicios que ofrece Spring MVC, de manera que se han de definir controladores, el conjunto de clases que conformará modelo persistente contra la base de datos MySQL, a través de Hibernate, y se agrupa la lógica de negocio dentro de los beans gestionados por Spring IoC a través de la definición de Services. @Controller public 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 controladores según la configuración Java y con anotaciones tal y como muestra el ejemplo de la Tabla 1: Estructura general de un Controlador, donde puede verse lo sencillo que es definir un controlador de Spring, asociarlo a una ruta URL mediante la anotación @RequestMapping. Al mismo tiempo queda reflejado cómo declarar una inyección de un componente, que en este caso es un servicio con lógica de negocio dentro del controlador para atender a una petición Http. El resultado de la ejecución de la lógica se puede hacer llegar a la vista mediante la inclusión de este objeto Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013. Ilustración 4: Arquitectura lógica de Spring MVC
  8. 8. 8 • Ramón Arnau Gómez 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ón de base de datos, con lo que si ocurriera alguna excepción en su ejecución no se procedería a la realización del commit SQL. Spring gestiona el ciclo de vida de la transacción y se asegura de crear o ofrecer una transacción existente a los beans gestionados dentro de una misma petición Http. Al finalizar la petición, si no ha ocurrido ninguna situación no esperada se ejecutará el finalizado correcto de una transacción y los cambios serán efectivos en base de datos para las sucesivas operaciones. El esquema general de un controlador no difiere demasiado en todo el conjunto de controladores disponibles en la aplicación. Pero sí puede verse un segundo esquema muy utilizado aplicado cuando se requiere validación de datos introducidos por el usuario siguiendo la estructura de la Tabla 2: Estructura de Controlador con validación de datos. @Controller public 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 de servicio de validación y mapeos de datos de Spring. En donde los datos son convertidos de String (tal y como vienen en el request) a otros tipos como Long, Date, Boolean, Integer, etc... según unas reglas de conversión predefinidas. Aunque como siempre en Spring esas reglas pueden sobrescribirse. Esto permite mapear los datos de request en un objeto de tipo Person como aparece en el ejemplo. Implementacióndelaaplicación- Modelo Los controladores, y el resto de la aplicación intercambiarán objetos Java (POJOS) como mensajes que contienen los datos que la aplicación gestiona. En el caso que abarca, el modelo contiene datos que han de ser duraderos en el tiempo y con reglas de integridad relacional que se han de satisfacer. Para ello se usa Hibernate 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 se define un objeto persistente mediante Hibernate. Existen otras anotaciones adicionales de Hibernate con las cuales podemos parametrizar el cómo será almacenada la información a la que hace ámbito. Normalmente la mayoría de anotaciones van aplicadas a nivel de atributo y vienen definidas según el estándar Java Persistence Api (JPA-2). Es Hibernate la implementación de referencia de dicho estándar, que es de obligado cumplimiento de los servidores de aplicaciones J2EE 5.0 y posteriores [19]. Las anotaciones más importantes son las que se refieren a las relaciones entre objetos que definirán la integridad relacional y consistencia 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 anotaciones adicionales a las definidas en JPA-2 que ayudan a la validación de los objetos del modelo antes de ser utilizados en la lógica de negocio. Estas anotaciones para validación de datos vienen definidas en el JSR-303 y la implementación de referencia es Hibernate Validator. Spring MVC reconoce dichas anotaciones y las usará como reglas que se han de cumplir a la hora de mapear los parámetros que llegan del request, dejando las restricciones no satisfechas dentro de BindingResult, en donde la aplicación puede consultar si las validaciones han ido bien o no y actuar en consecuencia. Ejemplos de 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 y Bean Validations dentro del modelo [14], con lo que si queremos distribuir el modelo a otras aplicaciones, éstas deberán incluir también las dos librerías para poder compilar correctamente el proyecto. Esto es una situación no deseable, pero las funcionalidades que aportan son suficientemente significativas como para aceptar dicha limitación. Al mismo tiempo no hay previstas integraciones tan fuertes mediante el modelo con otras aplicaciones, pero sí a futuro interconexiones con él mediante servicios web que requerirán definir un modelo público específico como subconjunto del modelo interno del proyecto, en dónde sólo aparezca información no sensible y que pueda ser distribuido hacia fuera del sistema. Implementacióndela aplicación–Vista Dados el modelo y los controladores que determinan el flujo de navegación del usuario por diferentes diálogos, las vistas son el último paso en la resolución de las peticiones Http y para ello el controlador deberá alojar en el objeto Model todos los objetos del modelo que contienen información a representar por la vista, por ejemplo Person. En el proyecto que se abarca las vistas son JSP que generan HTML dinámicamente. Los JSP pueden ejecutar pequeñas sentencias lógicas, como condicionales o bucles para elaborar tablas o listas dentro de una página web. Estos códigos lógicos y cómo imprimir atributos del modelo se invocan mediante librerías de etiquetas Tags. Java proporciona un surtido suficiente de Tags agrupados en dos librerías - Standar Tags y JST - que aceptan expresiones sencillas para mantener la lógica muy limitada en los JSP y que los grandes cálculos se realicen en los componentes de servicio de la lógica de negocio. A parte Spring Tags proporciona otro conjunto de Tags Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013.
  9. 9. AplicaciónSaaSparala AdministracióndeFincas • 9 para definir formularios acorde a como la validación y recuperació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 Tags de Spring se encargan de crear el HTML asociado para los campos Input Texts con el valor proveniente del modelo, mostrando o no mensajes de error si no han cumplido las validaciones indicadas en las anotaciones del modelo. Implementacióndelaaplicación–Servicio Los componentes con el código fuente correspondiente a la lógica de negocio se agrupan en servicios en forma de Beans gestionados por Spring IoC para la inyección de dependencias, principalmente en los controladores que los usen. Generalmente, los controladores recogerán la acción de negocio a ejecutar con sus parámetros y delegarán la operación en los servicios, los cuales se encargarán de ejecutar la operación dentro de un contexto transaccional. Véase tabla Tabla 5: Estructura de un Servicio. @Service @Transactional public 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 todos los métodos públicos estén encapsulados en al menos una transacción SQL. Puesto que unos métodos de un servicio pueden llamar a otros métodos del mismo servicio, Spring sólo creará una transacción salvo que se indique lo contrario. Si se desea puede configurarse que cada método tenga una transacción diferente o si queremos que la misma transacción se propague a los métodos internos de la llamada. Este parámetro y otros más se pueden configurar añadiendo la anotación transaccional en el método en vez de la clase. A su vez, la anotación permite otras configuraciones como: el modo de aislamiento, si será o no sólo lectura, tiempo máximo de espera, etc… Para completar la descripción de los servicios resta decir que en ellos se ejecutan las validaciones correspondientes a la lógica de negocio, como rangos de fechas o períodos de facturación. Posteriormente se realizan los cálculos correspondientes y los resultados se transmiten a los DAOs para que estos hagan permanentes los cambios en la base de datos. Implementacióndela 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 en base de datos. Descontando la capa ofrecida por Hibernate [14], estos últimos elementos se les denomina DAOs y su objetivo es aislar el sistema de persistencia usado a la capa de lógica de negocio para desacoplarla. De esta manera sería posible cambiar de sistema de persistencia aprovechando la lógica de negocio. Los DAOs a su vez son también Beans gestionados por Spring IoC, y mantienen la transacción SQL que el servicio les proporcionó. Spring tiene funcionalidades específicas para Hibernate por lo que se encarga de hacer llegar la transacción al punto de entrada de los DAO, que es mediante la sesión de Hibernate a través del SessionFactory. @Repository public 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 el formato que tendrá cualquier DAO implementado que se alojan en el aplicativo. 3.6 Despliegueyevaluacióndel lanzamiento El aplicativo se despliega sobre sistemas virtualizados dentro de la nube, donde se pone a disposición un número de instancias dependientes de la carga de trabajo. En concreto se ha utilizado Amazon Elastic Cloud Computing para desplegar el conjunto de elementos necesarios. Hay dos tipos de instancias, una de ellas destinadas a alojar la base de datos MySQL denominado instancia de base de datos, mientras que hay otras destinadas a procesar la lógica de la aplicación dentro de servidores Apache Tomcat, instancias web. Las instancias son máquinas virtuales que se comportan como las reales y contienen un sistema operativo basado en linux correspondientes a una distribución específica para servidores virtualizados de Amazon. Los dos tipos de instancias se diferencian entre ellas por el software que contienen, así que cada una de ellas tendrá el software instalado que se necesite: unas para el gestor de base de datos y las otras para arrancar un servidor web. Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013.
  10. 10. 10 • Ramón Arnau Gómez Aunque las dos instancias se basen en la misma distribución linux, las dos contienen configuraciones diferentes, por lo que hay que crear imágenes preconfiguradas a partir de la distribución. Una imagen (o AMI en términos de Amazon) corresponde a una configuración pre-establecida y congelada de una distribución con sistema operativo y el software necesario para el fin de la instancia. Como tenemos dos tipos de instancia, una contendrá la base de datos y la configuración de MySQL y la otra el servidor de aplicaciones Java Apache Tomcat y la configuración de éste. Se puede configurar el comportamiento de cada una de las máquinas virtuales. Cada proveedor determina los parámetros que pueden ajustarse, como capacidad de la CPU, cantidad de memoria RAM, 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, no almacena nada en el disco duro de la máquina virtual, pero en el script de arranque se ha configurado unos pasos para que acceda al repositorio del código fuente del aplicativo, construya la aplicación compilándola y empaquetándola en un fichero desplegable por el servidor de aplicaciones Web Tomcat. La otra instancia de base de datos es diferente a la Web respecto a que es una instancia no volátil, lo que escriba en el disco duro sí ha de ser durable en el tiempo, así que se le configura una unidad de red (al estilo NFS) donde será almacenado el contenido de las tablas de MySQL. Además, sólo una de las instancias de este tipo puede ser el maestro, dejando las demás como esclavas. Esto quiere decir que las escrituras sólo deben realizarse sobre la máquina maestro, y las demás replicar las operaciones en local después de que el maestro haya confirmado dichas operaciones. Así que la creación y destrucción de instancias tipo base de datos no es tan trivial como en el lado web, en este caso se requiere que el nombre de las máquinas se mantenga entre instancias porque será utilizado por los diferentes drivers Jdbc y un script adicional que active a uno y sólo uno de los nodos de base datos como máster, mediante la sentencia de SQL CHANGE MASTER [20]. Según la arquitectura en cloud descrita, las peticiones web entran en los sistemas de Amazon mediante un balanceador que distribuye dicha petición hacia los servidores Web virtuales. Puede verse un resumen del número de peticiones en la Ilustración 5: Resumen de sesiones Http para una instancia Web. Cada uno de los servidores Web delega la petición en la aplicación desarrollada. De ahí a la lógica de negocio y posteriormente a la base de datos a través de los DAOs. 4. RESULTADOS Una vez puesto en producción, el sistema se mantiene activo de forma estable aceptando peticiones Http de los diferentes navegadores web de los clientes. Los usuarios administradores de fincas pueden registrarse libremente sobre el sistema desde la página principal (Ilustración 6: Página principal del proyecto) y realizar pruebas gratuitas si utilizan pocos recursos, o pagando de forma mensual si el número de propiedades administradas supera la decena. En cuanto el usuario ha validado su correo electrónico, automáticamente se les habilita las funciones para crear las propiedades y propietarios de las diversas comunidades que deseen gestionar. Al la finalización del proyecto las funcionalidades descritas por cada uno de los perfiles de usuario están accesible desde un punto único y compartido, en donde los usuarios pueden acceder simultáneamente a los resultados de las liquidaciones y a los saldos de sus movimientos en tiempo real. El feedback proporcionado por los administradores de fincas es bastante satisfactorio, marcando un nivel de implantación aceptable a pesar del esfuerzo que requiere a estos la migración de todos los datos entre su posible sistema anterior y el nuevo. Por otro lado, los propietarios han declarado en diversas ocasiones mediante entrevistas personales, que la información a la que tienen acceso vía online (Ilustración 7: Vista parcial del Portal del Propietario) representa su fuente de información principal y más fiable, recurriendo únicamente a los listados impresos cuando no se dispone de una conexión a internet, marcando como exitoso uno de los objetivos principales del aplicativo. Actualmente el sistema se encuentra en producción después de un proceso que ha durado cerca de 3 años desde su creación, con más Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013. 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
  11. 11. AplicaciónSaaSparala AdministracióndeFincas • 11 de 500 visitas únicas semanales. En un total de 20.000 páginas servidas por semana y distribuidas entre 54 comunidades administradas. Se puede encontrar en las primeras páginas de resultados de Google en búsquedas con las palabras clave “Software Administración Fincas” y “Administración Fincas Online”. 5. CONCLUSIÓN Se han satisfecho los objetivos marcados. Se ha diseñado y desarrollado un sistema de administradores de fincas para usuarios domésticos y profesionales denominado Arteco Radis, adaptado al entorno Cloud, disponible en producción para cualquier usuario que desee administrar el control contable de su comunidad o comunidades de vecinos. Arteco Radis cumple todos los requisitos de usuario tanto a nivel funcional como a nivel técnico. Por un lado permite la realización correcta y consistente de las operaciones requeridas por el perfil de usuario y por otro lado cumple con las normas de accesibilidad, seguridad y usabilidad que marca el consorcio W3C, garantizando que el aplicativo se ejecutará correctamente en la mayoría de navegadores Web disponibles. La elaboración del portal ha implicado el estudio y elaboración de diferentes tareas: 1. Definir las infraestructuras necesarias para las operativas. En donde se han citado aquellos elementos que forman parte de las comunicaciones y sistemas adaptadas a un entorno Cloud. 2. Se ha realizado un análisis y elección de las alternativas tecnológicas. Para reducir riesgos minimizando esfuerzos en la elaboración se han estudiado las principales tecnologías más importantes del panorama Web, escogiendo la plataforma Java como el producto más maduro y con la mayor comunidad de usuarios de todos los disponibles. 3. Se ha evaluado la elección del proveedor del entorno Cloud. Siguiendo las pautas las pruebas realizadas sobre sistemas de carga, despliegue y servicios adicionales de seguridad para la contención y backups. 4. Descripción de los estándares de compatibilidad Web. Para llegar al máximo número de usuarios independientemente del navegador que se use o del dispositivo de visualización, ya sea un dispositivo móvil o fijo, se han incluido los principales estándares HTML, ECMAScript y WCAI en la generación del código de visualización. 5. Análisis y definición de los mensajes de entrada y salida de cada proceso de negocio. Una vez definida la tecnología y los elementos de información a gestionar, se han establecido los procesos y actividades para abordar el desarrollo por fases con hitos alcanzables involucrando al usuario desde el primer momento. 6. Definición de la arquitectura física y lógica del aplicativo. Dados los elementos que se han de interconectar en este punto se han establecido unidades funcionales tanto físicas (hardware virtual) como lógicas (software) para la división y simplificación de cada una de 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ón Modelo Vista Controlador que facilita la división e independencia 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 escogido herramientas de programación con inserción de código automático, gestores de versiones y software colaborativo para todo el equipo de desarrollo que facilitan el trabajo en grupo y la colaboración. 9. Definición del entorno de desarrollo y metodología de programación. Establecidas la tecnología de programación y las herramientas de construcción se han escrito las pautas del desarrollo para conseguir un código homogéneo, mantenible y fácil de probar antes de pasar a producción. 10. Definición de la metodología de pruebas y pase a producción. El pase a producción es un proceso complejo ya que debe mantenerse el servicio siempre disponible sin que el usuario note ninguna interrupción, por lo que en este punto se establecieron los procedimientos de pase a producción y control del código fuente. 11. Definición e implementación de cada uno de los módulos del aplicativo que dan soporte al funcionamiento completo. Por último y para cada módulo funcional se han descrito las características y particularidades para la construcción de cada uno de ellos dejando explicaciones de las soluciones incorporadas para cada problemática aparecida. Estos 11 puntos resumen todo el conjunto de actividades que han sido necesarias realizar para poner en marcha la aplicación, partiendo únicamente del conocimiento de negocio que transmitido a personal formado en nuevas tecnologías, ha sido capaz de reescribir los procesos de gestión diarios adaptándolos a un entorno Cloud y de alta disponibilidad en forma de una aplicación rentable y disponible al gran público. 5.1 Mejoras Arteco Radis no es un producto cerrado, es un primer paso que sirve para continuar el desarrollo de nuevos servicios y operativas a los administradores de fincas destinados a crear un sistema de pago por uso de calidad, que permita mejorar la gestión interna y administrativa de cada usuario con y para su comunidad. También puede especializarse o añadir código adicional para mejorar la adaptación de las nuevas generaciones de dispositivos móviles, integraciones con otras plataformas existentes para la administración de comunidades e incluso con aplicaciones contables para la importación y exportación de datos. La aparición de tecnologías que mejoran la visualización y la interacción de los usuarios con las interfaces gráficas son un objetivo a tener presente cara al futuro, tecnologías como JavaFX, Silverligth y Flex o el hermano mayor de todas ellas HTML5 pueden mejorar en un alto grado todos los conceptos de análisis técnico y toma de decisiones con cuadros de mando integrados que centralicen toda la información que cualquier administrador o propietario pueda necesitar. Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013.
  12. 12. 12 • Ramón Arnau Gómez Un portal Web debe ser un servicio que evoluciona con el tiempo adaptándose continuamente a las nuevas tecnologías y requisitos de los usuarios que exigen un alto compromiso por las entidades que las soportan, sobre todo cuando la información que gestiona este tipo de portales es tan importante como el capital económico de 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 Reference http://docs.spring.io/spring/docs/3.0.x/reference/mvc.ht ml [13] Spring IOC Reference http://docs.spring.io/spring/docs/3.0.x/reference/beans.ht ml [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 Manuals http://dev.mysql.com/doc/ Màster Universitari en Tecnologies de la Informació, Universitat de les Illes Balears, 2013.

×