Mejoras al prototipo anterior:

En la actualidad, se puede encontrar un Prototipo [7] similar en varios aspectos a la Aplicación Web desarrollada en este trabajo. A continuación se mencionan diversas deficiencias del mismo junto con las mejoras desarrolladas en el presente trabajo.

3.5.1 Proceso de análisis de datos:

En el prototipo Desktop desarrollado con anterioridad, se iniciaba el proceso de análisis de datos al comienzo de la aplicación, ya que el resultado del mismo se guardaba en memoria, lo cual era bloqueante y el usuario debía esperar a que termine dicho proceso para comenzar a utilizar el prototipo. Asimismo, al actualizar algún mapeo de una característica con un producto, ahí mismo se iniciaba el proceso de análisis nuevamente para tenerlo actualizado en memoria, aquí el usuario debía esperar a que termine para realizar otra operación.

Ahora, en cualquier momento que quiera el usuario, con el botón “Iniciar Análisis”, inicia un nuevo análisis. Además, ahora queda esa información persistente (guardado en la BD) que antes se tenía en memoria, por eso al iniciar la aplicación no se inicia más el análisis y permite enseguida empezar a realizar cualquier operación, como predecir, asignar, ver reportes, etc.

También hay que tener en cuenta que al invocar al método encargado de iniciar el análisis (ahora servicio REST) no se bloquea la interfaz, el servicio queda corriendo en background.

46 3.5.2 Adaptación a más dominios (generalización)

Se creó una aplicación que no sólo está preparada para el servicio de alimentación que brinda Cáritas sino también para otros dominios y/o servicios, como puede ser administrar la adquisición y asignación de ropa, remedios en un hospital o materiales de construcción.

La base de datos que usa la aplicación es configurable con sólo cambiar una variable en un archivo externo a la aplicación (conn.properties). Esta práctica, de externalizar los archivos de configuración (.properties) de nuestras aplicaciones, hace que el software sea más dinámico, y nos ayuda a evitar tocar código cada vez que se quiera cambiar un valor de configuración. Con esto se mejora la conexión a la BD, la cual se encontraba en una clase en java, ya que era un prototipo en el que se llevaron a cabo pruebas locales.

Entonces, con simplemente cambiar una variable de un archivo de configuración, la cual contiene el nombre de la BD, se estará accediendo a otra BD con la misma estructura que la de Cáritas pero con otro contenido.

Por lo tanto, al almacenar las aplicaciones web como ficheros .war, si se introducen la configuración de la conexión a BD en un fichero XML de Spring o en un fichero de propiedades dentro del propio War, no se podrá tomar directamente la aplicación del Servidor y desplegarla tal cual en el servidor de QA y el servidor de desarrollo, ya que cada uno de ellos tendrá sus propios datos de conexión a BD.

Spring proporciona mecanismos para externalizar la configuración que ayudan a resolver este tipo de situaciones utilizando “Property placeholder configurer” que sustituye las propiedades de los marcadores de posición con los valores obtenidos de un archivo de propiedades externo.

La configuración de una aplicación suele variar según el entorno en el que se ejecuta, la opción recomendada es que sea externalizada y que el artefacto que se despliega en cada entorno sea el mismo.

Desarrollar una aplicación no consiste sólo en programar el código que proporciona su funcionalidad, igual de importante es poner en producción esa aplicación para que preste su servicio, algo de lo que el desarrollador no debería ser ajeno. Casi siempre hay algo de configuración que varía entre entornos siendo estos al menos el de desarrollo y producción. Una aplicación, en su ciclo de vida, pasa por varios entornos de ejecución hasta llegar a producción, desde desarrollo, pruebas, QA y finalmente en producción. Seguramente la configuración de la aplicación, en cada uno de estos entornos, varía, por ejemplo, las direcciones ya sean IP o nombres de dominio de las bases de datos relacional u otros servicios externos.

Para que en el entorno de pruebas y QA se use exactamente el mismo artefacto (en Java un archivo war o jar) que el que se enviaría al de producción, la configuración de la aplicación no debería ser incluida en el mismo.

3.5.3 Login

En el ámbito de seguridad informática, login o logon (en español ingresar o entrar) es el proceso mediante el cual se controla el acceso individual a un sistema informático mediante la identificación del usuario utilizando credenciales provistas por el usuario.

Un usuario puede hacer el login a un sistema para obtener acceso y puede hacer el logout o logoff (en español salir o desconectar) cuando no se precisa mantener el acceso. Logout consiste en cerrar el acceso personal a un sistema informático, al cual anteriormente se había realizado el login.

