Arteco Radis - Trabajo Proyecto fin de Máster

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 • 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.

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

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
Ilustración 1: Actores del sistema

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.

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.
Ilustración 2: Componentes principales del aplicativo
Ilustración 3: Arquitectura Cloud

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
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ó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

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.

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
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á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.

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/

Arteco Radis - Trabajo Proyecto fin de Máster

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Arteco Radis - Trabajo Proyecto fin de Máster

Ähnlich wie Arteco Radis - Trabajo Proyecto fin de Máster (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (15)

Arteco Radis - Trabajo Proyecto fin de Máster