1 UNIVERSIDAD NACIONAL DEL CENTRO DE LA PROVINCIA DE BUENOS AIRES TRABAJO FINAL DE CARRERA INGENIERÍA DE SISTEMAS -------------------------------------------------------------------------------------------------------------------- ------- Generalización y Diseño Web de Herramienta de Soporte para la Toma de Decisiones en Organizaciones de Ayuda Social. -------------------------------------------------------------------------------------------------------------------- ------- Autor: Mariano Ezequiel Weimann Directores: Mag. María Rosa Dos Reis. Mag. Moisés Bueno. Facultad de Ciencias Exactas Universidad Nacional del Centro de la Provincia de Buenos Aires
Universidad Nacional del Centro de la Provincia de Buenos Aires
2
Resumen
El presente trabajo desarrolla mejoras, tanto en requerimientos funcionales y
no funcionales, con respecto a un prototipo diseñado con anterioridad para una Tesis de Grado. En el mismo se llevó a cabo una primera aproximación en lo que se refiere al desarrollo de una Aplicación de escritorio (no Web) para toma de decisiones en organizaciones de asistencia social. Dicha aplicación sólo puede ser utilizada para la Organización Social Cáritas.
Además de las mejoras que se detallan en este informe, se lleva a cabo la migración de este prototipo para que deje de ser de Escritorio y pase a ser Web (con los beneficios que esto conlleva).
Otro punto importante que se desarrolla es la abstracción de la propuesta inicial ya que la misma se centró en una Institución en particular (Cáritas) y, el nuevo trabajo, puede ser utilizado por varias Instituciones y por varios Usuarios al mismo tiempo.
El resultado final es una herramienta de soporte para la toma de decisiones que permite predecir los productos a ser adquiridos por Organizaciones de Asistencia Social con el fin de ser distribuidos eficientemente a sus beneficiarios.
Para lograr este objetivo se desarrolló una Aplicación Web utilizando los principios de la Minería de datos mediante métodos de Inteligencia artificial, Aprendizaje automático, Estadística y Sistemas de bases de datos.
Esto permite, mediante el conocimiento adquirido sobre los beneficiarios, ser capaces de interpretar sus objetivos, expectativas y deseos.
Posteriormente, este análisis es útil para llevar a cabo un estudio y realizar un tratamiento de datos masivos para extraer conclusiones e información relevante. En este trabajo se presentan los resultados de dos casos de estudio (de manera que se pueda ver reflejada la abstracción antes mencionada) y aplicación en diferentes dominios de acción. Para esto se utiliza la herramienta matemática de Minería de datos Weka, la cual permite extraer patrones, tendencias y regularidades para describir y comprender mejor los datos y predecir comportamientos futuros.
Al momento de finalización de este Trabajo Final, la Facultad de Ciencias Exactas ganó una Convocatoria a Proyectos de Extensión de la Subsecretaría de Políticas Universitarias con la propuesta “TICs en la Gestión Solidaria”. La misma incluye la implementación una herramienta de ASIGNACIÓN DE ALIMENTOS A GRUPOS DE FAMILIAS y una herramienta de trabajo inter-institucional en Organizaciones Sociales, ambas serán implementadas en forma conjunta con la Asociación Civil Proyecto Koinonía. Uno de los servicios ofrecidos por la Organización comprende la herramienta desarrollada en el presente trabajo.
Figura 1: Esquema de la Minería de Datos .................................................................................. 17
Figura 2: Aplicaciones de la I.A .................................................................................................... 18
Figura 3: Etapas del Proceso KDD................................................................................................ 19
Figura 4: Usos y tipos de Programación Dinámica ...................................................................... 24
Figura 5: Representación del Algoritmo de Greedy .................................................................... 25
Figura 6: Arquitectura cliente-servidor utilizada en el diseño de la solución propuesta. El
usuario interactúa con el cliente, mientras que el procesamiento de los datos es llevado a cabo
en el servidor. .............................................................................................................................. 27
Figura 7: Arquitectura cliente-servidor ....................................................................................... 28
Figura 8: Arquitectura MVC dentro del Cliente........................................................................... 29
Figura 9: Diagrama de Entidad/Relación utilizado en la Aplicación ............................................ 40
Figura 10: Login de la Aplicación ................................................................................................. 49
Figura 11: Vista de la pantalla de Predicción .............................................................................. 50
Figura 12: Vista de la pantalla de Actualización .......................................................................... 51
Figura 13: Vista de la pantalla de Asignación de Recursos ......................................................... 51
Figura 14: Vista de la pantalla de Reporte de Asignaciones ....................................................... 52
Figura 15: Grilla de Precios y sin Características ......................................................................... 54
Figura 16: Predicción mes de Enero ............................................................................................ 54
Figura 17: Predicción mes de Julio .............................................................................................. 55
Figura 18: Predicción mes de Diciembre ..................................................................................... 55
Figura 19: Error Marzo sin Productos ......................................................................................... 55
Figura 20: Error Octubre sin Productos ....................................................................................... 56
Figura 21: Predicción mes de Diciembre con Encuestas ............................................................. 57
Figura 22: Predicción mes de Diciembre con Encuestas ............................................................. 57
Figura 23: Predicción mes de Diciembre con Encuestas ............................................................. 57
Figura 24: Predicción Marzo con encuestas ................................................................................ 58
Figura 25: Predicción Octubre con encuestas ............................................................................. 58
Figura 26: Pantalla de Actualización con Precios y Características ............................................. 59
Figura 27: Asignar agua mineral .................................................................................................. 60
Figura 28: Asignar polenta .......................................................................................................... 61
Figura 29: Asignar pan dulce ....................................................................................................... 61
Figura 30: Asignar galleta sin sal ................................................................................................. 61
Figura 31: Consulta sobre importación a histórico de productos ............................................... 62
Figura 32: Obtener asignación para el beneficiario 1 ................................................................. 63
Figura 33: Obtener asignación para el beneficiario 2 ................................................................. 63
Figura 34: Obtener asignación para el beneficiario 3 ................................................................. 63
Figura 35: Obtener asignación para el beneficiario 4 ................................................................. 63
Figura 36: Obtener asignación para el beneficiario 5 ................................................................. 64
Figura 37: Exportar reporte individual ........................................................................................ 64
Figura 38: Contenido del reporte exportado .............................................................................. 65
Figura 39: Exportar reporte para todos los beneficiarios ........................................................... 65
Figura 40: Contenido del reporte total exportado ...................................................................... 66
7
Figura 41: Borrar historial de reporte ......................................................................................... 67
Figura 42: Pantalla de predicción en servidor ............................................................................. 67
Figura 43: Pantalla de predicción fuera del servidor .................................................................. 68
Figura 44: Login en servidor ........................................................................................................ 68
Figura 45: Login fuera del servidor .............................................................................................. 68
Figura 46: Pantalla de actualización en servidor ......................................................................... 69
Figura 47: Pantalla de actualización fuera del servidor .............................................................. 69
Figura 48: Se actualiza el precio en servidor ............................................................................... 70
Figura 49: Fuera del se ve el cambio hecho anteriormente........................................................ 70
Figura 50: Se asigna agua mineral en servidor ............................................................................ 71
Figura 51: Generación de reporte fuera del servidor ................................................................. 71
Figura 52: Excepción al eliminar mapeo ..................................................................................... 72
Figura 53: Excepción al eliminar precio....................................................................................... 72
Figura 54: Excepción al agregar mapeo ...................................................................................... 73
Figura 55: Excepción al agregar precio........................................................................................ 73
Figura 56: Excepción en predicción ............................................................................................. 73
Figura 57: Excepción en asignación ............................................................................................. 74
Figura 58: Excepción en Reportes ............................................................................................... 74
Figura 59: Pantalla de actualización ............................................................................................ 75
Figura 60: Predecir en hospital ................................................................................................... 75
Figura 61: Asignar en hospital ..................................................................................................... 76
Figura 62: Reportes en hospital .................................................................................................. 77
8
Índice de tablas
Tabla 1: Contenido de la base de datos Histórico de Productos ................................................ 53
Tabla 2: Contenido de la base de datos PRECIOS ....................................................................... 53
Tabla 3: Contenido tabla MAPEOS .............................................................................................. 56
Tabla 4: Contenido tabla RESPUESTAS ENCUESTAS .................................................................... 56
Tabla 5: Contenido tabla OPCIONES ........................................................................................... 56
Tabla 6: Parte del contenido de la tabla de UTILIDADES ............................................................ 60
Tabla 7: Tabla de histórico de productos sin actualizar por importaciones ............................... 62
Tabla 8: Tabla de histórico de productos actualizada luego de aceptar la importación ............ 62
Tabla 9: Contenido de la tabla de UTILIDADES ........................................................................... 76
9
Índice de ilustraciones
Ilustración 1: Diagrama general de la Aplicación ........................................................................ 40
Ilustración 2: Diagrama login ...................................................................................................... 41
Ilustración 3: Diagrama de iniciar análisis ................................................................................... 42
Ilustración 4: Diagrama predicción ............................................................................................. 43
Ilustración 5: Diagrama de asignaciones ..................................................................................... 44
Ilustración 6: Diagrama de reporte de asignaciones ................................................................... 45
10
Capítulo 1: Introducción.
La presente investigación se encuentra en el marco de las actividades de la Asociación Civil Proyecto Koinonía [8]. Esta asociación, junto a alumnos de la carrera Ingeniería de Sistemas de la Facultad de Ciencias Exactas de la UNCPBA, ha estado trabajando los últimos años en diseño, desarrollo e implementación de diversas herramientas de gestión que faciliten la asistencia y promoción humana con la ayuda de las Tecnologías de la información y la Comunicación (TICs).
El concepto Asistencia Social se utiliza frecuentemente como sinónimo de Bienestar Social o de Servicios Sociales restringiendo así todo su contenido a una de sus formas, que aun siendo hoy la más significativa, no es la única, ni lo ha sido a lo largo de la Historia [59].
En [51] se define este concepto como "toda actividad consciente, organizada y dirigida de manera individual o colectiva, que de modo expreso tiene por finalidad actuar sobre el medio social, para mantener una situación, mejorarla o transformarla". Por otra parte, en [52] entienden que la Asistencia Social tiene como finalidad “conseguir la mejora de las condiciones de vida de todos los ciudadanos y a la satisfacción de las necesidades básicas de los mismos, para terminar con la injusticia social”. Así, liga este concepto al Bienestar Social y afirma que en cierta forma entra en oposición con la mera acción benéfica.
También, en [53], sitúan la Asistencia Social en el campo de la relación entre el binomio necesidades y recursos; para ellas esa relación se caracteriza por el conflicto por lo que es necesaria una intervención intencionada, que es precisamente, lo que denominan Acción Social.
A través del conocimiento adquirido sobre los beneficiarios de cada organización de ayuda social, se debe ser capaz de interpretar sus objetivos, expectativas y deseos. Esto es conseguido por la Minería de datos (MD), la cual utiliza métodos de Inteligencia Artificial, aprendizaje automático, estadística y sistemas de Bases de datos (BD), los cuales facilitarían la interpretación para llevar a cabo un estudio y realizar un tratamiento de datos masivos para extraer conclusiones e información relevante de ellos.
En resumen, el concepto de asistencia social, está asociado a un servicio que se presta para solucionar problemas de diversa índole y mejorar las condiciones de vida de las personas. El trabajo de las organizaciones de asistencia social se orienta a que todos los individuos puedan satisfacer sus necesidades básicas. Las prestaciones englobadas en el concepto pueden ser muy variadas e incluyen desde apoyo educativo hasta la facilitación de una vivienda, pasando por la entrega de alimentos o de remedios, entre otras.
La MD puede definirse como un proceso de descubrimiento de nuevas y significativas relaciones, patrones y tendencias al examinar grandes cantidades de datos [1].
Para llegar a los objetivos no bastan las herramientas genéricas, se necesita también capacidad analítica para identificar patrones y predicciones a partir de los datos estratégicos de una organización.
La MD provee un método automático para descubrir patrones en datos, sin la tendenciosidad y la limitación de un análisis sustentado meramente en la intuición humana. Además, muchos conjuntos de datos son demasiados grandes e intrincados para tratamiento manual [2]. Una de las herramientas utilizadas para la minería de datos es Weka.
Weka es una herramienta de tipo software para el aprendizaje automático y minería de datos diseñado a base de Java y desarrollado en la universidad de Waikato en Nueva Zelanda en el año 1993, esta herramienta por su nombre en inglés (Waikato Environment for Knowledge Analysis) además es una herramienta de distribución de licencia GNU-GLP o software libre.
11
Weka contiene una colección de algoritmos para realizar análisis de datos y modelado predictivo, también tiene herramientas para la visualización de estos datos y provee una interfaz gráfica que unifica las herramientas para que estén a una mejor disposición.
En base a lo explicado anteriormente, en este trabajo se presenta una Aplicación Web, utilizando la herramienta matemática de MD Weka, la cual permite extraer patrones, tendencias y regularidades para describir y comprender mejor los datos y predecir comportamientos futuros [1].
Se toma como entrada de la aplicación una BD en la cual están registrados los beneficiarios que forman parte de un dominio de estudio en particular, así como también los nuevos datos que se van ingresando.
La información alojada en la BD se transforma a un tipo de dato estructurado, el cual se convierte en entrada de la herramienta de MD Weka. Ésta, estudia y analiza la información generando reglas, las cuales servirán para llevar a cabo un análisis con el que se producirá el resultado final.
Otro punto importante enfocado es el desarrollo de una generalización de la aplicación de manera que no se encuentre atada a un único dominio.
Esto último se lleva a cabo debido a que en [7] se realizó un trabajo que se centraba en un único dominio de distribución de recursos (bolsón de alimentos que mensualmente distribuye Cáritas). Entonces, viendo que lo anterior era de gran ayuda, se pretende el desarrollo de una aplicación que sea más abarcativa de manera que sirva de soporte para diversas organizaciones de ayuda social que no necesariamente se basen en la distribución de alimentos.
1.1 Estado del Arte y descripción de la problemática
En lo que respecta a la toma de decisiones para compras y asignaciones de
productos en Organizaciones Sociales dependiendo de las características de los beneficiarios presentes, según se resume en [54], “se planteó un enfoque de asignación de recursos orientado a la resolución a nivel individual de cada organización. Siguiendo esta línea, se trabajó en un principio sobre el ordenamiento de las familias en base a sus necesidades básicas insatisfechas –NBI- [40], para luego dar lugar a una serie de aplicaciones donde se tuvieron en cuenta distintos métodos de asignación de los recursos disponibles en cada organización. En estos trabajos se plantearon diferentes soluciones de optimización: aplicación de una heurística de ponderación lineal [42], utilización del algoritmo de Bellman basado en la teoría de utilidades [43], diseño de un algoritmo genético de tipo binario [44] y técnica ELECTRE [47] Paralelamente se desarrolló un prototipo que permitió la comparación de resultados entre tres métodos utilizados en la asignación: proceso analítico jerárquico, arrow-Raynaud y metaheurístico [48].
En la evolución del conocimiento en la materia se observó que la atención de NBI requiere una visión sistémica y global [49] donde las TICs se enfocan para brindar soluciones en la toma de decisiones. En tal sentido, como articulación entre organizaciones que prestan servicios de similares características, surge una herramienta informática denominada AYUDARG. La misma consiste en una serie de aplicaciones que utilizan tecnologías web para dar soporte en la toma de decisiones a una agrupación en red de organizaciones no gubernamentales (ONGs) de carácter social” [50].
En lo que se refiere al presente trabajo, cuando se habla de características de los beneficiarios, se hace referencia a una problemática en sí que puede tener un beneficiario determinado. Es decir, por ejemplo, si en una familia existe una persona hipertensa, eso mismo se lee como una característica del beneficiario. De tal modo, y basándose en dicha característica, se hace el análisis correspondiente para que, al momento de asignar productos, el beneficiario con problemas para ingerir alimentos con sal, obtendrá recursos acordes a su característica.
12
De la mano con lo anterior, en el trabajo también se hace presente la posibilidad de predecir qué recursos se deberán comprar por parte de la Organización Social cuando se tiene un dinero determinado. Para esto, se tienen en cuenta, también, las características de los beneficiarios junto con el historial de qué productos prevalecen en cada donación en un determinado mes del año. Es decir, es probable que en meses de verano se tenga que comprar más frutas o agua mineral que en épocas de frío, por ejemplo.
Ahora bien, cuando se habla de asignar, se hace referencia a un conjunto de recursos que serán entregados a los beneficiarios correspondientes. Luego del análisis hecho, y conociendo las características de cada familia, se le entregará a los beneficiarios los productos necesarios conforme a las características de la familia y a los intereses que presente el mismo en base a cada producto.
En el año 2012, y como tarea relacionada al Proyecto Koinonia, estudiantes de la carrera Ingeniería de Sistemas realizaron un trabajo de cátedra para la materia Investigación Operativa en el que, mediante la Teoría de Utilidad y el Algoritmo de Bellman, se optimizó la distribución de recursos realizada mensualmente ya que en lugar de asignar recursos a familias uniformemente; se le entregaría a cada familia lo que necesita a fin de maximizar el beneficio total. Así, al principio de cada mes, quienes llevan adelante la organización de Cáritas, podrían asignar eficientemente los productos a las familias teniendo en cuenta sus necesidades básicas.
Continuando este último trabajo se crea un prototipo de ayuda a la toma de decisiones, el cual proponía resolver un problema central de Cáritas en el que, cada vez que se produce una entrada de dinero o productos, se trabaja de forma intuitiva, por parte de un voluntariado, quienes deciden qué productos se compran para luego distribuir a los beneficiarios [14].
Ese prototipo de Escritorio desarrollado cuenta con numerosas desventajas que serán explicadas en los capítulos 3 y 4.
Por ese motivo, se consideró de interés desarrollar una herramienta web que asista al personal encargado de cualquier Organización Social al momento de la toma de decisiones y que además pueda asignar eficientemente los productos a los beneficiarios.
Además de ser una Aplicación Web, tiene la ventaja de que no sólo está preparada para la distribución de alimentos Cáritas, sino también para otros dominios, 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 propuesta en este trabajo es configurable con sólo cambiar una variable en un archivo externo a la aplicación. Esta práctica, de externalizar los archivos de configuración de nuestras aplicaciones, hace que el software sea más dinámico, y ayuda a evitar tocar código cada vez que se quiera cambiar un valor de configuración.
A continuación se precisa el objetivo y alcance de la propuesta.
1.2 Objetivos
El objetivo principal es disponer de una Herramienta Web Generalizada, de
manera que cualquier Organización Social con acceso a internet pueda utilizarla para realizar las asignaciones de productos a beneficiarios, y que permita automatizar el proceso de gestión del ciclo de cada donación realizada a cualquier Organización social.
Se busca que la aplicación sea web para realizar un aporte tecnológico a lo que es la cooperación ínter-institucional (ayuda y colaboración en tiempo real entre instituciones diferentes pero relacionadas entre sí), trabajo en red (estructuras en que personas o instituciones están relacionadas entre sí) y ayuda social a organizaciones que reciben donaciones y reparten de alguna manera lo recolectado.
13
Se plantea realizar una Aplicación en la que se pueda predecir específicamente qué productos comprar y en qué cantidad de acuerdo a las necesidades de cualquier Organización Social de acuerdo a lo sucedido en años anteriores y a los nuevos datos que se van obteniendo, y de esa forma, brindar asistencia para la correcta toma de decisiones a la hora de comprar los productos que serán distribuidos a los beneficiarios.
Un objetivo secundario de la Aplicación, es realizar una interfaz de usuario simple e intuitiva para facilitar la usabilidad de la Aplicación Web, ya que concretamente será puesta a disposición de cualquier persona de una Organización determinada.
Además, otro objetivo secundario, y no por esto menos importante, es permitir el uso de la Aplicación en RED. Es decir, cualquier persona autorizada dentro de una red particular, pueden utilizar la Aplicación y realizar tareas en paralelo.
Se decidió brindar esta funcionalidad debido a que desde hace tiempo se viene llevando a cabo una importante iniciativa en lo que se refiere al trabajo inter-organizacional [55] y [56].
Además, se desea que la Aplicación cuente con una metodología específica de manera que, con una modificación sencilla, se pueda adaptar el sistema a un nuevo dominio de uso. Con esto, se logra una generalización en la Aplicación que permite que múltiples Organizaciones Sociales, cuyos fines sean diferentes, puedan utilizar el presente trabajo sin inconvenientes.
Por otra parte, se busca que la Aplicación cuente con un Login que permita agregar seguridad al sistema. De esta manera, sólo podrán acceder los usuarios registrados. Como se mencionó antes, varios usuarios al mismo tiempo podrán hacer uso de la Aplicación, lo que le aporta la característica de Multiusuario.
También, al ser un sistema web que podrá ser accedido desde celulares, tablets o computadoras, se requiere que el mismo sea Responsivo y se adapte a diversas resoluciones sin tener problemas de pantallas mal formadas.
Además de los objetivos planteados, se planea hacer varias mejoras sobre el prototipo anterior. Las mismas serán explicadas en detalle en la sección 3.2.1.
Como resumen de dichos objetivos, el usuario podrá seleccionar el período de tiempo del cual se llevará a cabo la predicción. También, podrá ingresar nuevos datos que formarán parte de la BD, junto con información relevante que será de gran ayuda al estudio y análisis de los mismos, como por ejemplo el precio de cada producto y el dinero disponible.
La respuesta será una sugerencia de cómo deberá ser usado lo recolectado, la cual se podrá visualizar de forma numérica. Por otra parte, se incorpora la herramienta de Optimización de recursos [5], la cual indica cómo distribuir lo que se haya recolectado con el agregado de poder exportar dicho informe en un archivo “.csv”. Esta distribución va a tener en cuenta los productos donados, así como también los obtenidos a partir de la predicción.
Técnicamente hablando, para lograr la generalización buscada y para el desarrollo de la Aplicación Web necesaria a partir del trabajo realizado en [7], se podrán adaptar los servicios que formarán parte del back-end que contiene toda la lógica de procesamiento y el acceso a la BD. A través de los lenguajes y frameworks (AngularJS), se recibe, procesa y envía información al navegador del usuario enviando datos puros en XML o JSON, para ser procesados por Javascript.
Se desarrolla un front-end que se encargue de maquetar la estructura semántica del contenido (HTML), codificar el diseño en hojas de estilo (CSS) y agregar la interacción con el usuario (Javascript).
Por último, Javascript y sus frameworks añaden el componente de interactividad y conexión al servidor.
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
14
necesidad de instalar nada de manera local y sin importar qué sistema operativo esté usando, basta contar con un navegador web.
Son aplicaciones muy ligeras (el Navegador de Internet no contiene el programa) por lo que el Usuario no necesita tener un ordenador de grandes prestaciones para trabajar con ellas. Consumen muy pocos recursos del equipo en el que están instaladas.
1.3 Organización del Documento
El proyecto consta de varias partes bien marcadas que se detallan a
continuación: En el capítulo 1 se presenta la Introducción a la problemática inicial junto con
los objetivos del trabajo. En el capítulo 2 se detalla el estudio de la MD, se analizan y marcan en detalle
los conceptos más importantes de esta metodología de tratamiento de datos. Por otro lado, se exponen algunas técnicas adicionales que se utilizaron para resolver problemas en algunas etapas del desarrollo.
En el capítulo 3 se presenta la solución al problema planteado detallando la Aplicación Web creada y describiendo su funcionamiento, uso e implementación. Además, se presentan comparaciones detalladas con respecto a la herramienta existente. En el capítulo 4 se presentan las interfaces involucradas en la Aplicación Web y se analizan los resultados obtenidos de las pruebas realizadas, mostrando gráficos y tablas.
Finalmente se exponen las pruebas y conclusiones obtenidas y los trabajos futuros propuestos.
1.4 Cronograma del proyecto
La planificación de este proyecto se dividió en seis tareas principales que
abarcaron desde la fase de planificación y diseño hasta la fase de implementación y test de la Aplicación Web generada.
Las principales tareas en las que se dividió el proyecto son las siguientes: Relevamiento bibliográfico: Relevamiento de la bibliografía disponible de libros,
internet, papers, etc. Análisis de trabajos relacionados: Se estudió de forma exhaustiva la
herramienta de base. Análisis y diseño de la solución: La etapa del Diseño del Sistema contempló
cuatro etapas. Implementación y desarrollo de la Aplicación Web: Fase en la que se
implementó la Aplicación Web de Predicción. Análisis, testeo y discusión de los resultados obtenidos: En este apartado se
analizaron los resultados obtenidos del estudio detallado de un conjunto de datos generado. Redacción de informe final de tesis: Fase en la que se generó la documentación requerida por el proyecto.
15
Capítulo 2: Elección de las técnicas utilizadas. El Aprendizaje Automático (AA), es un campo de la Inteligencia Artificial (IA) que se dedica al estudio de los agentes/programas que aprenden o evolucionan basados en su experiencia, para realizar una tarea determinada cada vez mejor. El objetivo principal de todo proceso de aprendizaje es utilizar la evidencia conocida para poder crear una hipótesis y poder dar una respuesta a nuevas situaciones no conocidas [57]. Hoy en día existen aplicaciones que utilizan agentes basados en aprendizaje en numerosas ramas de la industria y de la ciencia. Por ejemplo: Procesamiento del Lenguaje Natural: Para el análisis sintáctico y morfológico de los textos. Extracción de Información, Clasificación Automática de Documentos, Agrupamiento Semántico. Los modelos de Análisis de Sentimiento permiten reconocer la orientación o polaridad subjetiva de un texto, esto es, si están hablando bien o mal de aquello que se está opinando. Sistemas de Recuperación de Información: Los buscadores de Internet utilizan técnicas para mejorar la performance de sus búsquedas y confeccionar rankings personalizados según la experiencia de los usuarios. Luego, la minería de datos aplica la IA para encontrar patrones y relaciones dentro de los datos permitiendo la creación de modelos, es decir, representaciones abstractas de la realidad, pero es el descubrimiento del conocimiento el que se encarga de la preparación de los datos y la interpretación de los resultados obtenidos, los cuales dan un significado a estos patrones encontrados. Así el valor real de los datos reside en la información que se puede extraer de ellos, información que ayude a tomar decisiones o mejorar nuestra comprensión de los fenómenos que nos rodean. Además de la MD se tuvieron que elegir otras técnicas para resolver ciertos problemas como la distribución uniforme de productos, donde se decidió utilizar la Teoría de Utilidades y el Algoritmo de Bellman o la utilización del algoritmo de Greedy para introducir al proceso la noción de costo del producto, los cuales se irán desarrollando en la presente sección.
2.2 Técnicas y conceptos utilizados
2.2.1 Métodos estadísticos
La estadística puede definirse como un método de razonamiento que permite interpretar datos cuyo carácter esencial es la variabilidad. Está presente en la práctica médica cada vez con más frecuencia y en muy diversas formas, desde las estadísticas de actividad de un hospital o los resultados de auditorías, por ejemplo, hasta los hallazgos de estudios de investigación que aparecen en la literatura médica [20].
En investigación, la finalidad de la estadística es utilizar datos obtenidos en una muestra de sujetos para realizar inferencias válidas para una población más amplia de individuos de características similares. La validez y utilidad de estas inferencias dependen de cómo el estudio ha sido diseñado y ejecutado, por lo que la estadística debe considerarse como una parte integrante del método científico. Muchos profesionales creen que se trata simplemente de un conjunto de fórmulas y cálculos matemáticos que se aplican a un conjunto de datos.
Si bien el análisis de datos es la parte más visible de la estadística, deben tenerse en cuenta los aspectos metodológicos relacionados con el estudio. La justificación del análisis no radica en los datos, sino en la forma en que han sido recogidos.
16
Habitualmente se distingue entre estadística descriptiva, que comprende la organización, presentación y síntesis de datos de una manera científica, y estadística inferencial, que comprende las bases lógicas mediante las cuales se establecen conclusiones relacionadas con poblaciones a partir de los resultados obtenidos en muestras.
Las técnicas estadísticas pueden utilizarse para confirmar hipótesis de trabajo o bien para explorar conjuntos de datos sin hipótesis previas. Ambas finalidades, la confirmación y la exploración, están vinculadas a la naturaleza de los objetivos del estudio, a la actitud con que el investigador se enfrenta a los datos y a los términos en que deberán interpretarse los resultados.
Una hipótesis se confirma cuando se diseña un estudio con el propósito de hacerlo. Se explora cuando se rastrean datos en busca de información, sin objetivos concretos y formales que hayan gobernado el diseño del estudio. La exploración puede servir para sugerir nuevas hipótesis, pero de ningún modo para contrastarlas, sino que la confirmación deberá obtenerse en un nuevo estudio diseñado específicamente para ello.
2.2.2 Introducción a la Minería de datos
La minería de datos o exploración de datos es un campo de la estadística y las ciencias de la computación referido al proceso que intenta descubrir patrones en grandes volúmenes de conjuntos de datos. Utiliza los métodos de la inteligencia artificial, aprendizaje automático, estadística y sistemas de bases de datos.
Los datos almacenados son un tesoro para las organizaciones, es donde se guardan las interacciones pasadas con los clientes, la contabilidad de sus procesos internos, representan la memoria de la organización. Pero con tener memoria no es suficiente, hay que pasar a la acción inteligente sobre los datos para extraer la información que almacenan. [58].
El objetivo general del proceso de minería de datos consiste en extraer información de un conjunto de datos y transformarla en una estructura comprensible para su uso posterior. Además de la etapa de análisis en bruto, que involucra aspectos de bases de datos y de gestión de datos, de procesamiento de datos, del modelo y de las consideraciones de inferencia, de métricas de Intereses, de consideraciones de la Teoría de la complejidad computacional, de post-procesamiento de las estructuras descubiertas, de la visualización y de la actualización en línea [22].
El término es una palabra de moda, y es frecuentemente mal utilizado para referirse a cualquier forma de datos a gran escala o procesamiento de la información (recolección, extracción, almacenamiento, análisis y estadísticas), pero también se ha generalizado a cualquier tipo de sistema de apoyo informático decisión, incluyendo la inteligencia artificial, aprendizaje automático y la inteligencia empresarial. En el uso de la palabra, el término clave es el descubrimiento, comúnmente se define como "la detección de algo nuevo".
La tarea de minería de datos real es el análisis automático o semi-automático de grandes cantidades de datos para extraer patrones interesantes hasta ahora desconocidos, como los grupos de registros de datos (análisis clúster), registros poco usuales (la detección de anomalías) y dependencias (minería por reglas de asociación). Esto generalmente implica el uso de técnicas de bases de datos como los índices espaciales. Estos patrones pueden entonces ser vistos como una especie de resumen de los datos de entrada, y pueden ser utilizados en el análisis adicional o, por ejemplo, en la máquina de aprendizaje y análisis predictivo.
Dentro de las técnicas de MD destacan el Clustering, la Asociación, la Predicción, entre otras, los cuales se explicarán en apartados posteriores.
17
Figura 1: Esquema de la Minería de Datos
2.2.3 Inteligencia artificial
La inteligencia artificial es considerada una rama de la computación y relaciona un fenómeno natural con una analogía artificial a través de programas de computador. La inteligencia artificial puede ser tomada como ciencia si se enfoca hacia la elaboración de programas basados en comparaciones con la eficiencia del hombre, contribuyendo a un mayor entendimiento del conocimiento humano.
Si por otro lado es tomada como ingeniería, basada en una relación deseable de entrada-salida para sintetizar un programa de computador. "El resultado es un programa de alta eficiencia que funciona como una poderosa herramienta para quien la utiliza."
A través de la inteligencia artificial se han desarrollado los sistemas expertos que pueden imitar la capacidad mental del hombre y relacionan reglas de sintaxis del lenguaje hablado y escrito sobre la base de la experiencia, para luego hacer juicios acerca de un problema, cuya solución se logra con mejores juicios y más rápidamente que el ser humano [25].
18
Figura 2: Aplicaciones de la I.A
2.2.4 Proceso KDD
La Extracción de conocimiento está principalmente relacionado con el proceso
de descubrimiento conocido como Knowledge Discovery in Databases (KDD), que se refiere al proceso no-trivial de descubrir conocimiento e información potencialmente útil dentro de los datos contenidos en algún repositorio de información. No es un proceso automático, es un proceso iterativo que exhaustivamente explora volúmenes muy grandes de datos para determinar relaciones. Es un proceso que extrae información de calidad que puede usarse para dibujar conclusiones basadas en relaciones o modelos dentro de los datos [28]. La siguiente figura ilustra las etapas del proceso KDD:
19
Figura 3: Etapas del Proceso KDD
Como muestra la figura 3, las etapas del proceso KDD se dividen en 5 fases y son:
- Selección de datos. En esta etapa se determinan las fuentes de datos y el tipo de información a utilizar. Es la etapa donde los datos relevantes para el análisis son extraídos desde la o las fuentes de datos.
- Pre procesamiento. Esta etapa consiste en la preparación y limpieza de los datos extraídos desde las distintas fuentes de datos en una forma manejable, necesaria para las fases posteriores. En esta etapa se utilizan diversas estrategias para manejar datos faltantes o en blanco, datos inconsistentes o que están fuera de rango, obteniéndose al final una estructura de datos adecuada para su posterior transformación.
- Transformación. Consiste en el tratamiento preliminar de los datos, transformación y generación de nuevas variables a partir de las ya existentes con una estructura de datos apropiada. Aquí se realizan operaciones de agregación o normalización, consolidando los datos de una forma necesaria para la fase siguiente.
- Data Mining. Es la fase de modelamiento propiamente tal, en donde métodos inteligentes son aplicados con el objetivo de extraer patrones previamente desconocidos, válidos, nuevos, potencialmente útiles y comprensibles y que están contenidos u “ocultos” en los datos.
- Interpretación y Evaluación. Se identifican los patrones obtenidos y que son realmente interesantes, basándose en algunas medidas y se realiza una evaluación de los resultados obtenidos.
Además de las fases descritas, frecuentemente se incluye una fase previa de análisis de las necesidades de la organización y definición del problema, en la que se establecen los objetivos de la minería de datos. También es usual incluir una etapa final, donde los resultados obtenidos se integran al negocio para la realización de acciones comerciales.
20
2.3 Minería de Datos
2.3.1 Breve Historia de la Minería de Datos
Aunque desde un punto de vista académico el término data mining es una etapa dentro de un proceso mayor llamado extracción de conocimiento en bases de datos, en el entorno comercial, así como en este trabajo, ambos términos se usan de manera indistinta. Lo que en verdad hace el data mining es reunir las ventajas de varias áreas como la Estadística, la Inteligencia Artificial, la Computación Gráfica, las Bases de Datos y el Procesamiento Masivo, principalmente usando como materia prima las bases de datos [32].
Una definición tradicional es la siguiente: Un proceso no trivial de identificación válida, novedosa, potencialmente útil y entendible de patrones comprensibles que se encuentran ocultos en los datos. Desde el punto de vista empresarial, lo definimos como: La integración de un conjunto de áreas que tienen como propósito la identificación de un conocimiento obtenido a partir de las bases de datos que aporten un sesgo hacia la toma de decisión.
La idea de data mining no es nueva. Ya desde los años sesenta los estadísticos manejaban términos como data fishing, data mining o data archaeology con la idea de encontrar correlaciones sin una hipótesis previa en bases de datos con ruido.
Las listas de discusión sobre este tema las forman investigadores de más de ochenta países. Esta tecnología ha sido un buen punto de encuentro entre personas pertenecientes al ámbito académico y al de los negocios.
El data mining es una tecnología compuesta por etapas que integra varias áreas y que no se debe confundir con un gran software. Durante el desarrollo de un proyecto de este tipo se usan diferentes aplicaciones software en cada etapa que pueden ser estadísticas, de visualización de datos o de inteligencia artificial, principalmente. Actualmente existen aplicaciones o herramientas comerciales de data mining muy poderosas que contienen un sinfín de utilerías que facilitan el desarrollo de un proyecto. Sin embargo, casi siempre acaban complementándose con otra herramienta.
La data mining es la etapa de descubrimiento en el proceso de KDD: Paso consistente en el uso de algoritmos concretos que generan una enumeración de patrones a partir de los datos pre procesados. Aunque se suelen usar indistintamente los términos KDD y Minería de Datos.
2.3.2 Conceptos asociados a la Minería de datos
La MD se encarga de buscar relaciones y patrones entre toda la cantidad de información disponible.
Un patrón, es algo que se repite, una tendencia, como una representación de los datos e información obtenidos de una fuente de información, como puede ser una BD. Un patrón debe ser interesante desde el punto de vista del tema que se está tratando. Trivial, aportando alguna clase de conocimiento útil sobre lo que se está analizando. También debe ser, nuevo y desconocido, así también como comprensible, patrones difíciles de entender no nos son de gran utilidad.
Para obtener estos patrones y poder conseguir información relevante y de utilidad, la MD dispone de varios métodos y algoritmos.
Los dos caminos principales de la MD son la predicción y a la descripción. Para ambos existen una variedad de métodos que se pueden utilizar con el fin de descubrir conocimiento [34-38].
21
2.3.3 Técnicas más utilizadas en la Minería de Datos
A continuación se detallan brevemente las técnicas que se usan más frecuentemente en la minería de datos: REDES NEURONALES: Esta técnica de inteligencia artificial, en los últimos años se ha convertido en uno de los instrumentos de uso frecuente para detectar categorías comunes en los datos, debido a que son capaces de detectar y aprender complejos patrones, y características de los datos. Una de las principales características de las redes neuronales, es que son capaces de trabajar con datos incompletos e incluso paradójicos, que dependiendo del problema puede resultar una ventaja o un inconveniente. Además esta técnica posee dos formas de aprendizaje: supervisado y no supervisado.
ÁRBOLES DE DECISIÓN: Esta técnica se encuentra dentro de una metodología de aprendizaje supervisado. Su representación es en forma de árbol en donde cada nodo es una decisión, los cuales a su vez generan reglas para la clasificación de un conjunto de datos.
Los árboles de decisión son fáciles de usar, admiten atributos discretos y continuos, tratan bien los atributos no significativos y los valores faltantes. Su principal ventaja es la facilidad de interpretación.
ALGORITMOS GENÉTICOS: Los algoritmos genéticos imitan la evolución de
las especies mediante la mutación, reproducción y selección, como también proporcionan programas y optimizaciones que pueden ser usadas en la construcción y entrenamiento de otras estructuras como es el caso de las redes neuronales. Además los algoritmos genéticos son inspirados en el principio de la supervivencia de los más aptos. CLUSTERING (Agrupamiento): Agrupan datos dentro de un número de clases preestablecidas o no, partiendo de criterios de distancia o similitud, de manera que las clases sean similares entre sí y distintas con las otras clases. Su utilización ha proporcionado significativos resultados en lo que respecta a los clasificadores o reconocedores de patrones, como en el modelado de sistemas. Este método debido a su naturaleza flexible se puede combinar fácilmente con otro tipo de técnica de minería de datos, dando como resultado un sistema híbrido.
Un problema relacionado con el análisis de cluster es la selección de factores en tareas de clasificación, debido a que no todas las variables tienen la misma importancia a la hora de agrupar los objetos. Otro problema de gran importancia y que actualmente despierta un gran interés es la fusión de conocimiento, ya que existen múltiples fuentes de información sobre un mismo tema, los cuales no utilizan una categorización homogénea de los objetos. Para poder solucionar estos inconvenientes es necesario fusionar la información a la hora de recopilar, comparar o resumir los datos.
2.4 Weka
2.4.1 Introducción
Weka es un software programado en Java que está orientado a la extracción de conocimientos desde bases de datos con grandes cantidades de información. Para ello únicamente se requiere que los datos a analizar se almacenen con un cierto formato, conocido como ARFF (Attribute-Relation File Format).
22
WEKA se distribuye como software de libre distribución desarrollado en Java. Está constituido por una serie de paquetes de código abierto con diferentes técnicas de pre procesado, clasificación, agrupamiento, asociación, y visualización, así como facilidades para su aplicación y análisis de prestaciones cuando son aplicadas a los datos de entrada seleccionados.
2.4.2 Por qué seleccionar la herramienta Weka?
Es un entorno para experimentación de análisis de datos que permite aplicar,
analizar y evaluar las técnicas más relevantes de análisis de datos, principalmente las provenientes del aprendizaje automático, sobre cualquier conjunto de datos del usuario.
Para ello únicamente se requiere que los datos a analizar se almacenen con un cierto formato, conocido como ARFF (Attribute-Relation File Format).
Por ejemplo, la concesión de créditos bancarios en el momento que vivimos es un tema bastante complicado. La crisis económica que se está viviendo en estos momentos obliga a los bancos a ser muchos más estrictos a la hora de conceder un préstamo/crédito a sus clientes. Se ha intentado, a partir de ciertos estudios y usando distintas metodologías, identificar las probabilidades que tiene un cliente de devolver un crédito de acuerdo con los datos de los que se dispone de él.
Se trata de un software específicamente diseñado y utilizado para investigación y fines educativos. Esta característica es importante para un proyecto de investigación como este.
Weka es un conjunto de librerías java para la extracción de conocimientos desde BD. Es un software que ha sido desarrollado bajo licencia GPL lo cual ha impulsado que sea una de las suites más utilizadas en el área en los últimos años. Una de las propiedades más interesantes de este software, es su facilidad para añadir extensiones, modificar métodos, entre otros.
Se ha definido que Weka es la más conveniente para el trabajo que se quiere realizar. Principalmente porque el software es de tipo Open-Source con licencia GNU GPL, basado en java. Además es multiplataforma, pues se puede ejecutar en Windows y Linux. Weka es una de las herramientas más sencillas y abarca todas las características necesarias para desarrollar el proyecto.
Es una herramienta flexible para aprender y explorar la MD, la interfaz gráfica de usuario tiene como objetivo simplificar el uso para las tareas complejas de esta área. Se puede utilizar desde la línea de comandos, desde una interfaz de usuario o creando un programa Java, lo cual permite utilizar todas las funcionalidades disponibles en las distintas interfaces gráficas. Esta última característica fue fundamental para poder incluir Weka a la Aplicación Web que se pretendía desarrollar.
Además, todas las técnicas de Weka se fundamentan en la asunción de que los datos están disponibles en un fichero plano, en la que cada registro de datos está descrito por un número fijo de atributos (normalmente numéricos o nominales, aunque también se soportan otros tipos). Weka también proporciona acceso a BD vía SQL gracias a la conexión JDBC (Java Database Connectivity) y puede procesar el resultado devuelto por una consulta hecha a la BD [29-30].
WEKA permite realizar manipulaciones sobre los datos aplicando filtros. Se pueden aplicar en dos niveles: atributos e instancias. Además las operaciones de filtrado pueden aplicarse en cascada, de forma que la entrada de cada filtro es la salida de haber aplicado el anterior filtro.
La máquina de aprendizaje WEKA proporciona un entorno con algoritmos de pre-procesamiento de datos, la función de selección, clasificación, regresión y la agrupación. Ellos se complementan con las interfaces gráficas de usuario para la entrada de datos y modos de exploración.
23
Una característica importante de WEKA es la interfaz uniforme Java para todos sus algoritmos. Se organizan en paquetes y cuando se agrega el weka.jar a un proyecto independiente, sólo se necesita la importación con el fin de conseguir el acceso a cualquier funcionalidad de WEKA.
2.5 Técnicas de Optimización de recursos
2.5.1 Programación dinámica (PD)
La programación dinámica es un enfoque general para la solución de
problemas en los que es necesario tomar decisiones en etapas sucesivas. Las decisiones tomadas en una etapa condicionan la evolución futura del sistema, afectando a las situaciones en las que el sistema se encontrará en el futuro (denominadas estados), y a las decisiones que se plantearán en el futuro.
Conviene resaltar que a diferencia de la programación lineal, el modelado de problemas de programación dinámica no sigue una forma estándar. Así, para cada problema será necesario especificar cada uno de los componentes que caracterizan un problema de programación dinámica.
El procedimiento general de resolución de estas situaciones se divide en el análisis recursivo de cada una de las etapas del problema, en orden inverso, es decir comenzando por la última y pasando en cada iteración a la etapa antecesora. El análisis de la primera etapa finaliza con la obtención del óptimo del problema. Frecuentemente para resolver un problema complejo se tiende a dividir este en subproblemas más pequeños, resolver estos últimos (recurriendo posiblemente a nuevas subdivisiones) y combinar las soluciones obtenidas para calcular la solución del problema inicial. Puede ocurrir que la división natural del problema conduzca a un gran número de sub-ejemplares idénticos. Si se resuelve cada uno de ellos sin tener en cuenta las posibles repeticiones, resulta un algoritmo ineficiente; en cambio, si se resuelve cada ejemplar distinto una sola vez y se conserva el resultado, el algoritmo obtenido es mucho mejor.
La idea de la PD es no calcular dos veces lo mismo y utilizar normalmente una tabla de resultados que se va rellenando a medida que se resuelven los sub-ejemplares. La PD es un método ascendente. Se resuelven primero los sub-ejemplares más pequeños y por tanto más simples. Combinando las soluciones se obtienen los resultados de ejemplares sucesivamente más grandes hasta llegar al ejemplar original [18]. Está basada en el principio de optimalidad de Bellman, que dice así: "Una política óptima tiene la propiedad de que, sin importar las decisiones previas que se han tomado, el resto de las decisiones deben constituir una política óptima independientemente del estado resultante de las decisiones previas." [19]
24
Figura 4: Usos y tipos de Programación Dinámica
2.5.2 Teoría de utilidades
El término utilidad fue mencionado por primera vez por el filósofo Jeremy Bentham, menciona la existencia de conformidad o inconformidad de complacer el deseo del individuo provocando felicidad o desilusión conforme a su interés. Así podemos decir que “la utilidad es la variable cuya magnitud relativa indica la dirección de la preferencia. Al encontrar la posición que más se prefiera, se dice que el individuo maximiza su utilidad” [41].
Existen diferentes tipos de elecciones las cuales nos dan la posibilidad de optar por la alternativa que nos maximice nuestra utilidad al máximo. Estas preferencias se pueden dividir en alternativas sin riesgo, que es en la que el individuo sabe a la perfección lo que obtendrá, y las alternativas inciertas que son aquellas en las que el individuo corre un riesgo ya que no sabe lo que obtendrán este tipo de preferencias usualmente se presenta en la lotería.
El presente trabajo trata la alternativa sin riesgo (adaptación de la escala de Glasgow [60]), dado que la decisión del valor de utilidad de cada beneficiario con respecto a las diferentes cantidades de productos es influyente en el resultado de asignación.
Puede hacerse una escala subjetiva de valores para presentar cuánto valor atribuye una persona a recibir una cierta cantidad de un producto. Por ejemplo:
Excelente: 15. Muy bueno: 13. Mejor que un término medio: 11. Un término medio: 9. Peor que el término medio: 7. Regular: 5. Malo: 3. Muy malo: 1. Para el caso en donde el valor de la utilidad para un producto en particular sea
cero (0) para todos los beneficiarios, se repartirán los recursos existentes equitativamente en caso que exista un número de recursos a asignar superior a la
25
cantidad de beneficiarios y al azar en caso que los recursos a asignar sea menor a la cantidad de beneficiarios existentes. Con esto se logra que el reparto de productos se haga en cualquier caso, de manera que no queden productos en stock sin ser entregados.
2.6 Greedy
La técnica de diseño de algoritmos denominada Greedy (algoritmos voraces)
es aquella que va construyendo la solución de un problema a partir de decisiones parciales tomadas en base a la información disponible en cada momento.
No mira hacia adelante, es decir, no ve los efectos de las decisiones tomadas a futuro y nunca reconsidera una decisión ya tomada.
Esta técnica es utilizada en general para resolver problemas de optimización. Suelen ser muy eficientes pero su eficacia debe ser validada, o sea, debe tenerse mucho cuidado con su correctitud. Esto quiere decir que se debe demostrar que la solución encontrada es óptima [39].
Figura 5: Representación del Algoritmo de Greedy
Se basa en un conjunto de candidatos a formar parte de la solución. En cada paso se toma uno de los candidatos, el más apropiado y se evalúa si sirve o no. Si sirve, el candidato es agregado a la solución, caso contrario es descartado. Para ello, es necesario saber en todo momento, dado un candidato, si el mismo está pendiente de ser evaluado, si ya fue evaluado y agregado a la solución o si fue descartado.
Para cumplir con esto deben conocerse cuatro funciones:
- La función selección, que es la que selecciona el mejor candidato dentro de los pendientes.
- La función factibilidad, que evalúa si un candidato seleccionado es factible de formar parte de la solución.
- La función solución, que evalúa si un conjunto solución propuesto conforma la solución al problema.
- La función objetivo, que es la que se debe maximizar o minimizar (optimizar).
Resumiendo, los algoritmos ávidos construyen la solución en etapas sucesivas, tratando siempre de tomar la decisión óptima para cada etapa.
26
Capítulo 3: Herramienta de soporte para la toma de decisiones
3.1 Introducción
En este capítulo se detalla la solución propuesta a la problemática descripta. En la Sección 3.1 se introduce al lector sobre temas generales, los cuales
abarcan desde conceptos tecnológicos hasta algunas de las pautas de usabilidad empleadas.
El proyecto se divide en dos partes. Una aplicación que se ubica del lado del cliente (Sección 3.2) y un servidor encargado de realizar el procesamiento de la información, accesos a la BD, etc. (Sección 3.3).
Para cada uno de los componentes que intervienen, se describe el diseño de interacción, así como las características más importantes de su arquitectura y las tecnologías empleadas en su implementación.
3.1.1 Tecnología Utilizada
La herramienta se desarrolló como una Aplicación Web. Esta decisión se tomó
al considerar que la Asociación Civil Proyecto Koinonia se encuentra desarrollando aplicaciones Web y a las ventajas asociadas a este tipo de aplicación.
Ventajas de las Aplicaciones Web:
• Compatibilidad multiplataforma. Las aplicaciones web tienen un camino mucho más sencillo para la compatibilidad multiplataforma que las aplicaciones de software descargables.
• Actualización. Las aplicaciones basadas en web están siempre actualizadas con el último lanzamiento.
• Inmediatez de acceso. Las aplicaciones basadas en web no necesitan ser descargadas, instaladas y configuradas. Se accede a la cuenta online a trabajar sin importar cuál es su configuración o su hardware.
• Menos requerimientos de memoria. Las aplicaciones basadas en web tienen muchas más razonables demandas de memoria RAM de parte del usuario final que los programas instalados localmente.
• Menos Bugs. Las aplicaciones basadas en web deberán ser menos propensas a colgarse y crear problemas técnicos debido a software o conflictos de hardware con otras aplicaciones existentes, protocolos o software personal interno. Con aplicaciones basadas en web, todos utilizan la misma versión, y todos los bugs pueden ser corregidos tan pronto como son descubiertos.
• Múltiples usuarios concurrentes. Las aplicaciones basadas en web pueden realmente ser utilizada por múltiples usuarios al mismo tiempo.
27
Figura 6: Arquitectura cliente-servidor utilizada en el diseño de la solución propuesta. El usuario interactúa con el cliente, mientras que el procesamiento de los datos es llevado a cabo en el servidor.
3.1.2 Arquitectura
Se eligió desarrollar una Aplicación Web utilizando una arquitectura cliente-servidor (figura 7).
La arquitectura cliente - servidor es una arquitectura de computación en la que se consigue un procesamiento cooperativo de la información por medio de un conjunto de procesadores, de tal forma que uno o varios clientes, distribuidos geográficamente o no, solicitan servicios de computación a uno o más servidores [43].
De esta forma, y gracias a esta arquitectura, la totalidad de los procesadores, clientes y servidores, trabajan de forma cooperativa para realizar un determinado tratamiento de la información.
Atendiendo a esta visión descentralizada, la arquitectura cliente - servidor consiste en una arquitectura distribuida de computación, en la que las tareas de cómputo se reparten entre distintos procesadores, obteniendo los usuarios finales el resultado final de forma transparente, con independencia del número de equipos (servidores) que han intervenido en el tratamiento. Se puede decir por tanto que la arquitectura cliente - servidor es un tipo de arquitectura distribuida, posiblemente la más extendida.
El Esquema de funcionamiento de un Sistema Cliente/Servidor sería:
. El cliente solicita una información al servidor.
. El servidor recibe la petición del cliente.
. El servidor procesa dicha solicitud.
. El servidor envía el resultado obtenido al cliente.
. El cliente recibe el resultado y lo procesa.
El modelo Cliente/Servidor es un modelo basado en la idea del servicio, en el que el cliente es un proceso consumidor de servicios y el servidor es un proceso proveedor de servicios. Además esta relación está establecida en función del intercambio de mensajes que es el único elemento de acoplamiento entre ambos.
De estas líneas se deducen los tres elementos fundamentales sobre los cuales se desarrollan e implantan los sistemas Cliente/Servidor: el proceso cliente que es quien inicia el diálogo, el proceso servidor que pasivamente espera a que lleguen peticiones de servicio y el middleware que corresponde a la interfaz que provee la conectividad entre el cliente y el servidor para poder intercambiar mensajes.
Para entender en forma más ordenada y clara los conceptos y elementos involucrados en esta tecnología se puede aplicar una descomposición o arquitectura
28
de niveles. Esta descomposición principalmente consiste en separar los elementos estructurales de esta tecnología en función de aspectos más funcionales de la misma:
Nivel de Presentación: Agrupa a todos los elementos asociados al componente Cliente.
Nivel de Aplicación: Agrupa a todos los elementos asociados al componente Servidor.
Nivel de comunicación: Agrupa a todos los elementos que hacen posible la comunicación entre los componentes Cliente y servidor.
Nivel de base de datos: Agrupa a todas las actividades asociadas al acceso de los datos.
Figura 7: Arquitectura cliente-servidor
(a) Estructura de navegación web - Jerarquía (b) Componentes del Servidor
3.1.2.1 Arquitectura Interna del Cliente
En la Aplicación Web desarrollada en el presente trabajo, el cliente accede a
una API REST. El diseño del mismo responde a una arquitectura MVC (Model View Controller) y está basado en los paradigmas de la programación guiada por eventos para la interacción entre los diferentes componentes del sistema y la comunicación entre la interfaz con los diferentes controladores (Figura 8).
29
Figura 8: Arquitectura MVC dentro del Cliente
El motivo de la elección de API REST fue debido a los siguientes puntos:
1. separación cliente/servidor
Al ser sistemas independientes (solo se comunican con un lenguaje de intercambio como JSON) puedes desarrollarlos proyectos autónomos, equipos autónomos. Al cliente le da igual cómo está hecha la API y al servidor le da igual qué vas a hacer con los datos que te ha proporcionado.
Si necesitas evolucionar/refactorizar uno de los dos, back o front, se puede hacer de manera separada, siempre que se mantenga la interfaz del API.
Se pueden hacer varios front con un único backend (frontal no tiene porqué ser solo web, puede ser un app para Android otro para un App iOS, etc.)
En este sentido otra ventaja importantísima es la posibilidad de crear tantos frontales como necesites con la misma API. Se puede comenzar desarrollando una web, pero con la misma API se puede desarrollar también una aplicación para iOS 2. Independencia de tecnologías / lenguajes
Es posible desarrollar en cualquier tipo de tecnología o lenguaje que se prefiera. Es indiferente que en el futuro se cambie totalmente las tecnologías con las que está implementado el API REST, siempre y cuando se respete "el contrato", o sea, que se siga teniendo las mismas operaciones en el API y hagan las mismas cosas que se supone que deben hacer.
3. Fiabilidad, escalabilidad, flexibilidad
Sólo hay que preocuparse que el nexo cliente / servidor esté correcto. Se pueden hacer cambios en el servidor, lenguajes, bases de datos, etc. y mientras se devuelvan los datos necesarios, todo irá correctamente.
Escalabilidad porque se puede crecer todo lo que se necesite en cada momento. El API puede responder a otros tipos de operaciones o puede versionarse tanto como se desee.
4. Experiencia de usuario
Aunque eso depende más de cómo está hecha la parte del cliente, teóricamente el desarrollo de sitios web basados en un API puede dar mejor
30
desempeño que uno tradicional. Cuando haces una solicitud al servidor lo que tienes como respuesta son datos planos, que requieren tiempos de transferencia menores que si esos mismos datos los recibieras mezclados con el HTML/CSS de la presentación.
En este tipo de aplicaciones web no se necesita recargar la página, aunque esto no es una ventaja específica del desarrollo basado en REST, sino del uso de Ajax en general, con el que podemos conseguir aplicaciones web que se asemejan más a aplicaciones de escritorio.
Por otra parte, la primera razón por la que se escogió utilizar MVC, es la facilidad que nos aporta a nosotros, como desarrolladores que somos, administrar una aplicación web compleja teniéndola dividida en tres pilares fundamentales (modelo, vista, controlador, como ya comentamos antes).
La segunda ventaja es el uso de un “FrontController” que procesa todas las solicitudes a nuestra aplicación. Esto permite diseñar una infraestructura con un sistema de enrutamiento avanzado.
Otra ventaja también muy importante es su funcionamiento para aplicaciones web en las que trabajan grandes equipos formados por desarrolladores y diseñadores. Al tener la vista completamente separada de la lógica, unos no “interfieren” en las tareas de los otros.
Además, un Framework MVC te ayuda a controlar los recursos del servidor, evitando Bugs que puedan repercutir en el rendimiento, por ejemplo, muchas veces olvidamos cerrar conexiones a la base de datos, sobrecargando el servidor.
Frente a los WebForms, MVC tiene un par de ventajas, la primera de ellas es que no utiliza formularios de servidor con lo cual el desarrollador tiene mucho mayor control sobre la aplicación, la otra ventaja es que tampoco utiliza los “ViewState”, consiguiendo así ahorrar notablemente en el ancho de banda consumido.
3.2 Aplicación Web En esta sección se describen los requerimientos funcionales y no funcionales
de la aplicación. Se introduce al lector en la tecnología utilizada, para luego presentar en detalle el diseño y la implementación de los componentes principales y los subcomponentes que conforman la aplicación web.
3.2.1 Requerimientos
A nivel funcional, la Aplicación Web debe: Permitir al usuario loguearse en el sistema para ingresar al mismo. De esta
manera, sólo podrán acceder los usuarios registrados. Como se mencionó antes, varios usuarios al mismo tiempo podrán hacer uso de la Aplicación, lo que le aporta la característica de Multiusuario.
Permitir al usuario ingresar un mes y un monto para llevar a cabo una predicción.
Visualizar en una tabla el resultado de la predicción. Permitir agregar, editar o eliminar mapeos característica-productos. Este
mapeo hace referencia a qué productos se asocian con alguna característica en particular. Por ejemplo, si una característica es hipertenso, los productos asociados podrían ser galletas sin sal y pan sin sal.
Permitir agregar, editar o eliminar los precios de los productos. Permitir al usuario iniciar el proceso de análisis de datos cuando lo requiera y
seguir con otra tarea sin que la primera sea bloqueante. El iniciar análisis se mejora. En cualquier momento que quiera el usuario, con el botón correspondiente, puede iniciar un nuevo análisis. También, queda guardado en la base de datos el estado de
31
la última predicción. Por eso, al iniciar la aplicación, no se inicia más el análisis y permite enseguida empezar a predecir, asignar, ver reportes, etc.
Permitir al usuario elegir un producto e ingresar la cantidad disponible en stock para hacer una asignación. Fue necesario que los combos que aparecen en las pantallas se llenen mediante llamadas a servicios y que no sean estáticos. De esta manera, al ir agregando o eliminando productos o beneficiarios, los combos siempre reflejarán los datos correctos.
Visualizar en una tabla cómo se distribuyen los productos para hacer una asignación.
Permitir al usuario obtener un reporte del conjunto de productos que deberán entregar a los beneficiarios.
Visualizar en una tabla los productos que se le dará al beneficiario elegido. Permitir la importación del resultado de una asignación hacia la tabla de
histórico de productos para que la misma se re-alimente automáticamente. Permitir que una característica de una familia sea multivaluada (Por ejemplo,
un hipertenso puede necesitar varios alimentos y no sólo uno). Se tuvieron en cuenta las características multivaluadas. Esto es con respecto a los productos que se corresponden con las mismas y no un único producto. Con esto, se agranda el abanico de productos que puede recibir un beneficiario que posee una característica determinada.
También, se desea tener la posibilidad de exportar los resultados de una asignación determinada, ya sea para un beneficiario particular o para todos los beneficiarios. Las planillas exportadas sirven de ayuda para cualquier revisión o análisis que se desee hacer por fuera del sistema.
Borrar historial para realizar una nueva asignación. Una vez que se hayan realizado todos los reportes, se deberá eliminar el historial de asignaciones para que los datos existentes no interfieran en futuras asignaciones de recursos.
Contar con un mecanismo que, si se desea, permita la inclusión en la base de datos cualquier información relacionada con la fecha y cantidades de un producto determinado que haya sido donado. Este mecanismo tiene que estar presente en la interfaz para que sea transparente y útil de manera que no haya que ingresar a las tablas de la base de datos y cargarlos manualmente.
Emitir un error ante cualquier procedimiento mal hecho para que el usuario pueda revisar las causas del problema y solucionarlo.
Se tuvo la necesidad de que, si hay productos que no fueron solicitados por ningún beneficiario, los mismos se repartan de todas maneras. El mecanismo elegido es repartir equitativamente dicho producto entre todos los beneficiarios. Con esto se logra que, ante la existencia de productos que nadie solicitó, los mismos se entreguen y no queden el stock, lo que podría provocar que los productos se venzan.
A nivel no funcional: Su uso debe ser agradable para los usuarios. Ser accesible, el usuario puede acceder a cualquiera de las pantallas a través
de la web principal. Ser visualizado y funcionar correctamente en distintos navegadores. El tiempo de respuesta debe ser aceptable para el usuario. Es decir, el usuario
no debe percibir el tiempo que pasa entre que se solicita algo y se visualiza la respuesta.
No se tiene que modificar el código de la aplicación cuando se la instale a otra organización.
Su código debe ser libre.
32
3.2.2 Implementación e Integración
Teniendo en cuenta que se optó por realizar una aplicación web, a
continuación se procede a detallar las diferentes tecnologías utilizadas. En primer lugar, se definió la tecnología y lenguaje de implementación
utilizados por el cliente. De las alternativas que se pueden seleccionar existen un conjunto de estándares web, definidos por el W3C (World wide Web Consortium 1), que todo navegador debe implementar, y también existe un conjunto de tecnologías no estándar para la construcción de aplicaciones. El desarrollo de la aplicación se realiza en HTML5 por ser un lenguaje nativo y estándar para la generación de páginas web. HTML5 es el último estándar del lenguaje de hipertexto HTML, el cual en realidad es una familia de tecnologías:
HTML: es el lenguaje de modelado semántico que permite estructurar la información en secciones, párrafos, título, imágenes y otras etiquetas.
JavaScript: es el lenguaje de programación que permite agregar interactividad. CSS: es el lenguaje que le da estilos al diseño gráfico de HTML, el cual permite
agregarle estética y capacidad visual (colores, tipos de letras, fondos, efectos, etc). En comparación, las otras alternativas descartadas fueron: Adobe Flash (no estándar) - Es una tecnología utilizada principalmente para
generar contenido multimedia interactivo en las páginas web. Es una tecnología cerrada, propietaria (gratis para los usuarios, pero algunas características de desarrollo son pagas) y además es considerada ineficiente. Para la ejecución de los desarrollos en esta tecnología es necesario tener descargado Flash Player (complemento de flash para el navegador).
Applets de Java (no estándar) - Los applets de Java fueron los precursores de Flash. Su performance suele ser más baja. Hace varios años que esta tecnología se encuentra en desuso.
Microsoft Silverlight (no estándar) - Esta tecnología surgió como la alternativa competitiva de Microsoft a Adobe Flash. Posee un soporte muy limitado en plataformas diferentes a Windows.
Por otra parte, fue necesario definir la estructura de la aplicación. Para ello, existen múltiples frameworks de alto nivel que estructuran una aplicación web de forma completa. Los tres más populares al momento de comenzar el desarrollo son: Angular.js, Backbone.js y Ember.js. Estos son de código abierto, están basados en JavaScript y se utilizan para el desarrollo de aplicaciones web ’single page’ utilizando el patrón de diseño MV* (Modelo-vista-*). Todos poseen componentes que representan vista, eventos, modelos de datos y enrutamiento. A continuación se presentan algunas de las principales diferencias que poseen:
Backbone.js es ligero y no ocupa mucho espacio, tiene una excelente documentación, su código es simple y además posee una única dependencia (para su funcionamiento sólo es necesario incorporar la librería de utilidades Underscore.js). Posee una curva de aprendizaje muy chica (si se posee algo de experiencia con jQuery y Unhderscore.js), debido a que no existe mucha diferencia entre desarrollar en JavaScript con y sin la utilización del framework.
Angular.js posee una enorme popularidad, es el framework de JavaScript que gana si se compara el tamaño de la comunidad de usuarios que lo utilizan, y conforme mayor sea el tamaño de ésta es más fácil encontrar ejemplos y ayuda para desarrollar con él. Por otro lado, posee una curva de aprendizaje algo abrupta y muchos de sus conceptos claves (como directivas o servicios) no poseen una explicación clara y sencilla de entender para usuarios con poca experiencia. La documentación oficial es poco clara y además está orientada a usuarios experimentados en la herramienta.
Ember.js funciona bajo el principio de Convention over Configuration (convenciones de nombres en lugar de configuraciones), lo que permite al framework
33
asumir de forma automática muchas tareas que en otros tienen que ser desarrolladas por el programador. Como consecuencia directa de esto, el framework posee una estructura muy rígida. Es necesario aprender cómo funciona internamente el framework (o al menos una parte del mismo) antes de poder empezar a trabajar con él.
Se escogió utilizar Angular.js ya que al comenzar el proyecto se poseía experiencia previa y esto aceleraría el desarrollo.
Además, se utilizaron otras tecnologías durante el desarrollo de la aplicación web.
Se utilizan peticiones AJAX, que es una técnica de desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor (en formato JSON) en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, mejorando la interactividad, velocidad y usabilidad en las aplicaciones.
En cuanto a manejo de CSS, se utiliza Bootstrap, una librería desarrollada por Twitter que simplifica el proceso de creación de diseños Webs (maquetado).
El entorno de desarrollo utilizado fue el editor de texto Sublime Text 2, que es un editor de texto y editor de código fuente. Se puede descargar y evaluar de forma gratuita.
Para realizar el control de versiones se utilizó GIT, un sistema de control de versiones distribuido de código abierto, en conjunto con Github el cual es un servicio para alojamiento de repositorios de software gestionados por el sistema de control de versiones Git.
Por último, para organizar todas estas herramientas se utiliza Bower y Grunt en conjunto con npm. Bower es un gestor de paquetes para desarrollo web en el lado del cliente el cual funciona con Git y utiliza además repositorios de GitHub. Por otro lado, Grunt permite configurar tareas automáticas y gestionar dependencias entre otras funcionalidades.
Así, es posible ahorrar tiempo durante el desarrollo y despliegue de aplicación web.
Este FrontEnd puede compilar en un WAR (Web Application Archive) separado del BackEnd o los dos pueden formar un único WAR.
A continuación se explicarán con más detalle las tecnologías utilizadas:
3.2.2.1 HTML
Cuando se mira una página web en el navegador, lo que se ve a simple vista
son palabras. Estas palabras normalmente tienen algunas características, como diferentes tamaños y colores. En algunos casos la página web puede mostrar imágenes o incluso vídeos. Otras veces, formularios donde puedes introducir o buscar información, o personalizar la apariencia de la página que estás viendo. La página también puede contener animaciones y contenidos que cambian mientras el resto de la página se mantiene sin cambios.
Varias tecnologías (como CSS, JavaScript, Flash, AJAX, JSON) pueden usarse para definir los elementos que componen una página web. Sin embargo, en el nivel más bajo, una página web se define usando HTML (HyperText Markup Language). Sin HTML, no habría páginas web.
HTML es un lenguaje de etiquetas [4]. Indica al navegador como tiene que mostrar el contenido. El HTML separa el "contenido" (palabras, imágenes, audio, video, etc.) de la "presentación" (la definición del tipo de contenido y las instrucciones de cómo esos contenidos tienen que mostrarse). El HTML emplea un conjunto de elementos predefinidos que permiten identificar los distintos tipos de elementos. Estos elementos contienen una o más etiquetas que contienen o expresan el contenido.
Estas etiquetas suelen ir encapsuladas entre los símbolos <>, y las etiquetas de cierre (que indican el final de un determinado contenido) están precedidas por una barra /.
3.2.2.2 CSS
CSS es un lenguaje de hojas de estilos creado para controlar el aspecto o
presentación de los documentos electrónicos definidos con HTML y XHTML [6]. CSS es la mejor forma de separar los contenidos y su presentación y es imprescindible para crear páginas web complejas.
Separar la definición de los contenidos y la definición de su aspecto presenta numerosas ventajas, ya que obliga a crear documentos HTML/XHTML bien definidos y con significado completo (también llamados "documentos semánticos"). Además, mejora la accesibilidad del documento, reduce la complejidad de su mantenimiento y permite visualizar el mismo documento en infinidad de dispositivos diferentes.
Al crear una página web, se utiliza en primer lugar el lenguaje HTML/XHTML para marcar los contenidos, es decir, para designar la función de cada elemento dentro de la página: párrafo, titular, texto destacado, tabla, lista de elementos, etc.
Una vez creados los contenidos, se utiliza el lenguaje CSS para definir el aspecto de cada elemento: color, tamaño y tipo de letra del texto, separación horizontal y vertical entre elementos, posición de cada elemento dentro de la página, etc.
3.2.2.3 Javascript
JavaScript es un lenguaje de programación que se utiliza principalmente para
crear páginas web dinámicas [9]. Una página web dinámica es aquella que incorpora efectos como texto que
aparece y desaparece, animaciones, acciones que se activan al pulsar botones y ventanas con mensajes de aviso al usuario.
Técnicamente, JavaScript es un lenguaje de programación interpretado, por lo que no es necesario compilar los programas para ejecutarlos. En otras palabras, los programas escritos con JavaScript se pueden probar directamente en cualquier navegador sin necesidad de procesos intermedios.
AngularJS es Javascript. Es un proyecto de código abierto, realizado en
Javascript que contiene un conjunto de librerías útiles para el desarrollo de aplicaciones web y propone una serie de patrones de diseño para llevarlas a cabo. En pocas palabras, es lo que se conoce como un framework para el desarrollo, en este caso sobre el lenguaje Javascript con programación del lado del cliente [10].
Este Javascript pretende que los programadores mejoren el HTML que hacen. Que puedan producir un HTML que, de manera declarativa, genere aplicaciones que sean fáciles de entender incluso para alguien que no tiene conocimientos profundos de informática. El objetivo es producir un HTML altamente semántico, es decir, que cuando lo leas entiendas de manera clara qué es lo que hace o para qué sirve cada cosa.
Lógicamente, AngularJS viene cargado con todas las herramientas que los creadores ofrecen para que los desarrolladores sean capaces de crear ese HTML enriquecido. La palabra clave que permite ese HTML declarativo en AngularJS es "directiva", que no es otra cosa que código Javascript que mejora el HTML.
A continuación se nombrarán y describirán los elementos y conceptos que se encuentran en AngularJS.
35
Primeramente tenemos que hablar sobre el gran patrón que se usa en Angular, el conocido Modelo, Vista, Controlador.
Vistas: Será el HTML y todo lo que representa datos o información. Controladores: Se encargará de la lógica de la aplicación y sobre todo de las llamadas "Factorías" y "Servicios" para mover datos contra servidores o memoria local en HTML5. Modelo de la vista: En Angular el "Modelo" es algo más de aquello que se entiende habitualmente cuando se habla del MVC tradicional, o sea, las vistas son algo más que el modelo de datos. En modo de ejemplo, en aplicaciones de negocio donde se tiene que manejar la contabilidad de una empresa, el modelo serían los movimientos contables. Pero en una pantalla concreta de una aplicación es posible que se tengan que ver otras cosas, además del movimiento contable, como el nombre de los usuarios, los permisos que tienen, si pueden ver los datos, editarlos, etc. Toda esa información, que es útil para el programador pero que no forma parte del modelo del negocio, es a lo que llamamos el "Scope" que es el modelo en Angular. Además del patrón principal, descrito hasta ahora existen los módulos que
propone AngularJS para poder dividir las cosas, evitar las variables globales en Javascript, etc. Con los módulos se pueden realizar aplicaciones bien hechas, y sobre todo, que facilite su desarrollo y el mantenimiento.
3.3 Servidor En esta sección se describen los requerimientos funcionales y no funcionales
del servidor. Se introduce al lector en la tecnología utilizada, para luego presentar los componentes principales que lo conforman detallando el diseño e implementación de los mismos.
3.3.1 Requerimientos
A nivel funcional, la aplicación servidor debe: Generar, en el caso de que se encuentre algún error, un mensaje que permita
identificarlo. Permitir usar la herramienta en más de un dominio, valiéndose de la
representación de los mismos mediante un archivo de configuración. Deberá, también, ser capaz de interpretar cualquier pedido que se le haga
presente. Además, tendrá que formatear los datos de respuesta de manera tal que sean
comprendidos sin inconvenientes desde el cliente que los recibe. A nivel no funcional: Debe ser capaz de analizar las sentencias en un tiempo aceptable, reduciendo
la espera de la respuesta a menos de 5 segundos. Debe proporcionar mensajes de error que sean informativos y orientados al
usuario. Debe poseer una documentación en la que se explique cómo se interpretan los
archivos de configuración. Debe proveer la posibilidad de que un usuario del lenguaje JAVA extienda la
funcionalidad de los subcomponentes que lo conforman.
36
Deberá ser capaz de atender y proveer datos independientemente de cómo esté desarrollado el cliente. Es decir, deberá recibir y emitir respuestas independientemente de la tecnología que haya en el otro extremo.
3.3.2 Implementación e Integración
La parte del servidor se creó en el IDE Eclipse. Se incluyó en el mismo un
servidor Tomcat para publicar los servicios durante el desarrollo. Una vez finalizado el desarrollo, este BackEnd compila en un WAR que se instalará en el servidor de la Organización social que requiera la aplicación. Además de Tomcat, la aplicación fue probada en un servidor WebSphere, que es un servidor de aplicaciones de software. Entonces, la aplicación estará disponible a cualquier hora dado que el servidor estará corriendo las 24hs del día.
A continuación se explicarán con más detalle las tecnologías utilizadas.
3.3.2.1 Servicios Web REST
La Transferencia de Estado Representacional (REST - Representational State
Transfer) fue ganando amplia adopción en toda la web como una alternativa más simple a SOAP y a los servicios web basados en el Lenguaje de Descripción de Servicios Web (Web Services Description Language - WSDL) [11]. Ya varios grandes proveedores de Web 2.0 están migrando a esta tecnología, incluyendo a Yahoo, Google y Facebook, quienes marcaron como obsoletos a sus servicios SOAP y WSDL y pasaron a usar un modelo más fácil de usar, orientado a los recursos.
REST define un set de principios arquitectónicos por los cuales se diseñan servicios web haciendo foco en los recursos del sistema, incluyendo cómo se accede al estado de dichos recursos y cómo se transfieren por HTTP hacia clientes escritos en diversos lenguajes. REST emergió en los últimos años como el modelo predominante para el diseño de servicios. De hecho, REST logró un impacto tan grande en la web que prácticamente logró desplazar a SOAP y las interfaces basadas en WSDL por tener un estilo bastante más simple de usar.
Una implementación concreta de un servicio web REST sigue cuatro principios de diseño fundamentales:
Utiliza los métodos HTTP de manera explícita. Un cliente REST debe incluir dentro de la cabecera y cuerpo HTTP todos los parámetros, contexto y datos necesarios para que el servidor genere la respuesta. Esto aumenta el rendimiento del servicio REST y simplifica el diseño e implementación del servidor ya que la ausencia de sesiones de clientes elimina la necesidad de sincronizar datos de sesión con aplicaciones externas.
No mantiene estado, cada mensaje HTTP contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes.
Expone URIs con forma de directorios. Transfiere XML, JavaScript Object Notation (JSON), o ambos. Por lo tanto, el desarrollador sólo tiene que verificar que el nexo cliente /
servidor esté correcto. Se pueden hacer cambios en el servidor, lenguajes, bases de datos, etc. y mientras se devuelvan los datos correctos todo irá correctamente.
Una de las grandes ventajas es la escalabilidad, porque está preparado para crecer sin perder calidad en los servicios ofrecidos. La API puede responder a otros tipos de operaciones o se puede versionar tanto se desee. También la programación del lado del cliente puede crecer todo lo necesario con el tiempo, incluso, crear otros frontales, no solo web, también de Apps para cualquier dispositivo.
A la hora de ejecutar la aplicación también tiene una flexibilidad mucho mayor. Las páginas del front se pueden enviar desde unos servidores y las API pueden estar alojadas en servidores independientes, tantos como se necesiten. Por las
37
características de REST (principalmente no guardar estado) es indiferente qué servidor atienda cada solicitud, pues es el propio cliente el que tiene que mandar el estado al servidor, así que el balanceo de carga es mucho más simple que en aplicaciones tradicionales donde el front está mezclado con el back. También se tiene la aproximación de las "micro APIs", en las que puedes dividir los procesos en diferentes servidores que atienden a diferentes tipos de operaciones del API.
Si en un futuro se quiere hacer otro sistema de la organización pero que no sea para predecir, y que tenga la finalidad de consultar productos o familias, o agregar algunos de estos datos se puede usar el mismo Backend porque está hecho con una API REST. Además, si se quiere hacer un sistema CRUD (alta, baja modificación) de familias, precios o productos, se pueden usar los mismos servicios, y si se quiere hacer otro Cliente en otra tecnología diferente, esto va a funcionar sin tener que cambiar nada del servidor, lo cual lo hace reusable.
3.3.2.2 API REST
Una REST API es una API, o librería de funciones, a la que se accede por el
protocolo HTTP. Una REST API, por tanto, se accede a través de direcciones web o URLs en las que enviamos los datos de nuestra consulta [12]. Como respuesta a la consulta sobre el REST API se obtienen datos en diferentes formatos, como pueden ser texto plano, XML, JSON, etc.
Esto es así porque REST es el estándar más lógico, eficiente y habitual en la creación de APIs para servicios de Internet.
3.3.2.3 Maven
Maven es una herramienta de gestión de proyectos. Se basa en un fichero
central, pom.xml, donde se define todo lo que necesita el proyecto. Maven maneja las dependencias del proyecto, compila, empaqueta y ejecuta los test [13].
Lo más útil de Maven es el manejo de las dependencias. Sin maven, era necesario ir descargando manualmente los jar que se necesitan en el proyecto y copiarlos manualmente en el classpath. Esto es muy tedioso. Con Maven esto no sucede. Sólo es necesario definir en el pom.xml las dependencias que se necesitan y maven las descarga y añade al classpath.
3.3.2.4 Spring
Spring Framework es un marco de aplicaciones Java que facilita enormemente
la implementación de distintos patrones de diseño y la integración con una gran cantidad de tecnologías. Spring Framework (también conocido simplemente como Spring) es un framework Java de Software Libre, liviano de aplicación. Su principal característica es brindar un factory de objetos basado en la Inyección De Dependencia [15] y [16].
Por su diseño el framework ofrece mucha libertad a los desarrolladores en Java y soluciones muy bien documentadas y fáciles de usar para las prácticas comunes en la industria.
Spring se puede ver como un soporte que nos proporciona anotar las clases indicando por ejemplo que pertenecen a la capa de negocio o de acceso a datos. Se dice que son configurables porque podemos definir estereotipos propios "a medida": por ejemplo se podrá definir un nuevo estereotipo que indicara un objeto de negocio que además sería cacheable automáticamente y con acceso restringido a usuarios con determinado rol. También proporciona inyección de dependencias que permite solucionar de forma sencilla y elegante cómo proporcionar a un objeto cliente acceso a un objeto que da un servicio que este necesita. Por ejemplo, que un objeto de la capa
38
de presentación se pueda comunicar con uno de negocio. En Spring las dependencias se pueden definir con anotaciones o con XML.
3.3.2.5 Java
El paradigma de programación utilizado ha sido el Paradigma Orientado a
Objetos, y el lenguaje de programación seleccionado para la implementación ha sido JAVA. La principal motivación de esta elección no es otra que la facilidad para identificar objetos dentro del sistema. Esto ayuda enormemente a la concepción general del sistema.
3.3.2.6 SQL Server
Microsoft SQL Server es un sistema para la gestión de bases de datos
producido por Microsoft basado en el modelo relacional cuya principal función es la de almacenar y consultar datos solicitados por otras aplicaciones, sin importar si están en la misma computadora, si están conectadas a una red local o si están conectadas a través de internet.
Microsoft SQL Server le sirve a Industrias o Bancos o Compañías manufactureras o Empresas o Instituciones. Básicamente, cualquier usuario que desee mantener ordenados/organizados datos o información con el fin de acceder a ellos más adelante.
Se puede elegir Microsoft SQL Server por la seguridad, protección de datos, control de acceso, integridad de datos. La exigencia de integridad de los datos garantiza la calidad de los datos de la base de datos.
SQL Server proporciona los siguientes mecanismos para exigir la integridad de los datos en una columna: Restricciones PRIMARY KEY, Restricciones FOREIGN KEY, Restricciones UNIQUE, Restricciones CHECK, Definiciones DEFAULT, Permitir o denegar valores NULL.
SQL Server admite distintos tipos de datos: Integer, Float, Decimal, Char, Varchar, binarios, texto, entre otros, además de que permite a los usuarios definir y usar su propio tipo de datos compuestos (UDT).
SQL Server permite que varios clientes usen la misma base de datos al mismo tiempo controlando el acceso simultáneo mediante 2 modos de control de concurrencia: Pessimistic concurrency: Uso de bloqueos exclusivos y compartidos. Optimistic concurrency: Similar al uso de sistemas subversión. Permite la creación de una nueva fila cada vez que ésta se actualiza, almacenando las “versiones anteriores” de la fila en una tabla temporal junto con el ID de la transacción mediante la cual fueron actualizadas.
Microsoft SQL Server cuenta con formas diferentes y eficientes de respaldo y recuperación de bases de datos.
3.3.2.7 Logueo de transacciones con Log4j
Es una biblioteca open source desarrollada en Java por la Apache Software
Foundation que permite a los desarrolladores de software escribir mensajes de registro, cuyo propósito es dejar constancia de una determinada transacción en tiempo de ejecución. Log4j permite filtrar los mensajes en función de su importancia. La configuración de salida y granularidad de los mensajes es realizada en tiempo de ejecución mediante el uso de archivos de configuración externos.
3.3.2.8 Manejo de excepciones
Una excepción en términos de lenguaje de programación es la indicación de un
problema que ocurre durante la ejecución de un programa. Sin embargo, la palabra
excepción se refiere a que este problema ocurre con poca frecuencia generalmente cuando existe algún dato o instrucción que no se apega al funcionamiento del programa por lo que se produce un error. El manejo de excepciones permite al usuario crear aplicaciones tolerantes a fallas y robustos (resistentes a errores) para controlar estas excepciones y que pueda seguir ejecutando el programa sin verse afectado por el problema.
En este caso particular se creó una clase encargada de controlar excepciones propias de la aplicación, por ejemplo, cuando no están cargadas todas las utilidades necesarias para realizar la asignación de recursos, o el monto ingresado para llevar a cabo la predicción es menor al mínimo requerido para el estudio, etc.
3.3.2.9 GIT
Se utilizó Git como software de control de versiones, pensando en la eficiencia
y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Git se ha convertido en un sistema de control de versiones con funcionalidad plena. Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo Linux. El diseño de Git resulta de la experiencia del diseñador de Linux, Linus Torvalds, manteniendo una enorme cantidad de código distribuida y gestionada por mucha gente, que incide en numerosos detalles de rendimiento, y de la necesidad de rapidez en una primera implementación.
3.3.2.10 Modelo de datos
El diseño de una base de datos consiste en definir la estructura de los datos
que debe tener un sistema de información determinado. Para ello se suelen seguir por regla general unas fases en el proceso de diseño, definiendo para ello el modelo conceptual, el lógico y el físico.
En el modelo relacional las dos capas de diseño conceptual y lógico, se parecen mucho. Generalmente se implementan mediante diagramas de Entidad/Relación (modelo conceptual), tablas y relaciones entre éstas (modelo lógico). Este es el modelo utilizado por los sistemas gestores de datos más habituales (SQL Server, Oracle, MySQL).
A continuación se puede ver el diagrama correspondiente utilizado:
40
Figura 9: Diagrama de Entidad/Relación utilizado en la Aplicación
3.4 Funcionalidades de la herramienta/Servicios:
La aplicación cuenta con 5 funciones que se describen a continuación y se muestran en sus pantallas correspondientes.
Dichas funcionalidades serán, también, plasmadas en diagramas que aclaran un poco más cada uno de los procesos que se siguen en la aplicación.
A continuación se puede ver un diagrama general de la aplicación y, en las posteriores secciones, se verá el diagrama específico de la pantalla específica.
En dichos esquemas, además, se podrán observar las diferencias entre el presente trabajo y el prototipo anterior.
Ilustración 1: Diagrama general de la Aplicación
41
3.4.1 Login:
Se creó un servicio REST de tipo POST, el cual recibe usuario y password
ingresados y valida los datos con la tabla USUARIO. En el esquema que figura a continuación, se puede ver el proceso completo del
login.
Ilustración 2: Diagrama login
3.4.2 Actualización de datos:
Fue necesario construir una API REST en donde los usuarios podrán usarla
para gestionar el mapeo de una característica con un producto (alta, baja, modificación y consultas) visualizando los datos desde una grilla en pantalla.
También se podrán gestionar los precios de los productos (alta, baja, modificación y consultas) visualizando los datos desde una grilla en pantalla.
Se desarrolló un servicio que lleva a cabo un análisis tomando como fuente de información las tablas Respuestas_Encuestas y Opciones_Encuestas para obtener las características de los beneficiarios y ser mapeados con un producto en particular elegido por el usuario, también usa la tabla Historico_Productos que le brindarán información de todos los productos repartidos por la Organización Social que se hayan cargado en la BD.
En dichas encuestas figuran las respuestas de cada beneficiario en base a sus necesidades (Ver Anexo 1). De tales encuestas, se tomarán datos que luego serán analizados para buscar una correspondencia entre las características que posee un beneficiario y los productos que le serán asignados.
Luego se procesan estos datos y se crea un archivo en formato ARFF para que Weka lleve a cabo el correspondiente análisis, el resultado se escribe en la tabla Regla (reglas generadas por Weka). Esas reglas quedan persistentes en la BD y serán usadas por otro usadas por el servicio de predicción que se detalla a continuación.
En el diagrama que figura abajo, se puede ver el proceso completo del inicio del análisis.
42
Ilustración 3: Diagrama de iniciar análisis
3.4.3 Predicción:
Se desarrolló un servicio REST, el cual recibe el mes elegido para llevar a cabo
la predicción y el monto ingresados por el usuario, busca los resultados en la tabla Regla y luego hace el estudio correspondiente utilizando el algoritmo de Greedy para mostrar en una grilla los resultados de la predicción.
Se decidió utilizar dicho algoritmo ya que los mismos se basan principalmente en usar la mejor opción para un momento dado, para obtener la mejor solución general. El funcionamiento de esta técnica sigue los siguientes pasos:
– Para cada paso en el algoritmo se elige la mejor opción, que se tiene disponible. – Se comprueba si la opción elegida podría llevar a la solución del problema. – Si esa opción puede llevar a la solución se elige, sino se elige la siguiente mejor opción.
– Si el conjunto de “mejores opciones” escogidas es solución, se termina el algoritmo. Si no, se continúa.
Esta técnica nos brinda muchas ventajas, las soluciones “ávidas” son muy fáciles de implementar, por lo tanto fáciles de depurar, la velocidad de ejecución es muy rápida además de usar muy poca memoria.
A diferencia de esta técnica, en los algoritmos de backtracking, no se puede trabajar con espacios de búsqueda muy grandes, además de que la implementación recursiva requiere ciertos gastos en memoria extra, también hay que tener en cuenta que posiblemente se haga el cálculo de alguna solución que ya fue probada, en otro momento.
También se descartó el algoritmo de ramificación y poda debido a que depende mucho del problema a solucionar. Después de analizar el problema, se puede obtener
43
una estrategia adecuada para la convergencia del problema, y si las estrategias son complicadas implica una mayor dificultad al implementar, además de que si la estrategia elegida es incorrecta puede arrojar soluciones también incorrectas.
En el esquema que figura a continuación, se puede ver el proceso completo de la predicción.
Ilustración 4: Diagrama predicción
3.4.4 Asignación de recursos
Se creó un servicio REST, el cual consulta diferentes tablas, conformando un
“universo de productos”, para llenar un combo de productos entre los cuales podrá elegir el usuario.
Se crea otro servicio REST, el cual toma el producto elegido por el usuario en el combo explicado anteriormente y la cantidad (stock) ingresada mediante la interfaz, ejecuta el algoritmo de Bellman (Programación Dinámica, se explica en detalle en el Capítulo 2 de este trabajo) usando, además, la tabla Utilidades y escribe la tabla Reporte_asignacion. En esta última queda guardada la asignación óptima de recursos que debe recibir cada beneficiario en el mes actual.
No se eligió realizar esta acción mediante algoritmos genéticos debido a que los mismos pueden demorarse bastante en converger o no en absoluto, esto depende de cierto modo en los parámetros que se estén utilizando, por ejemplo el tamaño de la población, número de generaciones, etc. Además, pueden converger prematuramente debido a una serie de problemas. Si un individuo que es más apto que la mayoría de sus competidores emerge muy pronto en el curso de la ejecución, se puede reproducir de tal forma que reduce la diversidad de la población muy pronto, haciendo que el algoritmo converja hacia el óptimo local. Este problema se presenta en poblaciones pequeñas, donde una variación aleatoria en el ritmo de reproducción provoca que un genotipo se haga dominante sobre los otros.
Tampoco se decidió elegir algoritmos con procedimientos metaheurísticos ya que los mismos no garantizan una solución óptima en un tiempo finito, tienen muchos parámetros a ajustar y, además, son computacionalmente costosos (lentos).
44
En el diagrama que figura abajo, se puede ver el proceso completo de la asignación de recursos.
Ilustración 5: Diagrama de asignaciones
3.4.5 Reporte de asignaciones:
Se creó un servicio REST, el cual consulta las familias de la tabla Beneficiario,
para llenar un combo de beneficiarios entre los cuales podrá elegir el usuario. También se desarrolló un servicio REST que lista los productos y cantidades
que se le debe entregar al beneficiario seleccionado en una grilla. Adicionalmente, se creó un nuevo servicio para que una vez repartidos todos
los recursos se vacíe en la tabla Reporte_asignacion para de este modo iniciar una nueva asignación.
Se creó un servicio en el cual el usuario podrá exportar el reporte de cada beneficiario particular o del total de los beneficiarios en un archivo csv.
En el esquema que figura a continuación, se puede ver el proceso completo del reporte de asignaciones.
45
Ilustración 6: Diagrama de reporte de asignaciones
3.5 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
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
Capítulo 4: Interfaz de usuario y pruebas realizadas
4.1 Interfaz de usuario
4.1.1 Introducción
La interfaz de usuario es el medio con que el usuario puede comunicarse con
una máquina, equipo, computadora o dispositivo, y comprende todos los puntos de contacto entre el usuario y el equipo.
Normalmente suelen ser fáciles de entender y fáciles de accionar, aunque en el ámbito de la informática es preferible referirse a que suelen ser "amigables e intuitivos" porque es complejo y subjetivo decir "fácil".
En este trabajo, la interfaz pretende cubrir todas las actividades que se han descrito en los apartados anteriores, y que hacían referencia a la entrada y salida de datos por pantalla.
4.1.2 Vista Login
Login es el término que se usa en computación para referirse al ingreso a las
cuentas de usuario, a los sistemas o servicios. Es el momento de autenticación al acceder a un servicio o sistema que funciona normalmente, pidiendo un nombre de usuario y una contraseña, con el fin de tener un control en dicho ingreso. Login es un término que aunque no se menciona mucho entre las personas, está presente cada vez que se ingresa a una cuenta de correo electrónico, un blog, un servicio de mensajería instantánea, etc.
Al crear una cuenta en una página Web que lo requiera, se debe proporcionar un nombre de usuario, que puede ser el nombre real o uno inventado por la persona, y una contraseña o clave. Al dar un nombre de usuario, el sistema verificará en su base de datos si ese nombre ya existe; si así sucede, el sistema rechazará el nombre proporcionado y pedirá uno nuevo; eso se repetirá hasta que el nombre dado sea totalmente original. En el caso de este sistema particular, el administrador del sistema generará los nombres de usuarios y contraseñas para luego acercar los mismos a los usuarios del sistema. A continuación, en la figura 10, se puede observar la pantalla de login de la Aplicación Web desarrollada.
Figura 10: Login de la Aplicación
4.1.3 Vista Predicción
En esta pantalla, como puede observar en la figura 11, se muestra un combo
donde se podrá elegir el mes sobre el cual se hará la predicción y el monto de dinero disponible.
50
Una vez que se completen dichos datos, se deberá presionar el botón “Predecir”. El resultado de la predicción se verá en la grilla que se encuentra en la misma pantalla.
Dicha predicción dejará en claro cuáles son los productos que se recomienda comprar con el monto disponible.
A continuación, en la figura 11, se puede observar la pantalla de Predicción de la Aplicación Web desarrollada.
Figura 11: Vista de la pantalla de Predicción
En secciones posteriores, se explicará más en detalle el funcionamiento de todo lo que se encuentra en esta sección y se mostrarán las pruebas y resultados correspondientes. Además, se podrán observar las excepciones que genera la Aplicación Web cuando hay algún dato faltante o incorrecto.
4.1.4 Vista Actualización
En esta pantalla, se puede llevar a cabo el análisis necesario que se basará en el histórico de productos donados, en las encuestas realizadas a los beneficiarios y en las características que posee cada familia. Para esto, se deberá presionar el botón “Iniciar análisis”. Además, para facilitar la usabilidad, se introdujeron grillas totalmente editables donde se podrán modificar precios de productos y características mapeadas a sus respectivos productos asociados.
A continuación, en la figura 12, se puede observar la pantalla de Actualización de la Aplicación Web desarrollada.
51
Figura 12: Vista de la pantalla de Actualización
4.1.5 Vista Asignación
En esta pantalla, existe un combo donde se podrá elegir un producto y un
cuadro de texto donde se indique la cantidad de ese producto a asignar. Luego, una vez que se eligió lo anterior, se debe presionar el botón de “Asignar
Recurso” y, una vez que termine dicho proceso, se verá en la grilla cuántos de esos productos se asigna a cada familia.
Cabe destacar que esto debe hacerse con cada producto. Es decir, se debe asignar cada uno de los productos por separado.
A continuación, en la figura 13, se puede observar la pantalla de Asignación de la Aplicación Web desarrollada.
Figura 13: Vista de la pantalla de Asignación de Recursos
4.1.6 Vista Reporte
En esta pantalla, se hace presente la posibilidad de generar el reporte de todos
los productos para un beneficiario en particular. Este proceso se tendrá que realizar para cada beneficiario.
52
En la grilla se podrá ver qué producto y qué cantidad del mismo se debe obtener a cada beneficiario.
Además, existe la posibilidad de exportar el reporte para un beneficio particular o para todos los beneficiarios.
Es necesario aclarar que una vez que todo el proceso de asignación y reporte haya terminado, se debe eliminar el historial en esta pantalla para que en la próxima asignación no queden datos que incluyan “ruido” en el proceso.
A continuación, en la figura 14, se puede observar la pantalla de Reporte de la Aplicación Web desarrollada.
Figura 14: Vista de la pantalla de Reporte de Asignaciones
4.2 Pruebas realizadas
En este apartado se analizan los resultados obtenidos del estudio detallado de
un conjunto de datos cargados en la BD de Cáritas. También, se podrá ver otro caso de estudio perteneciente a otro dominio (Hospital), lo cual marca la adaptabilidad de la herramienta para poder ser utilizada en otros ámbitos pertenecientes a otras organizaciones de asistencia social.
En las posteriores secciones se podrán observar las pruebas con ambos dominios. Además, se podrá ver paso a paso las pruebas realizadas que incluirán capturas de la Aplicación, junto con el resultado que se espera a partir de los datos de entrada.
Al finalizar cada sección, se mostrarán los resultados obtenidos junto con un análisis correspondiente que indicará si la salida fue la esperada.
Para comenzar con el estudio de un caso particular de Cáritas, en la Tabla 1 se pueden observar los registros cargados en la tabla de HISTORICO_PRODUCTOS. Estos registros indican el producto y la cantidad de los mismos que fueron otorgadas a los beneficiarios de Cáritas en una fecha determinada.
Por ejemplo, la primera fila indica que se repartieron 10 unidades de agua_mineral el 8 de enero del año 2016.
53
Tabla 1: Contenido de la base de datos Histórico de Productos
En la Tabla 2 se presentan los registros ingresados en la tabla o grilla de PRECIOS, la cual contiene algunos valores como el de un paquete de fideos a $9 por unidad; agua_mineral $10; arroz, $9; entre otros productos y precios. Estos precios deben respetar el valor real que tiene que pagar Cáritas por cada unidad y pueden modificarse en cualquier momento en la BD.
Tabla 2: Contenido de la base de datos PRECIOS
Dichos precios, pueden verse y editarse en la siguiente grilla, figura 15, que se encuentra en la pantalla de Actualización.
54
Figura 15: Grilla de Precios y sin Características
Luego, en la Figura 16, se indica que el monto con el que se va a hacer el cálculo es de $2000 y se va a predecir el mes de enero.
Figura 16: Predicción mes de Enero
La figura anterior, además muestra los resultados obtenidos de la Aplicación en esta primera etapa.
Es importante destacar que, en este punto en particular de la prueba, la única fuente de información existente cargada en el sistema hasta el momento es provista por la tabla HISTORICO_PRODUCTOS.
El resultado obtenido indica que se deben adquirir 66 unidades de agua_mineral, 13 de fruta y 20 de fideo, tomando como unidad de frutas y verduras a una asignación que dependerá de la estación del año.
Por otra parte, el resultado es lógico debido a que, dado a que es un mes de verano, se donaron muchas frutas y agua.
Siguiendo la misma lógica, en las figuras 17 y 18 se puede observar como el sistema predice que se debe comprar polenta, arroz y puré de tomate en el mes de Julio y pan dulce en Diciembre debido a las fiestas junto con agua mineral y frutas debido al calor.
55
Figura 17: Predicción mes de Julio
Figura 18: Predicción mes de Diciembre
Un punto importante para tener en cuenta es que, dado que en este ejemplo en particular, donde en el histórico de productos donados contiene información de los meses Enero, Julio y Diciembre (además, por el momento no existen datos de encuestas ni de características de familias), si el usuario selecciona un mes diferente, por ejemplo Marzo u Octubre el sistema emitirá un error como el que se puede apreciar en las Figuras 19 y 20.
Figura 19: Error Marzo sin Productos
56
Figura 20: Error Octubre sin Productos
Continuando con el ejemplo, La Tabla 3 muestra las características especiales en general que puede tener un hogar determinado junto con el alimento que se corresponde con dicha característica.
Tabla 3: Contenido tabla MAPEOS
Avanzando un poco más con el ejemplo base, a continuación, en las figuras 4 y 5, pueden observarse las encuestas respondidas junto con las opciones elegidas.
Tabla 4: Contenido tabla RESPUESTAS ENCUESTAS
Tabla 5: Contenido tabla OPCIONES
Como puede apreciarse en las dos figuras anteriores, los beneficiarios 1, 2 y 4 respondieron que en su familia hay un integrante hipertenso (esto es porque eligieron la opción 1 de la pregunta cuyo id es 2), por lo que, dicha información, se tendrá en cuenta en futuras predicciones.
Aquí es muy importante aclarar que, a diferencia del prototipo inicial desarrollado en [7], las características de las familias pueden ser multivaluados. Es decir, para el caso donde una familia tenga la característica de hipertenso, la misma recibirá varios alimentos de este tipo (en caso que haya disponible). Con esto, se
57
elimina la posibilidad de asignaciones incorrectas que ocurrían cuando cada característica tenía asociado un único producto y, si el mismo no estaba disponible, no se intentaba asignar otros productos que cubrían la misma característica.
Uniendo los datos de las tablas 3, 4 y 5 se puede inferir que en futuras predicciones, debido a la cantidad de gente hipertensa, la Aplicación tendrá que sugerir la compra de galletas sin sal para cubrir las necesidades de dichos beneficiarios.
Teniendo en cuenta lo dicho en el párrafo anterior, se realizaron nuevamente las pruebas de predicciones y el resultado fue el esperado. Es decir, como puede ver en las figuras 21, 22 y 23, la predicción arroja que, además de lo que se arrojaba en las pruebas anteriores, también se compre galletas sin sal en los meses de Enero, Julio y Diciembre.
Figura 21: Predicción mes de Diciembre con Encuestas
Figura 22: Predicción mes de Diciembre con Encuestas
Figura 23: Predicción mes de Diciembre con Encuestas
Ahora bien, a diferencia del instante donde no se habían cargado características ni se habían respondido encuestas, la aplicación no debería arrojar el
58
error de “No hay datos suficientes para realizar el estudio del mes X” sino que, dado que hay gente hipertensa en familias, las galletas sin sal deben proveerse cada mes, siempre y cuando haya plata para comprarlas, obviamente.
Luego de las pruebas correspondientes, como se puede observar en las figuras 24 y 25, se puede apreciar que, por ejemplo, en Marzo y Octubre, se predice que hay que comprar galletas sin sal como era de esperarse.
Figura 24: Predicción Marzo con encuestas
Figura 25: Predicción Octubre con encuestas
Para cerrar lo que se refiere a las predicciones, es necesario aclarar que, las características con sus respectivos mapeos a productos, pueden editarse y observarse en la pantalla de Actualización en la respectiva grilla de la izquierda. Lo anterior puede observarse en la figura 26.
59
Figura 26: Pantalla de Actualización con Precios y Características
En la segunda etapa del trabajo se distribuyen los productos que se han adquirido. Ahora entra en juego la herramienta de optimización en asignación de recursos. El algoritmo de la herramienta es ejecutado por cada producto, a continuación se verá una prueba realizada.
Para realizar dicha tarea, se cuenta con una tabla de UTILIDADES, que contiene los valores de utilidad que cada familia le da a las diferentes cantidades de un producto en particular. Esta tabla está conformada por registros y contiene la información requerida por el algoritmo (en la tabla 6 puede verse el formato de la misma).
60
Tabla 6: Parte del contenido de la tabla de UTILIDADES
Focalizándose en el ejemplo, en las figuras 27, 28, 29, y 30 se puede observar el proceso de asignar agua mineral, pan dulce, polenta y galletas sin sal respectivamente a los diferentes beneficiarios.
Figura 27: Asignar agua mineral
61
Figura 28: Asignar polenta
Figura 29: Asignar pan dulce
Figura 30: Asignar galleta sin sal
Como se puede apreciar en las imágenes anteriores, en la grilla de la derecha, queda el registro de las cantidades de productos seleccionados que se deben proveer a cada beneficiario.
Una vez finalizada la funcionalidad de asignar recursos, se observó que sería de gran utilidad contar con la posibilidad de importar los resultados obtenidos en cada asignación a la tabla de histórico de productos para que la misma se retroalimente automáticamente.
Para esto, una vez que se selecciona la opción de importar, se le da al usuario la posibilidad de elegir si quiere realizar la importación antes mencionada o no (figura 31).
62
Figura 31: Consulta sobre importación a histórico de productos
Luego, si se selecciona la opción “Si”, se manda a guardar la asignación dada a la tabla de históricos de productos.
En la Tabla 7 se puede observar el estado de la tabla de histórico de productos donados antes de seleccionar la opción “Si”. Posteriormente, luego de seleccionar la opción antes mencionada, puede verse (Tabla 8) como la tabla se actualiza guardando la cantidad asignada de un producto particular para la fecha en la que se esté llevando a cabo la asignación.
Tabla 7: Tabla de histórico de productos sin actualizar por importaciones
Tabla 8: Tabla de histórico de productos actualizada luego de aceptar la importación
Ahora bien, una vez que se finalizan de asignar todos los productos, si se desea conocer el reporte completo para un beneficiario particular, hay que dirigirse a la sección de Reportes de asignaciones. Aquí se puede ver con claridad la asignación completa que recibirán cada uno de los beneficiarios.
Una vez que nos situamos en dicha pantalla, se puede elegir un beneficiario y luego presionar el botón Obtener asignación. Esta acción debe realizarse para cada uno de los beneficiarios a los que se desee entregar el asignación determinada.
En las figuras 32, 33, 34, 35 y 36 se puede ver los recursos asignados a cada uno de los 5 beneficiarios del sistema.
63
Figura 32: Obtener asignación para el beneficiario 1
Figura 33: Obtener asignación para el beneficiario 2
Figura 34: Obtener asignación para el beneficiario 3
Figura 35: Obtener asignación para el beneficiario 4
64
Figura 36: Obtener asignación para el beneficiario 5
De esta manera, queda ilustrada una de las funcionalidades más importantes del sistema que es la generación de recursos asignados a cada una de los beneficiarios de la Organización.
Al voluntario sólo le resta seguir los pasos mencionados y entregar los productos correspondientes a cada uno de los beneficiarios que indica el sistema.
Otro aspecto importante de la Aplicación es que permite exportar los resultados tanto del reporte de una asignación determinada como la exportación de los recursos asignados de todos los beneficiarios en formato CSV.
En la figura 37, se puede observar que, al presionar el botón Exportar beneficiario se descarga un archivo y el contenido del mismo se puede ver en la figura 38.
Figura 37: Exportar reporte individual
65
Figura 38: Contenido del reporte exportado
En la figura 39, se puede observar que, al presionar el botón Exportar todo se descarga un archivo y el contenido del mismo se puede ver en la figura 40. Aquí, como se dijo antes, se puede ver la información de los recursos para todos los beneficiarios.
Figura 39: Exportar reporte para todos los beneficiarios
66
Figura 40: Contenido del reporte total exportado
Por último, una vez que se hayan realizado todos los reportes, se deberá eliminar el historial de asignaciones para que los datos existentes no interfieran en futuras asignaciones de recursos.
Lo anterior, se realiza haciendo clic en el botón eliminar historial que se muestra en la figura 41. Al hacer lo dicho, cuando el proceso haya finalizado, se muestra un cartel que indica que el borrado ha finalizado.
67
Figura 41: Borrar historial de reporte
Con todo lo mencionado queda definido un ciclo completo en lo que se refiere al uso de la aplicación.
Es importante aclarar que la salida que se muestra en los archivos exportados puede ser usada para cargar la base de datos del histórico de productos donados.
Con lo anterior, se logra que la aplicación tenga un aprendizaje constante que le servirá para futuras predicciones.
4.3 Pruebas realizadas en Red. Luego de realizar las pruebas de la sección anterior, se prosiguió con las pruebas en red para corroborar que la Aplicación se desempeñe correctamente. Lo que se hizo fue conectar dos máquinas en red, donde una de ellas tenía el rol de servidor, por lo que la otra máquina apuntaba a la primera para compartir todo lo que sea referido a la base de datos. En las figuras 42 y 43 puede observar una de las máquinas (la que posee el rol de servidor) y la otra que apunta a la IP de la primera para conectarse y utilizar la Aplicación en paralelo.
Figura 42: Pantalla de predicción en servidor
68
Figura 43: Pantalla de predicción fuera del servidor
En primera instancia, ambos usuarios se loguean en la Aplicación como se puede observar en las figuras 44 y 45. El logueo se hace igual que como si hubiese un sólo usuario utilizando la Aplicación. Es decir, se corrobora en la base de datos sean los correctos para ambos usuarios y sus contraseñas.
Figura 44: Login en servidor
Figura 45: Login fuera del servidor
Como medida de prueba inicial, se realizarán cambios en los precios de un producto y se corroborará que el segundo usuario vea reflejado dicho cambio.
El precio inicial del agua mineral es de 12 pesos como se puede apreciar en la figura 46 y en la 47. En este punto, ambos usuarios ven el mismo precio
69
Figura 46: Pantalla de actualización en servidor
Figura 47: Pantalla de actualización fuera del servidor
Luego, en la figura 48, se puede ver cómo el primer usuario modifica el precio del agua mineral.
70
Figura 48: Se actualiza el precio en servidor
Como se puede observar en la figura 49, el resultado es el esperado ya que el segundo usuario, al ingresar a la pantalla de Actualización, ve el precio del agua mineral (14 pesos) tal cual lo ha modificado el primer usuario.
Figura 49: Fuera del se ve el cambio hecho anteriormente
71
Otra de las pruebas realizadas fue cuando el usuario 1 asigna los productos disponibles y luego el usuario 2 genera los reportes en base a las asignaciones realizadas por el otro usuario.
En las figuras 50 y 51 se puede observar cómo el usuario 1 asigna agua mineral y cómo el usuario 2 genera el reporte para esa asignación (se muestra sólo una asignación por cuestiones de legibilidad).
Figura 50: Se asigna agua mineral en servidor
Figura 51: Generación de reporte fuera del servidor
4.4 Excepciones que se muestran en la Aplicación
En esta sección se detallan y muestran las excepciones que se hacen presentes en la Aplicación cuando se ingresa algún dato erróneo, cuando hay ausencia de algún campo requerido o cuando no se cumple con alguna acción requerida por la Aplicación.
72
Para comenzar, en la pantalla de Actualización, en caso de que no se seleccione ninguna fila para borrar algún mapeo o precio se mostrará los errores que se muestran en las figuras 52 y 53.
Figura 52: Excepción al eliminar mapeo
Figura 53: Excepción al eliminar precio
De igual manera, si se desea agregar un mapeo o precio nuevo, si no se completan los datos en el pop up que se muestra, se van a producir los errores que se muestran en las figuras 54 y 55.
73
Figura 54: Excepción al agregar mapeo
Figura 55: Excepción al agregar precio
Pasando a la pantalla de Predicción, en caso que no se seleccione un mes o no se ingrese un monto se verá la excepción que se muestra en la figura 56.
Figura 56: Excepción en predicción
Si nos trasladamos a la pantalla de Asignaciones, en caso de no seleccionar un producto o una cantidad, la Aplicación emitirá un error como los que se pueden ver en la figura 57.
74
Figura 57: Excepción en asignación
Por último, en caso que no se seleccione un beneficiario en la pantalla de Reportes, se emitirá el error que se muestra en la figura 58.
Figura 58: Excepción en Reportes
4.5 Ejemplo de uso de la Aplicación en otro dominio (Hospital)
Por cuestiones de legibilidad, este ejemplo se hará más corto y se mostrará el paso a paso del ejemplo con algunas imágenes. No se desarrollará demasiado ya que dicha acción ya fue hecho en profundidad en el ejemplo anterior.
El ejemplo siguiente es sólo para demostrar la adaptabilidad del sistema a diferentes dominios sólo cambiando una línea en un archivo de configuraciones (no se mostrará la información que se encuentra en la base de datos ni otras cosas que ya se han ido mostrando en el ejemplo anterior). Para realizar la acción mencionada, se debe ingresar a dicho archivo de configuración y, únicamente, modificar el nombre de la base de datos por la que se desee usar en un determinado momento. En la figura 59, puede observar la pantalla de Actualización con las grillas de mapeos y precios de los productos pertenecientes a un hospital.
75
Figura 59: Pantalla de actualización
Luego, en la figura 60, se pueden ver las predicciones generadas (en este ejemplo se mostrará la predicción del mes de Enero).
Figura 60: Predecir en hospital
Para el caso de la asignación de productos, se cuenta con las utilidades que se muestran en la tabla 9.
76
Tabla 9: Contenido de la tabla de UTILIDADES
Para continuar con el ejemplo del Hospital, si se desean asignar los productos, la Aplicación responde correctamente como se puede ver en las figuras 61.
Figura 61: Asignar en hospital
Por último, en la figura 62 se aprecia el reparto de recursos para un beneficiario determinado.
77
Figura 62: Reportes en hospital
78
Capítulo 5: Conclusiones.
En este trabajo se presentó una herramienta Web para la ayuda en la toma de decisiones en Organizaciones Sociales. A partir de las herramientas existentes en la actualidad, se propuso el desarrollo de una herramienta visualmente atractiva, amigable, intuitiva, extensible y configurable, con el fin de superar varias de las limitaciones presentadas por la herramienta existente.
Centrándose en los objetivos cumplidos del presente trabajo, a continuación se hace un análisis detallado de los mismos junto con las limitaciones para cubrirlos:
- La migración del Prototipo inicial a una Aplicación que sea Web se llevó a cabo gracias a un análisis exhaustivo de herramientas y lenguajes de programación que permitieran un buen resultado final y que permitan cumplir con los objetivos planteados. La curva de aprendizaje de dichas herramientas fue grande y fue la causante de una demora extra en la finalización del trabajo. - En lo que se refiere a la posibilidad de generalizar la Aplicación, esto fue posible gracias a un archivo de configuración en el cual, con sólo hacer una pequeña modificación que consta del nombre de la base de datos que se desea utilizar, se logra el objetivo. Esto es realmente muy sencillo de realizar y cumple con unas de las metas principales del presente trabajo. - Con respecto al tema del login, esto fue logrado gracias a un servicio desarrollado que toma los datos ingresados y corrobora que sean los correctos. Esto también fue esencial ya que permite aportar seguridad al sistema. - Luego, pasando al resto de objetivos que representan mejoras al trabajo anterior, los mismos pudieron ser logrados debido al desarrollo de varios servicios y herramientas idóneas. Por ejemplo, en lo que se refiere al proceso de Iniciar Análisis, se pudo cumplir con lo esperado gracias a la refactorización de funcionalidades y servicios en paralelo que permiten que la funcionalidad no sea bloqueante. En lo que se refiere a la posibilidad de editar campos relacionados con las características y productos se buscó un mecanismo que permita realizar este tipo de acciones y se adaptó el mismo a la herramienta. El mismo mecanismo fue útil para poder llevar a cabo todas las validaciones y mensajes de error que se mencionan en los objetivos. Luego, con respecto a la carga de los combos de las pantallas, los atributos multivaluados, exportación de reportes y nuevos comportamientos en la distribución de productos fue logrado por medio de diversos servicios que se encargan de dichas acciones. En todos los casos, la limitación más general fue el conocimiento, tanto de las herramientas seleccionadas como del dominio de trabajo, de manera que se cumplan todos los objetivos de manera clara y no se experimenten resultados irreales en la Aplicación.
Es importante hacer notar que herramientas de esta índole son propicias para el tomador de decisiones para poder monitorear, simular, evaluar y predecir la demanda de recursos. Por otra parte permiten cuantificar e informar lo realizado a los efectos de mostrar resultados e incentivar las donaciones o mejorar la oferta.
A su vez, estas herramientas son de importancia para terceros, en especial el Estado, que puede obtener información adicional en el tratamiento de diversas problemáticas tales como detectar focos de enfermedades, analizar causas posibles de alguna problemática social, dimensionar el alcance de algún servicio a la comunidad, como podría ser la instalación de un centro de día, un comedor o una sala sanitaria. A través de este trabajo, se realizó una introducción en la obtención de información relevante de masas de datos compactas en un tema sensible como es la satisfacción de necesidades básicas insatisfechas. Se analizaron numerosos métodos
79
de cálculo y obtención de resultados que provee la MD como clustering, clasificación, asociación y predicción, entre otros, logrando un mayor grado de objetividad en la toma de decisiones al momento de establecer las compras de los productos que serán distribuidos a los beneficiarios. Si bien se puede profundizar más en la MD, esto no forma parte del objetivo de este trabajo.
A través de la herramienta de modelado Weka, se han podido analizar y aplicar de manera práctica y constructiva varios de los métodos de MD nombrados anteriormente que se encuentran implementados en la misma.
Se pudieron interpretar los resultados y discernir entre atributos influyentes y no influyentes, filtrando instancias de la gran masa de datos obtenidos.
Las pruebas anteriormente vistas han demostrado que los métodos utilizados son apropiados a la hora de solucionar las problemáticas que fueron planteadas. Para eso fueron claves los datos suministrados a la hora de realizar el proceso de MD, ya que para que se obtenga información relevante se deben tener la mayor cantidad de atributos y registros posibles en la BD, con el fin de encontrar alguna relación entre los datos y así generar un modelo donde se puedan identificar las relaciones existentes. En este caso se presentó un ejemplo concreto y simple para mejor entendimiento del proceso que se lleva a cabo, pero como se mencionó anteriormente, la Aplicación Web será más efectiva cuando se inserten grandes cantidades de datos.
Dentro del entorno de aplicación utilizado para la realización de esta investigación, el uso de la MD implica la obtención de diversos beneficios y ventajas para los interesados. Las ventajas van más allá de los resultados o reglas obtenidas por la aplicación de los algoritmos y tienen que ver con el uso, que de este conjunto de reglas obtenidas se haga, por parte del usuario final.
También, mediante la incorporación del algoritmo que se había desarrollado anteriormente, se logra optimizar la distribución de recursos por parte de cualquier Organización Social entre los beneficiarios involucrados.
De esta manera los beneficiarios más necesitados tendrán mayor prioridad y se logra una asignación más justa, maximizando el aprovechamiento de los recursos. El mayor inconveniente de la solución que se propone es que se necesita de un análisis de utilidades lo suficientemente sólido, ya que la matriz de utilidades es la base de todo el algoritmo.
Dicho análisis podría consistir en una serie de estudios sobre datos históricos de los beneficiarios, entrevistas, etc. Es importante intentar minimizar la subjetividad que arrojan estos resultados, esa es una de las cuestiones en que la Teoría de utilidades pone su mayor énfasis.
5.1 Trabajos Futuros
Teniendo en cuenta que el presente trabajo se enmarca dentro del Proyecto
Koinonia, el trabajo futuro depende de las exigencias de este último, pero en todo caso hay que destacar diferentes actividades que sí se deberían realizar en un futuro independientemente del proyecto que lleva adelante la Organización. Este trabajo futuro engloba varias áreas de mejora dentro del proyecto y son muchas las propuestas que se pueden plantear para la continuación o enriquecimiento de este trabajo.
A continuación se exponen las mismas.
5.1.1 Trabajo futuro 1: Ranking de productos para colectas.
En este prototipo se deberá contar con el dinero que dispone la Organización
Social para obtener la ayuda en la toma de decisiones. Se podría incorporar la obtención de un resultado independientemente del dinero que posee la organización. Un resultado, que consista en productos y cantidades de los mismos necesarios en un mes determinado, sin el ingreso del monto disponible de dinero. Es decir, presentar un
80
ranking donde se listen los productos de primera necesidad y, entonces, suponiendo que se pretende realizar una colecta, sería conveniente anunciar qué se necesita con mayor prioridad.
5.1.2 Trabajo futuro 2: Trazabilidad.
Se propone incluir trazabilidad en la herramienta para brindarle una mayor
transparencia al donante por parte de la Institución. Entonces, si un donante consulta a la Institución qué productos se necesitan con mayor prioridad y la Organización Social le pide un determinado producto al donante, el mismo sabrá luego cómo fue distribuido entre los beneficiarios. Así, la herramienta deberá ser capaz de generar informes acordes a este pedido. Este informe deberá contener, entre otras cosas, la fecha en la que se realizó la donación (en el caso de dinero, la fecha en la cual se lo usó para la compra de productos del stock), cantidad de productos adquiridos y familias beneficiadas.
5.1.3 Trabajo futuro 3: Proceso para el estudio de Weka.
Se puede crear un proceso que se ejecute cada cierto tiempo (un día fijo de cada mes) y que se encargue de todo el estudio que se hace ahora al presionar el botón “Iniciar análisis”. Se podría implementar con Quartz, que es un Framework para planificar las tareas y ayuda a las aplicaciones Java a programar trabajos/tareas que se ejecuten en una fecha y hora especificadas.
5.1.4 Trabajo futuro 4: Reemplazo de Weka por otro algoritmo de procesamiento.
El tiempo que tarda el análisis que se lleva a cabo para luego realizar la predicción, depende de la cantidad de datos que tenga que procesar Weka. A medida que vaya creciendo el volumen de la BD, se sugiere ver afectado ese análisis en su performance. En ese caso, se podría analizar la posibilidad de cambiar la herramienta por un algoritmo que se comporte como Weka pero que no realice un análisis tan exhaustivo.
5.1.5 Trabajo futuro 5: Modificar Bellman por otros métodos de asignación.
Se podrían agregar más métodos de asignación de recursos para que el
usuario pueda elegir entre ellos. Por ejemplo, Algoritmos Genéticos, que son métodos adaptativos que pueden usarse para resolver problemas de búsqueda y optimización; Proceso analítico jerárquico, que es una técnica estructurada para tratar con decisiones complejas; Metaheurístico, que son procedimientos de búsqueda que no garantizan la obtención del óptimo resultado del problema considerado y que se basan en la aplicación de reglas relativamente sencillas. Los métodos revisados en el capítulo 1.1., evaluados en trabajos finales de la cátedra Investigación Operativa, pueden ser incorporados a la herramienta.
5.1.6 Trabajo futuro 6: Carga de Tabla utilidades.
Crear proceso que cargue las utilidades con sólo saber las respuestas de cada
familia a una serie de preguntas que se incorporarán a las encuestas. O sea, crear un algoritmo que dados los valores de utilidad que le da cada familia a estar satisfecho o muy satisfecho con recibir una cierta cantidad de algún producto particular, llene la tabla de utilidades automáticamente.
81
En necesario remarcar que uno de los temas importantes para continuar avanzando con el análisis, es la posibilidad de incorporar conocimiento al modelo de manera permanente. Es decir que en lugar de trabajar con toda la información del problema a priori, sea posible continuar incorporando información que se refleje en el modelo con una cierta periodicidad. Esto permite cambiar el comportamiento del sistema inteligente a largo plazo. Dicho comportamiento, está incluido en el presente trabajo y representa una interesante ayuda ya que la incorporación de datos puede hacerse fácilmente desde la interfaz del usuario.
Para finalizar, es importante mencionar que los resultados y el accionar de la herramienta presentada en este trabajo es parte de un grupo de servicios evaluados para ser ofrecidos por la organización civil Proyecto Koinonía. En este sentido las autoridades del proyecto valoran el accionar de la herramienta propuesta y es intención su puesta en producción en el corto a mediano plazo, dependiendo sobre todo del recurso humano, en su mayoría voluntariado y de recursos tecnológicos de las instituciones usuarias.
82
Anexo 1
Los beneficiarios responden las encuestas. La encuesta amplia la realiza el titular e incluye datos personales, de la
vivienda, y situación social. La encuesta acotada la realiza cada integrante de la vivienda del respectivo
titular e incluye datos personales y situación social. Los beneficiarios o personas responden las encuestas y se registran sus
respuestas en la tabla correspondiente. Para lograr generar una matriz de utilidades lo suficientemente sólida, se
necesitan encuestas más detalladas sobre las características de las familias así como la ayuda de expertos en el área de humanidades (asistentes sociales, por ejemplo).
Las encuestas actuales, cumplen bien el propósito de recolectar datos personales y situación socioeconómica de cada familia, pero aportan muy poca información sobre las necesidades que tienen para con cada recurso en particular.
Se proponen algunas preguntas para un nuevo modelo de encuesta, que aporte mayor información para la construcción de la matriz de utilidades.
Pregunta 1: Ordene los siguientes alimentos, según la prioridad que le dé a cada uno. Utilice números del 1 al 10: yerba, harina, fideos, azúcar, sal, arroz, leche, papa, zapallo, lentejas.
Pregunta 2: Para cada alimento, indique la cantidad con que se puede conformar para subsistir durante un mes.
Pregunta 3: Para cada alimento, indique la cantidad con que puede satisfacer totalmente sus necesidades para subsistir durante un mes.
Dichas preguntas, van a aportar en la construcción de la matriz de utilidades
83
Bibliografía
[1] PÉREZ LÓPEZ C., SANTÍN GONZÁLEZ D: Minería de datos: Técnicas y herramientas. S.A. EDICIONES PARANINFO. 2007
[2] VIEIRA BRAGA L., ORTIZ VALENCIA L, RAMIREZ CARVAJAL S: Introducción a la minería de datos. Rio de Janeiro: Editora E-papers. 2009
[4] Sitio Web: https://developer.mozilla.org/es/docs/Web/Guide/HTML/Introduction_alhtml Fecha de consulta: Febrero 2017
[5] ILLESCAS G, BUENO M., DOS REIS M., XODO D., PÉREZ C., RECOFSKY E., WEIMANN R.: “Optimización en la asignación de recursos. Indicadores de transición de la decisión a la acción”. Anales del XXVI ENDIO – XXIV EPIO. Córdoba, Argentina. Mayo 2013.
[6] Sitio Web: https://librosweb.es/libro/css/capitulo_1.html Fecha de consulta: Febrero 2017
[7] Weimann Ramiro, Recofky Emliano. Tesis de grado: “Herramienta de soporte para la toma de decisiones en organizaciones de asistencia social”. Octubre 2015.
[8] Bueno, Moisés; Dos Reis, María Rosa; Illescas, Gustavo; Tripodi, Gustavo; Vallejos, Ignacio; Méndez Casariego, Ignacio: “CONOCIMIENTO EN ACCIÓN: MÉTODOS DE ASIGNACION DE ALIMENTOS A GRUPOS FAMILIARES - PROYECTO KOINONÍA”. ISSN 1853-9777. Revista de la Escuela de Investigación Operativa. Año XIX No 32 – Págs. 183 a 205 - Agosto 2011.
[9] Sitio Web: https://librosweb.es/libro/javascript/capitulo_1.html Fecha de consulta: Febrero 2017
[10] Sitio Web: http://www.desarrolloweb.com/articulos/que-es-angularjs-descripcion-framework-javascript-conceptos.html Fecha de consulta: Febrero 2017
[11] Sitio Web: http://www.dosideas.com/noticias/java/314-introduccion-a-los-servicios-web-restful.html Fecha de consulta: Febrero 2017
[12] Sitio Web: http://www.desarrolloweb.com/wiki/rest-api.html Fecha de consulta: Febrero 2017
[13] Sitio Web: http://www.genbetadev.com/java-j2ee/introduccion-a-maven Fecha de consulta: Febrero 2017
[14] RECOFSKY E. Y WEIMANN, R. “Entrevista al Párroco de la Iglesia San Cayetano, Padre Fabián Gerez”. Reporte interno. Tandil, Argentina. 2014.
[15] Sitio Web: https://blognextstar.wordpress.com/2013/02/08/spring-framework/ Fecha de consulta: Febrero 2017
[16] Sitio Web: http://www.jtech.ua.es/j2ee/publico/spring-2012-13/sesion01-apuntes.html Fecha de consulta: Febrero 2017
[17] Sitio Web: http://asprotech.blogspot.com.ar/2013/04/atributos-y-medidas-de-calidad-del.html Fecha de consulta: Febrero 2017
[18] RODRIGUEZ ROJAS, W. J. Conceptos y ejemplos básicos de la programación dinámica. Tesis de Grado para optar por el título de matemático. Bogotá D.C., Colombia. 34 p. 2005.
[19] HAMILTON CASTRO, A. F. Estrategias de control óptimo basadas en programación dinámica y redes neuronales para sistemas MIMO continuos no lineales. Tesis Doctoral. Tenerife, España. 273 p. 1996.
[20] José Jiménez. METODOS ESTADISTICOS. Junio 2015.
[21] VALERA GUARDIOLA, F. Sistema de predicción de resultados en eventos deportivos y su aplicación en las apuestas. Tesis Ingeniería Informática. Leganés, Universidad Carlos III de Madrid. 260p. 2013.
[22] Sitio Web: https://es.wikipedia.org/wiki/Miner%C3%ADa_de_datos Fecha de consulta: Febrero 2017
[23] Aprendizaje automático. Sitio Web: http://es.wikipedia.org/wiki/Aprendizaje_autom%C3%A1tico Fecha de consulta: Febrero 2017
[24] LUCENA, M. A. Análisis comparativo entre métodos estadísticos y de minería de datos. Proyecto fin de carrera. Madrid, España. 231 p. 2005.
[25] Sitio Web: http://bvs.sld.cu/revistas/san/vol2_2_98/san15298.htm Fecha de consulta: Febrero 2017
[26] Carlos Márquez Vera, Cristóbal Romero Morales, Sebastián Ventura Soto 2012: Predicción del Fracaso Escolar mediante Técnicas de Minería de Datos. IEEE-RITA Vol. 7, Núm. 3, Nov. 2012.
[27] CALLEJA GÓMEZ, A.J. Minería de Datos con Weka para la predicción del precio de automóviles de segunda mano. Proyecto fin de carrera. Valencia, España. 95 p. 2010.
[28] Sitio Web: http://www.webmining.cl/2011/01/proceso-de-extraccion-de-conocimiento/ Fecha de consulta: Febrero 2017
[29] 5 de los mejores software de minería de datos de Código Libre y Abierto. Sitio Web: http://blog.jmacoe.com/gestion_ti/base_de_datos/5-mejores-software-mineria-datos-codigo-libre-abierto/ Fecha de consulta: Febrero 2017
[30] CORSO, C. L.; S. L. ALFARO. Alternativa de herramienta libre para la implementación de aprendizaje automático. Córdoba, Argentina.
[31] WITTEN, I. H.; E. FRANK; L. TRIGG; M. HALL GEOFFREY HOLMES; S. CUNNINGHAM. s.f. Weka: Practical machine learning tools and techniques with java implementations. Waikato. New Zealand.
[32] Sitio Web: http://exa.unne.edu.ar/informatica/SO/Mineria_Datos_Vallejos.pdf Fecha de consulta: Febrero 2017
[33] VALHONDO, D. Gestión del conocimiento; del mito a la realidad. Madrid, España, Díaz De Santos, S.A. 373 p. 2010.
[34] FAYYAD, U.; G. PIATETSKY-SHAPIRO; P. SMYTH. From Data Mining to Knowledge Discovery in Databases. AAAI. (July): 37-54. 1996.
[35] MARTÍNEZ ÁLVAREZ, C.A. Aplicación de técnicas de minería de datos para mejorar el proceso de control de gestión en Entel. Tesis Mag. Santiago de Chile. 111p. 2012.
[36] TWO CROWS CORPORATION. Introduction to Data Mining and Knowledge Discovery. 3° ed. Two Crows Corporation. 1999.
[37] X. WU et al. Top 10 algorithms in data mining. Springer -Verlag. 2007.
[38] R. XU and D. C. WUNSCH II. Survey of Clustering Algorithms. IEEE Transactions on neural networks. 2005. [39] Sitio Web: http://apuntesinformaticauade.blogspot.com.ar/2013/02/capitulo-16-algoritmos-greedy-parte-i.html Fecha de consulta: Febrero 2017
[40] Bueno, Moisés; Dos Reis, María Rosa; Illescas, Gustavo; Tripodi, Gustavo;
Vallejos, Ignacio; Méndez Casariego, Ignacio: “CONOCIMIENTO EN ACCIÓN:
RANKING DE FAMILIAS SEGÚN NECESIDADES BÁSICAS INSATISFECHAS –
PROYECTO KOINONÍA”. Anales del XXIII ENDIO – XXI EPIO – II ERABIO. ISBN
978-987-24267-1-2. Tandil, Bs As, Argentina. Septiembre 2010.
[41] PÉREZ, A. s.f. Economía general. Lima, Perú. 95 p.
[42] Bueno, Moisés; Dos Reis, María Rosa: “CONOCIMIENTO EN ACCIÓN:
PROPUESTA DE APLICACION DE MODELO DE STOCK MULTIPRODUCTO CON
RESTRICCIONES. PROYECTO KOINONÍA”. Anales del XXIV ENDIO – XXII EPIO.
ISBN 978-950-665-672-0. Río Cuarto, Córdoba, Argentina. Mayo 2011.
[43] Illescas, Gustavo; Bueno, Moisés E.; Dos Reis, María R.; Xodo, Daniel; Pérez, César D.; Recofsky, E.; Weimann, Ramiro H.:”OPTIMIZACIÓN EN LA ASIGNACIÓN DE RECURSOS.INDICADORES DE TRANSICIÓN DE LA DECISIÓN A LA ACCIÓN”. Anales del XXVI ENDIO – XXIV EPIO. ISBN 978-987-24267-4-3. Córdoba, Argentina. Mayo 2013. [44] Trotti, Marcos; Dos Reis, María Rosa; Bueno, Moisés; Xodo,
Daniel: “ALGORITMO GENÉTICO PARA LA ASIGNACIÓN EFICIENTE DE
RECURSOS EN CASOS DE CATÁSTROFES CLIMÁTICAS”. Anales del XVII
WORKSHOP DE INVESTIGADORES EN CIENCIAS DE LA COMPUTACION, WICC
2015. ISBN 978-950-34-1084-4. Salta, Argentina. 2014
[45] DAVENPORT, T.H.; L. PRUSAK. Working Knowledge: How organizations manage what they know. Boston, MA: Harvard Business School Press. 1998.
[46] ORALLO, J. H.; C.F. RAMÍREZ. Práctica de minería de datos: Introducción al weka. Doctorado. Valencia, España. 2006.
[47] Xodo, Daniel; Dos Reis, María; Bueno, Moisés; Bengochea, Joaquín; Vidal Porcel, Édison; Suarez, Daniel: “ASIGNACIÓN DE PRIORIDADES EN LA AYUDA SOCIAL MEDIANTE ELECTRE”.COINI 2014: VII Congreso Argentino de Ingeniería Industrial / Cesar Bustelo... [et.al.]. - 1a ed. - Ciudad Autónoma de Buenos Aires: edUTecNe, 2015. E-Book ISBN 978-987-1896-39-4. UTN FRCH, PuertoMadryn, CHUBUT, Argentina. 30 y 31 de octubre de 2014.
[48] Illescas, Gustavo; Etchepare, Juan F.; Dos Reis, María R.; Bueno, Moisés E.:”APLICACIÓN DE MÉTODOS MATEMÁTICOS PARA DAR SOPORTE A LA TOMA DE DECISIONES MULTICRITERIO. PROYECTO KOINONÍA”. Anales XXVII Encuentro Nacional de Docentes en Investigación Operativa y XXV Escuela de Perfeccionamiento en Investigación Operativa / José Luis Vivas... [et.al.] ; compilado por Enrique Gabriel Baquela; coordinado por Patricia A. Iñiguez y Silvia Adriana Ramos. – 1a ed. - Tandil: Escuela de Perfeccionamiento en Investigación Operativa, 2014. E-Book ISBN 978-987-24267-5-0. San Nicolás, Argentina. Mayo 2014.
[49] Xodo, Daniel; Bueno, Moisés; Illescas, Gustavo; Dos Reis, María Rosa: “INGENIERÍA DEL CONOCIMIENTO EN LA AYUDA SOCIAL”. Memorias del XIV Whorkshop de Investigadores en Ciencias de la Computación. WICC 2012. Posadas, Misiones, Argentina, 26 y 27 de abril de 2012. [50] PRESENTACIÓN ASOCIACIÓN CIVIL PROYECTO KOINONIA y HERRAMIENTAS DE SERVICIO TECNOLÓGICO ORGANIZACIONAL (1ra, 2015, Tandil, Buenos Aires, Argentina). Presentación Asociación Civil. AUDITORIUM DE OSDE, Avenida Santamarina 451, 3° Piso, Tandil, Buenos Aires. 2015.
[51] Diccionario de Trabajo Social.10a edición, España. Ander-Egg, Ezequiel. 1984.
[52] “El Trabajo Social en la zona del Besés”, Revista de Trabajo Social. Montserrat Colomer (1983).
[53] INTRODUCCION AL BIENESTAR SOCIAL. De las Heras y Cortajarena (1979).
[54] Dos Reis, María Rosa; Trotti, Marcos; Bueno, Moisés; Illescas, Gustavo: “Un enfoque Genético como Asistente para la toma de decisiones en situaciones de Emergencia – PROYECTO KOINONÍA”. Anales del XXIX ENDIO - XXVII EPIO. Libro Digital PDF ISBN 978-987-24267-7-4. Buenos Aires, Argentina. 2016
[55] Las Redes Inter-Organizacionales y el Desarrollo de las ONGs de Base Estudios de Caso en el Gran Buenos Aires durante la década del 0 por Pablo Forni. Buenos Aires, DIC/2002.
[56] Las Redes Inter-Organizacionales y sus implicancias en el desarrollo de las Organizaciones Comunitarias de los Pobres y Excluidos. Estudios de Caso en el Gran Buenos Aires (1985-2000).
[57] Sitio Web: https://www.dc.uba.ar/materias/aa/2011/cuat2 Fecha de consulta: Febrero 2017
[58] LA MINERÍA DE DATOS, ENTRE LA ESTADÍSTICA Y LA INTELIGENCIA ARTIFICIAL. TOMAS ALUJA. Universitat PolitÉcnica de Catalunya. QUESTII O´, vol. 25, 3, p. 479-498, 2001.
[59] Sitio Web: http://www4.ujaen.es/~aespadas/TEMA1.pdf Fecha de consulta: Marzo 2017. [60] Sitio Web: http://definicion.de/escala-de-glasgow/ Fecha de consulta: Marzo 2017.