En esta aplicación se creó un Login que valide usuario y password guardados en la tabla Usuario, ya que el prototipo de Escritorio no contaba con el mismo. Esto posibilita que haya un responsable por asignación, cuando el trabajo dentro de la

47

Organización sea ejecutado por distintas personas, de acuerdo a la disponibilidad del voluntariado.

3.5.4 Multiusuario

En esta categoría se encuentran todos los sistemas que cumplen simultáneamente las necesidades de dos o más usuarios, que comparten mismos recursos. Este tipo de sistemas se emplean especialmente en redes. En otras palabras consiste en el fraccionamiento del tiempo (timesharing). El tiempo compartido en ordenadores o computadoras consiste en el uso de un sistema por más de una persona al mismo tiempo. El tiempo compartido ejecuta programas separados de forma concurrente, intercambiando porciones de tiempo asignadas a cada programa (usuario).

En este caso, se pueden conectar todas la Cáritas de Tandil y usar la misma aplicación al mismo tiempo.

Es una Aplicación Web, lo que mejora considerablemente el prototipo de Escritorio desarrollado anteriormente. Esta migración presenta ventajas interesantes. Se instala en un servidor, por lo que cualquier usuario con acceso a dicho servidor podrá ejecutar la aplicación web, sin necesidad de instalar nada de manera local y sin importar qué sistema operativo esté usando, basta contar con un navegador web.

3.5.5 Responsividad

Esta nueva aplicación se ajusta (adapta) a varias resoluciones diferentes de pantallas, gracias a la responsividad. Pudiendo ser visualizada correctamente en dispositivos como pc, tablet o celular.

El responsive design es un concepto que ataca la idea de multiplicar código. Ajusta la estructura de la interfaz sin necesidad de crear múltiples versiones de una misma aplicación, para ofrecer la mejor experiencia a diferentes resoluciones de dispositivos.

3.5.6 Mantenimiento

Un factor clave en todo proyecto de software es qué tan fácil o difícil es mantener la aplicación, tanto para resolver bugs como para añadir funcionalidad. En ese sentido, hay algunas características de AngularJS que han resultado especialmente beneficiosas.

En esta aplicación, el costo de arreglar un bug no es costoso, ya que el Backend está separado en varios servicios, el logueo ayuda a encontrar el bug y tratar de arreglarlo, el Frontend está modularizado, se separa el html del javascript y también se hace una capa de invocación al Backend mediante los services.js, al estar todo modularizado y separado, se hace fácil encontrar y corregir un componente [17].

3.5.7 Familias con características multivaluadas

Un aspecto positivo que se agregó en la Aplicación fue la posibilidad de contar con familias con características multivaluadas. Es decir, por ejemplo, a la característica de hipertenso, no sólo será posible un único producto relacionado con dicha característica.

Con esto se logra que a una familia con una característica determinada se le puedan dar más de un producto apropiado y no esté destinado a recibir sólo uno específico y se corra el riesgo de que haya otros productos para esa característica que no le sean provistos a pesar de que se cuenta con ellos en el inventario de productos disponibles.

48 3.5.8 Alimentación automática de la tabla histórico de productos

Otra de las características fundamentales que posee la Aplicación Web desarrollada es que la misma presenta la posibilidad de que la tabla de los productos que sean donados se re-alimente automáticamente. Esto evita que un usuario tenga que hacerlo de forma manual, evitando una pérdida de tiempo considerable.

3.5.9 Usabilidad

Además de las pautas presentadas, se tuvieron en cuenta las siguientes cuestiones específicas:

Se apuntó a un diseño minimalista sin gráficos pesados. El mismo posee estilo visual y un formato de contenido estandarizado.

Dentro de la aplicación se maneja un lenguaje con el que el usuario está acostumbrado, con términos cotidianos y comprensibles.

Se definió una estructura de contenido que agrupa funcionalidades y contenido relacionado, de esta forma se pretende que la aplicación sea intuitiva y no requiere de un proceso de aprendizaje para ser utilizada eficientemente.

Se crearon mensajes que se le presentarán al usuario por ejemplo cuando no complete algún campo requerido para llevar a cabo alguna operación.

Se pretendió presentar una interfaz lo más limpia y simple posible, para ello se intenta no sobrecargar con información y posibilidades de acción que posee el usuario. Para que el usuario pueda actualizar tablas de la base de datos, se puede realizar ediciones con doble-click sobre el campo requerido y además en caso de que desee agregar nuevas filas o eliminar se hacen mediante pop-up.

Durante el desarrollo de la aplicación se utilizó el navegador Google Chrome, pero la misma también fue testeada en Mozilla Firefox e Internet Explorer para asegurar su correcto funcionamiento.

49