Universidad Nacional del Centro de la Provincia de Buenos Aires Facultad de Ciencias Exactas - Departamento de Computación y Sistemas
Una herramienta web
para el Análisis Morfométrico Resistente
Trabajo Final de Carrera para acceder al título
de Ingeniero de Sistemas
Autor:
Guillermo Andrés Pacheco
Director: Viviana Ferraggine
Agradecimientos
Quiero agradecerle a mi familia el amor y el apoyo incondicional que me brindaron a lo largo de la carrera: me inculcaron desde pequeño el valor de los estudios y por eso he llegado a este lugar. A mi hijo, que es el motor de mi vida. No puedo dejar de agradecerles a los compañeros de cursada y conocidos en general con quienes compartí éstos años de carrera; su compañía, su apoyo y los lindos momentos compartidos enriquecieron este recorrido. Finalmente, quiero agradecer la directora y al codirector de este trabajo final por su paciencia, su ayuda y su guía en la realización del mismo. A todas éstas personas, mi más sincero agradecimiento.
INDICE GENERAL
CAPÍTULO 1: INTRODUCCIÓN 5
1.1 Motivación y Descripción del Problema 1.2 Objetivos
1.3 Metodología
1.4 Estructura del Documento
CAPÍTULO 2: MARCO TEÓRICO 8
2.1 Morfometría Geométrica
2.1.1 Landmarks, Datos Morfométricos, Forma 2.1.2 Superposiciones Procrustes
2.1.2.1 Superposición Procrustes por Cuadrados Mínimos (SPCM) 2.1.2.2 Superposición Procrustes Resistente (SPR)
2.1.3 Distancias Morfométricas
2.1.3.1 Distancia Procrustes 2.1.3.2 Distancia Resistente
2.1.4 Ordenamientos
2.2 Consideraciones sobre Softwares Morfométricos 2.3 RPS Desktop, Nuevas Funcionalidades y Entorno Web
CAPÍTULO 3: TECNOLOGÍAS UTILIZADAS 17
3.1 Introducción
3.2 Entorno de Capacidades Estadísticas y Gráficas 3.3 Tecnología de Base de Datos
3.4 Frontend
3.4.1 ReactJS 3.4.2 AngularJS
3.4.3 Librerías Gráficas Javascript
3.6 Backend
3.6.1 .NET Core 3.6.2 NodeJS
3.7 Web Services 3.8 Shiny de R Studio
CAPÍTULO 4 : DESARROLLO 27
4.2 RPS Package
4.2.1 Entorno de Desarrollo 4.2.2 Rutinas Principales
4.2.3 Documentación de R Package
4.3 Modelo de Datos
4.3.1 Descripción de Campos JSON
4.4 RPS Services
4.4.1 Gestión de Solicitudes 4.4.2 Módulos de Procesamiento
4.4.2.1 ParseJSON
4.4.2.2 PlotlyGenerator (GraphicsJSONGenerator) 4.4.2.3 R_Module
4.4.3 Gestión de Sistema de Archivos 4.4.4 Acceso a la Base de Datos
4.4.5 Funcionamiento Integral de RPS Services
4.5 RPS Frontend
4.5.1 Entorno de Desarrollo de la Aplicación Web 4.5.2 Desarrollo
4.5.2.1 Vista de Módulos 4.5.2.2 Vista de Componentes
4.5.3 Servicios AngularJS
CAPÍTULO 5 : MEJORAS Y TESTEO 46
5.1 RPS Online vs. RPS Desktop
5. 2 Test de Precisión del RPS Package 5.3 Test de Compatibilidad de RPS Online
1.1 Motivación y Descripción del Problema
La morfometría se ocupa del análisis cuantitativo de la forma de organismos y estructuras biológicas, valiéndose de herramientas matemáticas y estadísticas. El enfoque actual para describir la variación de una forma biológica es relativamente reciente: en la década del noventa tuvo lugar la llamada la revolución morfométrica
(Rohlf y Marcus, 1993; Adams et al., 2004), en la que los métodos matemáticos y geométricos se fusionaron con la estadística multivariada para constituir un área disciplinar específica conocida como el análisis estadístico de la forma.
En este contexto, morfometría geométrica utiliza para el estudio de una forma biológica las coordenadas cartesianas en 2D o 3D de puntos anatómicos denominados landmarks cuya característica distintiva es la homología: éstos puntos pueden ser claramente identificados y registrados por un especialista -biólogo, antropólogo, médico, etc.- en todos los organismos cuya forma se quiere analizar y/o comparar. Así, la MG representa una forma mediante un conjunto o
configuración de landmarks que captura la geometría del organismo biológico estudiado. Y la comparación de dos o más formas se realiza superponiendo de manera óptima las configuraciones que las representan.
En las últimas décadas los métodos de la MG se han convertido en estándares en disciplinas como la biología y la antropología. Sin embargo, la mayoría de los softwares morfométricos desarrollados desde entonces como MorphoJ (Klingenberg, 2011), Geomorph (Adams y Otárola Castillo, 2013) y la serie‐
TPS (Rohlf, 2015) entre otros, han implementado casi exclusivamente métodos de superposición basados en cuadrados mínimos dejando de lado las alternativas
resistentes (Siegel y Benson, 1982; Rohlf y Slice, 1990; Slice, 1996; Torcida et al.,
2014). Estas últimas ofrecen mejores resultados cuando existen errores, datos atípicos o outliers, facilitando la interpretación biológica de los resultados pese a su mayor costo computacional. La ausencia de herramientas de software de uso masivo que incluyan el enfoque resistente es por lo tanto evidente.
Para promover en la comunidad morfométrica el uso de algoritmos resistentes en el estudio de formas biológicas en 3D empleando landmarks, se desarrolló recientemente la herramienta de software de escritorio RPS: Resistant
Procrustes Software (Ferraggine et al., 2017) en Java; será mencionada como RPS
Desktop de aquí en adelante. RPS Desktop tiene una implementación sencilla y
permite el análisis de uno o más datasets (conjunto de configuraciones de landmarks cuya forma se quiere estudiar) dentro de un mismo proyecto. Después de haber sido usada un tiempo, se detectó la conveniencia de incorporar en RPS Desktop la persistencia de datos e integrarla con algún paquete estadístico. Se evaluó entonces desarrollar una herramienta web con las funcionalidades existentes, los agregados y con la posibilidad de ser colaborativa.
1.2 Objetivos
En este trabajo se describe el proceso de desarrollo e implementación en el entorno web RPS Online de las funcionalidades existentes en RPS Desktop, integrándolas con un motor de bases de datos y con un framework de capacidades estadísticas y gráficas. Los objetivos fueron:
• construir un modelo de datos genérico que para cada usuario soporte el
almacenamiento de sus proyectos, los datasets/landmarks/etc.
correspondientes y los resultados de los análisis realizados;
• integrar las funcionalidades estadísticas, gráficas, de análisis y de almacenamiento en una herramienta web que permita realizar un estudio morfométrico descriptivo con el enfoque resistente;
• incorporar a las funcionalidades de RPS Desktop la posibilidad de:
› aumentar o disminuir la cantidad de objetos y/o de landmarks a analizar; › importar y exportar datos morfológicos desde y hacia la base de datos,
partiendo de diferentes fuentes;
1.3 Metodología
En este trabajo se empleó un enfoque ágil: un desarrollo iterativo e incremental donde los requisitos y soluciones fueron evolucionando de acuerdo a las necesidades del proyecto. Inicialmente no resultaba claro cómo integrar una aplicación web con un framework de capacidades estadísticas y gráficas; éste y otros aspectos fueron definiéndose en el proceso. El análisis de alternativas, las consultas con usuarios representativos de la comunidad morfométrica y las discusiones con los directores fueron permanentes.
1.4 Estructura del Documento
Este documento está organizado de la siguiente manera:
• En el Capítulo 2 se describe brevemente el enfoque de la morfometría
geométrica para el estudio de las formas biológicas y también los análisis
morfométricos que se implementan en RPS Online.
• En el Capítulo 3 se describen las tecnologías de software utilizadas para el desarrollo del sistema, incluyendo las que fueron descartadas.
• En el Capítulo 4 se explica el desarrollo del sistema y su estructura/arquitectura final. Se describen la arquitectura, el modelo de datos y los componentes de la aplicación. Y se mencionan los cambios introducidos respecto a la planificación original.
• En el Capítulo 5 se detallan las funcionalidades y facilidades con las que cuenta el sistema, explicando a grandes rasgos su modo de uso. Y se mencionan los resultados obtenidos en los testeos.
2.1 Morfometría Geométrica
La morfometría geométrica (MG) alude al enfoque surgido en la década del
noventa en el que la forma de un organismo es representada mediante las coordenadas cartesianas de una configuración o conjunto de landmarks. Los landmarks fueron inicialmente utilizados para el estudio de formas en 2D, pero su uso en 3D se ha vuelto progresivamente más frecuente a partir del avance tecnológico y de la disponibilidad de imágenes de diverso tipo: tomografías computadas, resonancias magnéticas, etc.
2.1.1 Landmarks, Datos Morfométricos, Forma
Los landmarks se definen como puntos anatómica o geométricamente
homólogos entre estructuras u organismos. Como se describe en (Bookstein, 1991)
pueden distinguirse tres tipos de landmarks (Fig. 1):
Tipo I: son puntos que cuentan con mayor evidencia biológica de su homología. Por ejemplo, una yuxtaposición de tejidos o una sección pequeña de características histológicas inusuales;
Tipo II: son puntos cuya homología sólo se sostiene con evidencia geométrica y no histológica. Por ejemplo, puntos de máxima curvatura;
Tipo III: son puntos con al menos una coordenada ambigua. Por ejemplo, los extremos de un diámetro máximo o el punto inferior de una concavidad. Estos landmarks suelen caracterizar a más de una región de la estructura, condicionando las interpretaciones geométricas o biológicas sobre ellos. Debido a la naturaleza algo imprecisa de éste tipo de landmarks, Bookstein (1996) revisó su clasificación original y denominó semilandmarks a éste grupo.
En el ámbito de la llamada morfometría tradicional, la forma de un organismo era caracterizada y estudiada a través del registro de medidas lineales (Marcus, 1990; Fig. 1, B). El problema de éste tipo de medidas (el largo máximo y el ancho
mínimo son algunos ejemplos típicos) es que no hacían referencia a la homología
la configuración espacial y geométrica de la estructura subyacente (Adams et al., 2004; Slice, 2007).
El enfoque de la MG intentó superar los inconvenientes de la morfometría tradicional al registrar y analizar las coordenadas cartesianas de los landmarks
(Bookstein, 1991; Fig. 1, A). El criterio de homología biológica que sustenta la MG establece una restricción para elegir los puntos que se consideran informativos en términos de la forma de un organismo: los puntos seleccionados deben permitir realizar inferencias (Zelditch et al., 2004). Al mismo tiempo, esa restricción contribuye a reducir el error de medición: se utilizan puntos claramente reconocibles y presentes en todos los organismos que es estudian.
A finales de la década del setenta se postuló una definición bastante precisa de la forma: es aquella información geométrica de una estructura u organismo que permanece luego de filtrar los efectos de su posición, su escala y su orientación
(Kendall, 1977). Comenzó entonces una renovación significativa en el estudio de las formas biológicas como consecuencia del desarrollo de los métodos basados en las coordenadas cartesianas de puntos (Rohlf y Marcus, 1993; Adams et al., 2004; Gunz et al., 2005).
La MG representa una forma biológica mediante una configuración de landmarks: una matriz n x p en la que se almacenan las coordenadas cartesianas de
n landmarks en p=2 ó p=3 dimensiones. Estudios biológicos y antropológicos emplean habitualmente landmarks para obtener información sobre la forma de estructuras fenotípicas y analizar su variación entre individuos, poblaciones y/ó especies (Goodall, 1991; Adams et al., 2004; Mitteroecker y Gunz, 2009). En
tiempos recientes, el análisis de la variación de la forma biológica se ha vuelto un tema de interés en campos tan diversos como la ecología y los estudios evolutivos (Bookstein, 1989, 1991, 1996) y existe consenso en que el enfoque de la MG está poniendo a la luz aspectos morfométricos no considerados previamente (Zelditch et al., 2004; Mitteroecker et al., 2005; Hallgrímsson y Lieberman, 2008)
2.1.2 Superposiciones Procrustes
Un paso intuitivo para comparar la forma de dos o más configuraciones de landmarks en el contexto de la MG es intentar superponer sus coordenadas cartesianas. Pero esto requiere elegir cuidadosamente el criterio a usar para realizar la superposición, ya que las diferencias de forma que se identifican dependen fuertemente del criterio empleado (Richtsmeier et al., 2002; Catalano y Goloboff, 2012).
A partir de la definición de Kendall resulta claro que la superposición óptima de distintas configuraciones de landmarks puede alcanzarse una vez que las diferencias en términos de posición, orientación y escala han sido filtradas. Las superposiciones que filtran tales diferencias conservando la forma se conocen como
superposiciones Procrustes; el nombre alude al posadero de la mitología griega que
forzaba a sus huéspedes a encajar en sus lechos estirándolos cruelmente o cortándoles sus piernas. Matemáticamente, una superposición Procrustes busca determinar la traslación, la rotación/reflexión y el escalamiento óptimos para sincronizar respectivamente la posición, la orientación y la escala de las configuraciones de landmarks cuyas formas se comparan (Fig. 2). Tales transformaciones geométricas dejan invariante la forma.
2.1.2.1 Superposición Procrustes por Cuadrados Mínimos (SPCM)
El criterio de superposición Procrustes más utilizado busca transformaciones que dejen invariante la forma de modo que la suma de las distancias euclideas al
cuadrado entre los landmarks correspondientes de las distintas configuraciones sea
mínima luego de la superposición: es la llamada superposición Procrustes por
cuadrados mínimos (SPCM, en lo que sigue).
Por su relativa simplicidad matemática y su eficiencia computacional, la SPCM es el método más difundido para el análisis de la forma usando landmarks. Sin embargo, es sabido que posee limitaciones: en particular, cuando las diferencias de forma no son homogéneas entre los landmarks (Richtsmeier et al., 2002; van der Linde y Houle, 2009). En estos casos el resultado de una SPCM suele conducir a interpretaciones erróneas: cuando las diferencias de forma son importantes pero están concentradas en unos pocos landmarks, la SPCM tiende a desparramarlas porque promedia la falta de ajuste (Rohlf y Slice, 1990; Slice, 1996); ésta es una característica de los métodos basados en cuadrados mínimos. En consecuencia, los cambios de forma relativos que tienen lugar en diferentes sectores de un organismo
suelen ser medidos y representado con poca precisión por una SPCM, quedando muchas veces enmascarados (Fig. 3, [fuente: Perez et al. 2012]).
Brevemente, la SPCM de k configuraciones de n landmarks en p=2 ó p=3 dimensiones consta de los siguientes pasos (los detalles matemáticos de éste método iterativo pueden encontrarse por ejemplo en Gower, 1975):
1. Centrar todas las configuraciones de modo que el landmark promedio en c/u de ellas sea el origen del sistema cartesiano. Calcular como configuración consenso (o pivote) el promedio de todas las configuraciones.
2. Realizar una superposición por cuadrados mínimos de cada configuración sobre la configuración consenso. Luego, calcular la nueva configuración consenso.
3. Si la diferencia entre el nuevo consenso y el consenso anterior supera la tolerancia estipulada, volver al paso 2. Caso contrario, la convergencia se considera alcanzada y se da por terminado el algoritmo.
Aunque existen diversos paquetes estadísticos pagos que permiten realizar una SPCM, ésta funcionalidad ha sido incorporada a la aplicación RPS Online para permitir la comparación de los resultados del método más popular con los del método resistente que se intenta difundir.
2.1.2.2 Superposición Procrustes Resistente (SPR)
Diversas alternativas han sido propuestas en la literatura para sortear los defectos de la SPCM (Rohlf y Slice, 1990; Richtsmeier et al., 2002; van der Linde y Houle, 2009). Entre ellas, la superposición Procrustes resistente basada en
medianas repetidas (Siegel y Benson, 1982) es probablemente la más elegante y
entonces el mejor ajuste para a la mayoría de los landmarks, sin verse afectada por grandes variaciones en unos pocos puntos. Es importante mencionar que luego de una SPR las diferencias de forma localizadas son capturadas con mayor eficacia y precisión, facilitando su interpretación biológica (Siegel y Benson, 1982; Torcida et al., 2014). En (Torcida et al., 2014) se presenta una extensión de la SPR basada en medianas repetidas de (Siegel y Benson, 1982) que para comparar la forma de más de dos configuraciones de landmarks en 3D, además de 2D. El nuevo algoritmo reduce significativamente la complejidad computacional de la propuesta de (Slice, 1996) al reducir su complejidad combinatoria; por otro lado, se ofrece ahora una prueba de la optimalidad del algoritmo que no existía anteriormente. La nueva SPR utiliza como configuración consenso resistente aquella cuyos landmarks resultan las
medianas espaciales o geométricas (Weiszfeld, 1937) de los landmarks
correspondientes de las configuraciones cuyas formas se desean comparar.
Brevemente, la SPR para k configuraciones de n landmarks en p=2 ó p=3 dimensiones consta de los siguientes pasos (Torcida et al., 2014):
1. Llevar a cabo una SPCM para contemplar reflexiones, en caso de que fueran necesarias. Esta superposición inicial facilita además la estimación de la rotación resistente.
2. Calcular como configuración consenso la configuración cuyos landmarks son las medianas espaciales de los landmarks correspondientes de todas las configuraciones.
3. Realizar una superposición resistente de cada configuración sobre la configuración consenso. Luego, calcular la nueva configuración consenso.
4. Si la diferencia entre el nuevo consenso y el consenso anterior supera la tolerancia estipulada, volver alpaso 2. Caso contrario, la convergencia se considera alcanzada y se da por terminado el algoritmo.
Este algoritmo ha sido implementado en RPS Online, constituyendo su principal funcionalidad morfométrica.
2.1.3 Distancias Morfométricas
2.1.3.1 Distancia Procrustes
Cuando las configuraciones de landmarks han sido superpuestas a por una SPCM, la magnitud de las diferencias de forma entre dos configuraciones es estimada mediante la raíz cuadrada de la suma que ha sido minimizada: la suma de las distancias euclideas al cuadrado entre los landmarks correspondientes. Esta magnitud se conoce habitualmente como distancia Procrustes y ha sido implementada en RPS Online.
2.1.3.2 Distancia Resistente
La SPR no resulta de un proceso de optimización (minimización o maximización) y por lo tanto no existe una distancia naturalmente asociada a dicha superposición. En (Torcida et al, 2014) se propone como distancia razonable para medir las diferencias de forma luego de realizar una SPR a la suma de las distancias euclideas no cuadradas entre los landmarks correspondientes. Ésta distancia ha sido también implementada en RPS Online.
2.1.4 Ordenamientos
Luego de obtener una superposición Procrustes y de haber medido las diferencias de forma resultantes mediante una distancia, es habitual graficar a cada configuración de landmarks como un punto en 2D o en 3D de modo que la distancia entre cada par de puntos represente lo mejor posible la distancia morfométrica
correspondiente. Éste gráfico se conoce como escalamiento multidimensional (MDS, por sus siglas en inglés) u ordenamiento de las configuraciones y facilita la visualización de las diferencias de forma. Siguiendo (Torcida et al, 2014), en RPS Online se implementaron dos versiones del escalamiento multidimensional universal (UMDS) propuesto en (Agarwal, 2010): una por cuadrados mínimos (lsUMDS) y otra resistente (rUMDS).
2.2 Consideraciones sobre Softwares Morfométricos
contexto anatómico inmediato como desplazamientos relativos de los landmarks. La evolución de los recursos gráficos en la informática permite entonces visualizar la variación de la forma biológica en 2D y 3D de manera atractiva.
Los softwares morfométricos más utilizados actualmente se ejecutan bajo distintas plataformas (Microsoft, Mac, Linux). Existen diversas opciones, gratuitas o pagas. En algunos casos se trata de aplicaciones de escritorio, que requieren la descarga del programa y el uso de los recursos de la máquina del usuario; en otros casos se trata de frameworks que necesitan de un conocimiento específico de parte del usuario. Algunas de las aplicaciones más populares son:
➢ Geomorph (Adams, 2013): desarrollado en el entorno R, es un package gratuito y abierto que cubre todas las etapas del análisis de datos basados en landmarks. Entre otras funcionalidades, incluye rutinas para: la lectura, la manipulación y la digitalización de datasets en 2D y 3D; el análisis estadístico de la variación y la covariación de la forma; la visualización de las formas analizadas y de sus patrones de variación, etc.
➢ Morpho (https://cran.r-project.org/web/packages/Morpho/index.html): está desarrollado en R por S. Schlager y proporciona un conjunto de herramientas para la morfometría geométrica y el procesamiento de mallas. Incluye la deformación de mallas en base a puntos de referencia; pruebas de permutaciones; la detección de outliers; etc.
➢ MorphoJ (Klingenberg, 2011): ésta aplicación gratuita desarrollada en Java permite extraer información de formas biológicas en 2D y 3D a partir de la superposición Procrustes, ofreciendo análisis multivariados clásicos como componentes principales y análisis discriminante e incluyendo herramientas filogenéticas y de modularidad. La aplicación requiere que se instale Java Runtime Enviroment en el sistema operativo de la máquina a trabajar. Carece de una interfaz gráfica iteractiva en 3D.
➢ TPS Series (Rohlf, 2015): ésta serie de programas se inició a principios de los noventa bajo un entorno MS-DOS, migrando luego a las nuevas versiones de Windows. El desarrollo de aplicaciones especializadas en lugar de un software integral buscó acortar los plazos para ofrecer una herramienta de software para el análisis morfométrico.
ocasiones) y un navegador; no requiere instalación y utiliza la última versión estable disponible. Estas consideraciones impulsaron el desarrollo de una aplicación web.
2.3 RPS Desktop, Nuevas Funcionalidades y Entorno Web
Como se ha mencionado este trabajo está basado en RPS Desktop, una versión de escritorio muy similar descripta en (Ferraggine et al., 2017). La aplicación premite un análisis resistente de la forma a partir de configuraciones de landmarks en 2D y 3D. Y consiste en una herramienta Java de código abierto con una interfaz de usuario bien diseñada, amigable y personalizable.
De la versión de escritorio se conservan: todas las funcionalidades morfométricas, la creación de proyectos, la carga de datasets en los diferentes formatos (.tps, .nts, .txt); la eliminación de datasets y/o análisis de un proyecto; la eliminación de objetos y/o landmarks; la visualización en 2D y 3D.
3.1 Introducción
Internet está presente en todos los aspectos de la vida diaria y las tecnologías web son de uso cotidiano: buscar información, leer noticias, mirar televisión, participar de las redes sociales, etc. Basta ingresar una dirección URL y hacer un click para poder acceder al contenido buscado cuando se desee, en dispositivos móviles y en computadoras. En este contexto se pretende inaugurar el uso de herramientas de la MG en un entorno online. Las principales ventajas de una arquitectura web respecto a una standalone como RPS Desktop están asociadas con:
• la compatibilidad multiplataforma: su uso es independiente del dispositivo empleado;
• la actualización: se mantienen actualizadas a la última versión. El proceso es
automático y por lo tanto la actualización no necesita ser descargada, instalada o configurada por el usuario;
• el requerimiento de memoria: tienen una menor demanda de memoria RAM
de parte del usuario, comparadas con el software instalado localmente;
• el manejo de errores: son menos propensas a crear conflictos del software o
del hardware con otras aplicaciones del usuario. Los errores pueden ser corregidos en cuanto son descubiertos;
• la facilidad de uso: son accesibles desde cualquier lugar, desde una PC o
portátil, desde un móvil o una tablet y desde cualquier lugar físico con conexión a internet.
En el desarrollo de la aplicación web dos de las tecnologías estaban prefijadas: i) el uso de una aplicación de capacidades estadísticas y gráficas que al combinarse con las funcionalidades morfométricas permitiera elaborar un paquete autocontenido, y ii) para hacer posible la persistencia de los datos, el uso de una base de datos. En las próximas dos secciones se describen las características de
ambas tecnologías; posteriormente, se analizan opciones contempladas para el desarrollo del Frontend y del Backend de la aplicación web.
3.2 Entorno de Capacidades Estadísticas y Gráficas
En el ambiente morfométrico la herramienta de capacidades estadísticas y gráficas más utilizada es R: (https://www.r-project.org/).
surgió como un entorno y un lenguaje de programación directamente enfocado en análisis estadísticos y en gráficos. Fue desarrollado inicialmente por R. Gentleman y R. Ihaka de la Universidad de Auckland en 1993 y actualmente es responsabilidad del denominado R Development Core Team, quien monitorea el esfuerzo colaborativo permanente en el que personas de todo el mundo hacen sus contribuciones. se encuentra disponible bajo los términos de una licencia GNU de la Free Software Foundation en forma de código fuente. Se compila y ejecuta en una amplia variedad de plataformas como UNIX, FreeBSD, Linux, Windows y Mac. Como lenguaje de código abierto es relativamente accesible tanto para los principiantes como los para usuarios experimentados. Actualmente es uno de los lenguajes más utilizados en investigación para los análisis estadísticos; en particular, es muy popular en campos como la minería de datos, la bioinformática, la matemática financiera y la morfometría. Una explicación probable es que permite descargar bibliotecas o packages específicos con las funcionalidades de cálculo y gráficas deseadas a las que contribuyen aportantes de todo el mundo. La unidad fundamental del código compartible en es el package: éste agrupa el código, los datos, la documentación y los ejemplos de uso. En enero de 2015 había más de 6.000 packages disponibles en el CRAN (Comprehensive R Archive Network, el repositorio público de packages ).
resulta una plataforma atractiva para el estudio de la variación de la forma de objetos en 2D y en 3D, con herramientas que van desde la carga de datos hasta la producción de gráficos estáticos e interactivos y análisis estadísticos diversos.
3.3 Tecnología de Base de Datos
Para lograr la persistencia de datos en la aplicación web resulta natural utilizar una base datos. El motor de almacenamiento establecido fue PostgreSQL
al estándar SQL y soporta un gran volumen de datos. Se describen brevemente a continuación sus características más relevantes.
es un potente sistema de base de datos objeto-relacional y de código abierto que utiliza y amplía el lenguaje SQL. Se ha ganado una sólida reputación por su arquitectura, por el mantenimiento de la integridad de los datos, por su conjunto robusto de funciones y porque ofrece soporte seguro a grandes cargas de trabajo. Cabe mencionar además la dedicación de la comunidad de código abierto que colabora y contribuye con el mantenimiento y el desarrollo del software.
es altamente escalable, tanto por la cantidad de datos que puede gestionar como por la cantidad de usuarios concurrentes.
Otra característica fundamental de es que ofrece una gran variedad de tipos de datos estándares y de tipos semiestructurados como XML, JSON y JSONB (éste último disponible a partir de la versión 9.4); JSON está basado en sintaxis Javascript. En el contexto de éste trabajo, la opción de emplear tipos de datos semiestructurados para almacenar los datasets y evitar así el overhead de preprocesamiento condujo a la elección de un gestor de bases de datos pos-relacionales como que ofrece escalabilidad y tiempos de respuesta superiores a los ofrecidos por sistemas relacionales (Vazquez Ortiz et al. 2016). ha ido incorporando gradualmente características NoSQL lo que permitió prescindir de una tercera herramienta.
3.4 Frontend
Para el desarrollo de la interfaz de usuario se consideraron diversas tecnologías en auge, con sus virtudes y sus falencias. En la decisión se priorizó que las tecnologías elegidas pudieran complementarse tanto con el entorno como con el motor de base de datos y que facilitaran el desarrollo de la aplicación. A continuación se describen brevemente las opciones analizadas.
3.4.1 ReactJS
ReactJS (www.reactjs.org) es una librería Javascript de código abierto,
y modularidad, a la vez que promueve un flujo muy claro de datos y eventos facilitando la planificación y el desarrollo de aplicaciones complejas.
permite desarrollar aplicaciones web con mayor orden y con menos líneas de código que Javascript puro o que librerías como jQuery centradas en la manipulación del DOM (Document Object Model) para la representación de documentos. permite que las vistas se vinculen con los datos: las vistas cambian al cambiar los datos. Como el típico marco de binding y doble binding ralentizaba la aplicación debido a la cantidad de conexiones entre las vistas y los datos, se creó una nueva dinámica de funcionamiento que optimizó la renderización de las vistas ante los cambios en los datos de la aplicación.
mantiene un DOM virtual propio en lugar de depender exclusivamente del DOM del navegador; la biblioteca puede determinar qué partes del DOM se han modificado, comparando los contenidos de la versión nueva con los de la versión almacenada en el DOM virtual y en base a ello determinar cómo actualizar eficientemente el DOM del navegador.
posibilita un desarrollo basado en componentes reutilizables. Antes de desarrollar sobre conviene buscar si ya existe algún componente que realice la tarea deseada; pueden encontrarse componentes simples como botones, sliders, tooltips, etc.
3.4.2 AngularJS
AngularJS (www.angularjs.org) es un conjunto de librerías apoyadas por
Google. Una oleada de sistemas ha situado recientemente a Javascript en otro nivel: BackboneJS, EmberJS y entre otros. Estos frameworks aportan herramientas y patrones de diseño con los que Javascript se convierte en un lenguaje capaz de servir como motor de grandes aplicaciones. Anteriormente los servidores tenían que enviar el HTML completo al cliente; ahora la tendencia es que solo envíen los datos y que el cliente, un navegador o cualquier otro sistema donde se deseen ver esos datos, sea el que los manipule y los muestre debidamente.
transferir datos simples que el HTML completo. En definitiva, el servidor reparte su carga de trabajo entre todos los clientes que se conectan al web service. Las aplicaciones cliente/servidor van logrando así un desempeño similar al de las aplicaciones de escritorio: se les demanda que sean rápidas y eso se logra empleando frameworks como .
Al desarrollador también se le facilitan las cosas, no sólo porque dispone de un conjunto de librerías sino que además los frameworks están asociados a un conjunto de paradigmas y patrones que facilitan la elaboración del software y sobre todo su mantenimiento (Model View Controler, MVC). Cada parte del código se sitúa en un lugar específico y ese orden hace el desarrollo más manejable, lo que se traduce en una mejor calidad del código.
Por todo lo anterior, representa una alternativa muy atractiva como framework para el desarrollo de una aplicación web. La Fig. 4 describe el funcionamiento general de .
3.4.3 Librerías Gráficas Javascript
La visualización de los datos es un aspecto central en la MG y por ello se evaluaron alternativas basadas en librerias Javascript: chart.js, Plotly y three.js.
• chart.js tiene gran popularidad como librería de código abierto al contar con varios tipos de gráficos diferentes, una buena performance en la mayoría de los navegadores y la capacidad de adaptarse al dispositivo donde se
visualiza. Sin embargo, ésta alternativa fue descartada ya que no permite realizar gráficos en 3D.
• three.js es conocida por su gran potencia en visualizaciones y animaciones
3D. Admite una gran variedad de gráficos y es lo suficientemente flexible para manipular cualquier tipo de dato. Utiliza la API Javascript WebGL y admite la aceleración GPU cuando el usuario cuenta con ese recurso. La potencia de la librería excede las funcionalidades básicas que éste trabajo necesita y su uso requiere de un entrenamiento importante, por lo que fue descartada.
• Plotly.js es una librería de código abierto que brinda soporte para Javascript, Python y R (entre otros lenguajes) y que también utiliza WebGL. Permite crear gráficos muy flexibles en el servidor cuando se utiliza el tipo de dato JSON, los que luego serán visualizados en el navegador. Es fácil de integrar con distintos frameworks (AngularJS, por ej.).
3.6 Backend
Los análisis morfométricos requieren procesar un gran caudal de datos, tanto para realizar los cálculos matemáticos como para generar los gráficos en 2D y en 3D. Por este motivo se buscó un backend acorde que responda a las solicitudes del cliente en tiempos razonables y que soporte la carga de procesamiento requerida. Se consideraron tecnologías tales como: .NET Core, NodeJS y Shiny Studio, que se describen brevemente a continuación.
3.6.1 .NET Core
.NET Core es una implementación de .NET Standard
(www.microsoft.com/net) para uso general, modular, multiplataforma y de código abierto. Contiene muchas de las API de .NET Framework, aunque .NET Core es un conjunto más pequeño que incluye: componentes del entorno en tiempo de ejecución, un marco de trabajo, un compilador y herramientas que admiten diversos
sistemas operativos (SO).
Existen principalmente dos modos de desarrollo en : una implementación basada en framework y una implementación autocontenida, con una instalación mínima. En lugar de un gran ensamblado, está disponible en paquetes centrados en las características necesarias. Se consigue así un modelo de desarrollo más ágil y optimizado, de mantenimiento económico.
3.6.2 NodeJS
Concebido como un entorno de ejecución de JavaScript de código abierto, ejecutable en diversos SO y orientado a eventos asíncronos, NodeJS
(www.nodejs.org) está diseñado para construir aplicaciones en red escalables. Este entorno del lado del servidor utiliza el motor V8 desarrollado por Google para su navegador Chrome. El motor permite compilar y ejecutar Javascript a velocidades increíbles; tal velocidad es debida a que V8 compila Javascript en código de máquina nativo, en lugar de interpretarlo o ejecutarlo como bytecode.
En el modelo de concurrencia más común hoy en día se usan threads del SO; las operaciones de redes basadas en threads son relativamente ineficientes y más difíciles de usar. Cuando una aplicación necesita realizar un bloqueo
(operaciones de entrada/salida) envía una tarea asíncrona al event-loop (bucle de eventos) junto con un callback y luego continúa. Para escalar grandes volúmenes de clientes, todas las operaciones intensivas de bloqueo en se llevan a cabo de forma asíncrona. En términos de la administración de memoria, cada conexión dispara la ejecución de un evento dentro del proceso del motor. La Fig. 5 resume la dinámica.
3.7 Web Services
Si se busca un entorno de desarrollo con componentes cuya modificación sea sencilla y económica, utilizar un web service (https://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice) es una alternativa apropiada: se trata de un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones.
Un web service aporta interoperabilidad: distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes y ejecutadas sobre plataformas diversas pueden utilizar un web service para intercambiar datos en redes como internet. Un web service es una función que envía parámetros al servidor y éste responde a la petición. Los web services fomentan los estándares y protocolos basados en texto, facilitando el acceso a su contenido y permitiendo comprender su funcionamiento. Pueden sacar provecho de los firewalls, al estar basados en HTTP.
En la actualidad, para describir una interfaz entre sistemas que utilicen directamente HTTP en la obtención de datos o para indicar la ejecución de operaciones sobre los datos en cualquier formato (XML, JSON, etc.) se utiliza
REST. Como característica particular, REST no necesita de las abstracciones adicionales de aquellos protocolos basados en patrones de intercambio de mensajes: es más fácil de usar, más eficiente, más rápido y más flexible.
3.8 Shiny de R Studio
Shiny de R Studio surgió en la búsqueda de una herramienta que permita
3.9 Decisiones de Implementación
La evaluación de las tecnologías mencionadas condujo a las siguientes decisiones:
• El entorno R fue elegido desde el comienzo para la implementación de las funcionalidades morfométricas por su versatilidad como entorno de capacidades estadísticas y gráficas. Como parte del proceso de desarrollo se decidió implementar RPS package, un R package en el que están incluidas todas las funcionalidades morfométricas de RPS Online.
• En un principio se contempló la utilización de una base de datos no relacional como MongoDB, Cassandra, etc. porque éstas permiten gestionar fácilmente tipos de datos JSON. Se optó por una base pos-relacional como PostgreSQL para gestionar la información de tipo relacional involucrada en los perfiles de usuario y en la administración de los proyectos. Como PostgreSQL soporta el tipo de dato no estructurado JSON, se decidió además explotar esta característica y sacarle provecho en la carga, en el almacenamiento y en la lectura de las estructuras que representan las matrices de datos de los datasets y sus análisis. La versión utilizada es la 9.5.7.
• De las tecnologías Frontend se seleccionó el framework de propósito general AngularJS en lugar de la librería ReactJS ya que el primero permite desarrollar íntegramente la aplicación web, es modularizable y tiene vistas dinámicas que se actualizan en tiempo real.
• Para la visualización de los gráficos se descartaron las librerias chart.js y three.js. La primera de ellas no brinda visualización en 3D, un aspecto clave para una aplicación que necesita soporte para datos en 3D. Por otro lado, three.js es un módulo Javascript de usabilidad compleja que no ofrece los gráficos específicos buscados para RPS Online. Plotly.js cubre las pretensiones de RPS Online con un código fácil de comprender y potenciado por WebGL, lo que mejora su performance. Fue la elegida.
4.1 Introducción
El desarrollo de la aplicación web combina el framework AngularJS que interactúa con un web service REST (NodeJS) encargado de la gestión de las funcionalidades que requiere cada usuario. Se implementó además un R package
que es el módulo de procesamiento de los análisis morfométricos del web service. El trabajo se llevó a cabo en tres etapas: la elaboración de RPS package, el desarrollo de la web y por último el testeo modular e integral de todo lo anterior.
La arquitectura del sistema (Fig. 6) describe la interacción de los cuatro componentes principales: RPS Package (el R package), el servidor de bases de datos (PostgreSQL), RPS Services (la API REST) y RPS Frontend (la aplicación AngularJS). Este último sólo se ocupa de la visualización de los datos y de los resultados, dado que es la API REST la encargada de intercambiar información con R y con el servidor de base de datos. A continuación se describe en detalle el desarrollo de cada uno de los componentes, los inconvenientes encontrados en ese proceso y el modo en el que fueron resueltos.
CAPÍTULO 4 : DESARROLLO
4.2 RPS package
Tal como se ha mencionado, la elaboración de RPS package tuvo un doble objetivo: que RPS Online lo utilice como módulo de procesamiento dentro del web service y además ponerlo a disposición de la comunidad R en general y de la comunidad morfométrica en particular. Por este motivo, al momento de su implementación se tuvieron en cuenta todos los requerimientos para su publicación en el repositorio oficial CRAN de R (https://cran.r-project.org/web/packages/policies.html).
De todas las funcionalidades morfométricas mencionadas en la sección 2.1, la SPCM fue resuelta utilizando un R package ya disponible en el CRAN (Geomorph). RPS package tiene también dependencias con otros R packages como Gmedian (que aporta rutinas especificas para un buen funcionamiento de las rutinas nuevas) y matlab (que ofrece funcionalidades presentes justamente en el software bajo licencia del mismo nombre).
Para la elaboración de RPS package se utilizaron dos módulos adicionales:
roxygen2 y devtools. roxygen2 se utiliza para escribir y estandarizar la documentación de los R packages: hace posible especificar para cada función los parámetros de entrada/salida, los autores, las funciones auxiliares, cuáles son las dependencias (si corresponde), etc. devtools, por su parte, permite: realizar las validaciones cuando se incorpora un R package al CRAN, generar los archivos .tar, generar los binarios de instalación y también realizar pruebas en entorno local, entre otras funcionalidades.
4.2.1 Entorno de Desarrollo
RStudio (Fig. 7) es un entorno de desarrollo código abierto que tiene incorporado un editor de texto, debugging y diversos templates para la construcción de R packages. Para poder utilizarlo fue necesario aprender el lenguaje R (conocer su sintaxis, su estructura de datos y su flujo de ejecución) antes de implementar RPS package.
El insumo de partida fueron los archivos fuente de los algoritmos resistentes que los autores de (Torcida et al. 2014) proporcionaron al autor de este trabajo en el lenguaje Matlab. Al tratarse de scripts elaborados en un lenguaje puramente científico y sin un conocimiento informático experto, se encontraron errores de codificación tales como: redundancias, sobredeclaración de variables, bucles repetitivos, etc. Se realizó entonces un refactoring y una optimización de todas las rutinas, a partir de la potencia de la sintaxis de R que sí está orientada al desarrollador de software.
4.2.2 Rutinas Principales
Las funcionalidades de la sección 2.1 implementadas en RPS package
fueron:
Nombre Descripción Entrada Salida
cmdistance_RPS Calcula la distancia Procrustes (CM) entre cada par de matrices del conjunto de entrada.
Un conjunto de matrices que representan los especímenes de un dataset.
La matriz de distancias Procrustes entre cada par de especímenes del conjunto de entrada.
resdistance_RPS Calcula la distancia resistente entre cada par de matrices del conjunto de matrices de entrada.
Un conjunto de matrices que representan los especímenes de un dataset.
La matriz de distancias resistentes entre cada par de especímenes del conjunto de entrada.
resunivMDS_RPS A partir de una matriz de distancias D se obtienen k puntos en 2D o en 3D tales que las distancias euclideas entre éstos puntos aproximan D en base a un criterio resistente.
Una matriz de distancias D de tamaño kxk. La dimensión p (2 ó 3) de los puntos que la representarán.
El conjunto de k puntos en p dimensiones cuyas distancias aproximan D (aprox. resistente).
eucunivMDS_RPS A partir de una matriz de distancias D se obtienen k puntos en 2D o en 3D tales que las distancias euclideas entre éstos puntos aproximan D en base a un criterio de CM.
Una matriz de distancias D de tamaño kxk. La dimensión p (2 ó 3) de los puntos que la representarán.
Nombre Descripción Entrada Salida
procrustesCM_RPS Esta función es una invocación a la función gpagen del R package geomorph que lleva a cabo la superposición Procrustes por CM del conjunto de matrices de entrada.
Un conjunto de matrices que representan los especímenes de un dataset.
Un conjunto de matrices que representan los especímenes luego de una superposición Procrustes por CM.
robgit_RPS Realiza la superposición Procrustes
resistente del conjunto de matrices de entrada.
Un conjunto de matrices que representan los especímenes de un dataset. Un valor lógico que indica si se devuelve la configuración de consenso.
Un conjunto de matrices que representan los especímenes luego de una superposición Procrustes resistente. Y la configuración consenso final (si corresponde).
readlandtxtMorphJ_ RPS
Lee un archivo MorphoJ .txt y lo devuelve como un conjunto de matrices que representan los especímenes de un dataset.
El path del archivo y La dimensión de los puntos (2 ó 3).
Un conjunto de matrices que representan los especímenes de un dataset.
Las rutinas principales requirieron además de la implementación de algunas rutinas secundarias:
Nombre Descripción Entrada Salida
Spmedcrudo Calcula la mediana espacial de lasfilas de la matriz de entrada. Una matriz cuyas filasrepresentan los mismos
landmarks de distintos especímenes.
Un vector que es la mediana espacial de las filas de la matriz de entrada
Spatialmed Calcula la mediana espacial de unconjunto de matrices. Un conjunto de matricesque representan los
especímenes de un dataset.
Una matriz cuyas filas son las medianas especiales de las respectivas filas de las matrices de entrada.
scaleSpecimen Ajusta la de escala de un conjuntode matrices respecto a su
consenso.
Un conjunto de matrices que representan los especímenes de un dataset y su matriz consenso.
Una conjunto de matrices con el ajuste de escala correspondiente.
rotation Estima la matriz de rotaciónresistente en 3D. Dos matrices en p (2 ó 3)dimensiones que
representan un espécimen y el consenso de un dataset.
El eje y el ángulo de la rotación resistente óptima entre las dos matrices de entrada.
initialFocus Centrado resistente de un conjuntode matrices. Un conjunto de matricesque representan los
especímenes de un dataset
4.2.3 Documentación de RPS Package
Una vez finalizado el desarrollo de RPS package se procedió a documentarlo, requisito para su aprobación y publicación en el repositorio público oficial CRAN.
Tal como se mencionó, los módulos auxiliares devtools y roxygen2
permitieron crear y estandarizar la estructura de la documentación de RPS package. Debió agregarse entonces a RPS package información sobre: los autores, el encargado de mantenerlo, la versión, los nombres de las funciones disponibles (incluyendo los parámetros de entrada y de salida) y las funciones de otros packages que es necesario importar para poder utilizar RPS package. Se generaron entonces los archivos Description y Namespace que a su turno producen la documentación final.
La validación de RPS package para su incorporación al repositorio CRAN contempló diversos intentos que incluyeron alertas y errores; las observaciones señaladas en cada intento fueron oportunamente analizadas y corregidas. En
https://cran.rproject.org/web/packages/RPS/index.html puede encontrarse la documentación
del RPS package oficial publicado, mientras que la documentación interactiva se encuentra disponible en https://www.rdocumentation.org/packages/RPS/versions/1.0. 1
4.3 Modelo de Datos
En el diseño de la estructura de los datos se partió de un Diagrama de Entidades y Relaciones Extendido (DERExt) e inicialmente se realizó una transformación física a un modelo puramente relacional. Posteriormente se observó que con dicho modelo físico los tiempos de respuesta en la carga y en los análisis de los dataset no resultaban óptimos.
La utilización del tipo de datos JSON contribuyó a mejorar sustancialmente el tiempo de respuesta; por otra parte, al implementar un web service REST el intercambio se realiza en JSON con correspondiente ventaja en la manipulación.
El esquema de la base de datos (Fig. 8) está compuesto por seis tablas:
Tabla Descripción
app_user contiene los datos de una cuenta de usuario.
country contiene las nacionalidades posibles de los usuarios del sistema
project contiene los datos de los proyectos de cada usuario
dataset contiene los datos de los dataset que integran un proyecto
distance contiene los datos de una matriz de distancias entre los especímenes de un dataset
ordination contiene los datos de un ordenamiento obtenido a partir de una matriz de distancias
Dado que el costo de los análisis resistentes en tiempo de procesamiento es alto y resulta proporcional al tamaño de los datatests, se optó por un procesamiento
asíncrono. Para atender a este aspecto clave se agregó en algunas tablas un campo send que es un flag. Éste flag distingue tres estados: los análisis en proceso (estado 0), los análisis finalizados y no visualizados (estado 1) y los análisis finalizados y visualizados (estado 2); se utiliza principalmente cuando un usuario inicia la sesión en RPS Online.
4.3.1 Descripción de Campos JSON
Dataset.data: sobre esta estructura se almacena la matriz que representa un dataset original o resultante de un análisis
data Arreglo de objetos, en el que cada elemento se identifica concatenando la palabra “specimen” y el número de orden correspondiente y se describe con sus landmarks.
excluded_land Landmarks excluidos del análisis (cuando corresponde)
excluded_obj Número de orden de los especímenes excluidos del análisis (cuando corresponde)
root_number_landmarks Cantidad de landmarks del dataset original (al eliminarlos a lo largo de sucesivos análisis es necesario guardarlos)
root_number_specimens Cantidad de especímenes del dataset original
Dataset.objects_name Distance.objects_name, Ordination.objects_name
objects_name almacena un arreglo conteniendo los nombres de los objetos en orden posicional con respecto a los datos almacenados en Dataset.data
Distance.data, Ordination.data
data almacena un arreglo que: para Distance corresponde a la matriz de distancias de un dataset y para Ordination corresponde a una matriz donde cada fila representa un punto del escalamiento.
Dataset.pdf, Distance.pdf, Ordination.pdf Respetan el formato proporcionado por la librería pdfMake (NodeJS).
Dataset.content [ {text: 'Procrustes Superimposition Report', style: 'header'}, {text: 'Type of Superimposition: '+params.algorithm}, {text: 'Data Dimension: '+params.dimention+'D'}, {text: 'Dataset Name: '+params.name},
{text: 'Source Dataset: '+params.original_name},
{text: 'Number of Objects: '+params.numbers_of_specimen }, {text: 'Number of Landmarks: '+params.numbers_of_landmark } //table ],
Distance.content [ {text: 'Distance Matrix Report', style: 'header'}, {text: 'Type of Distance: '+params.algorithm}, {text: 'Output Name: '+params.name},
{text: 'Source Dataset: '+params.original_name},
{text: 'Number of Objects: '+params.numbers_of_specimen } ],
Ordination.content [ {text: 'Ordination Report', style: 'header'},
{text: 'Type of Universal MDS: '+params.algorithm}, {text: 'Output Name: '+params.name},
{text: 'Source Distance Matrix: '+params.distance_name}, {text: 'Cartesian Coordinates: ', style: 'subheader'} ],
styles { header: { fontSize: 18, bold: true, margin: [0, 0, 0, 10] },
subheader { fontSize: 14, bold: true, margin: [0, 10, 0, 5] },
4.4 RPS Services
RPS Services es un web service realizado sobre la plataforma NodeJS que
brinda soporte a la aplicación web AngularJS. El desarrollo del servicio se realizó en Javascript plano de acuerdo al estándar JavaScript ECMA-262 specification, que
posee un diseño modularizado y proporciona el procesamiento asíncrono no bloqueante para las solicitudes que recibe. RPS Services consta de 4 capas:
gestión de solicitudes, módulos de procesamiento, gestión de entrada/salida y
acceso a la base de datos (Fig. 9). Las capas se describen a continuación.
4.4.1 Gestión de Solicitudes
En RPS Services se define el enrutamiento utilizando sentencias para responder a solicitudes GET o POST, según corresponda. Ambos métodos definen
callbacks (también conocidos como handler functions) que son invocados cuando la
aplicación recibe el request para una ruta específica (endpoint). La aplicación escucha las solicitudes y cuando consigue hacer matching con algún endpoint definido, ordena su ejecución. De esta manera se separa la gestión de solicitudes de la definición de routes, agrupando endpoints según la acción a realizar y el componente lógico que se utilice. Por ejemplo, en un mismo archivo se gestionan todas las solicitudes que involucran la manipulación de datasets. Estas routes se formalizan como scripts donde se definen cada uno de los endpoints necesarios. Se definieron entonces los siguientes scripts:
Nombre Solicitudes gestionadas
S o lic itu d es G E T
Countries_read.js Países de origen de los usuarios
Dataset_read.js Dataset (originales o resultados de análisis) de usuarios
Project_read.js Proyectos del usuario
User_read.js Validación de usuarios, carga de cuentas de usuario, etc.
S o lic itu d es P O S T
Analysis_request.js Nuevas superposiciones Procrustes. Cuenta con los mecanismos necesarios para crear un nuevo sub-proceso al procesar un nueva superposición.
Dataset_request.js Carga datasets en los distintos formatos propuestos: .tps, .nts, .txt, .txt MorphoJ.
Distance_request.js: Cálculo de una nueva matriz de distancia. Cuenta con los mecanismos necesarios para crear un nuevo sub-proceso al procesar una nueva matriz de distancia.
Ordination_request.js Nuevo ordenamiento. Cuenta con los mecanismos necesarios para crear un nuevo sub-proceso al procesar un nuevo ordenamiento.
Project_request.js Alta y modificación de proyectos
Remove_management.js: Borrado de proyectos, datasets, análisis, etc.
user_request.js Alta de usuario y recuperación de claves.
Se desarrollaron tres módulos de procesamiento: ParseJSON, la interfaz
GraphicsJSONGenerator cuya implementación es PlotlyGenerator y R_Module.
4.4.2.1 ParseJSON
Este módulo implementa el patrón adapter para ajustar la interfaz de comunicación entre R_Module y R. La interfaz es bidireccional: ajusta las entradas y salidas tanto para el procesamiento en R como para la generación de la respuesta al cliente y hace hincapié en la representación de las matrices de datos que sirven de entrada para los distintos algoritmos.
4.4.2.2 PlotlyGenerator (GraphicsJSONGenerator)
GraphicsJSONGenerator es un módulo que funciona como interfaz hacia alguna implementación del generador de gráficos. Se utilizó un patrón de inyección de dependencias por pasaje de parámetros en el constructor de la clase, que depende de la librería gráfica de la aplicación cliente. Se implementó entonces
PlotlyGenerator, que utiliza la librería grafica PlotlyJS. Esta estrategia de implementación permite que una eventual modificación por el uso de una librería gráfica más potente no afecte los módulos de mayor abstracción.
4.4.2.3 R_Module
R_Module se encarga de correr las rutinas de R; utiliza el módulo
NPM:rscript, que envía scripts y parámetros de NodeJS a R y viceversa. R_Module
4.4.3 Gestión del Sistema de Archivos
La gestión de los archivos que son cargados a RPS Online se realiza a través del módulo NPM:fs para: la validación de las extensiones, la carga de archivos temporales, la copia/movimiento/borrado de archivos (datasets), etc.
4.4.4 Acceso a la Base de Datos
La interfaz DataLayer gestiona todas las operaciones en la base de datos (altas, bajas, modificaciones). Al igual que con las librerías gráficas, se implementó un patrón de inyección de dependencias por pasaje de parámetros en el constructor de la clase; el módulo correspondiente se denomina postgreSQL_DB. La gestión de las llamadas a la base de datos PostgreSQL se implementa con el módulo NPM:pg.
4.4.5 Funcionamiento Integral de RPS Services
El web service funciona de la siguiente manera: una vez recibida la solicitud de la aplicación cliente (una superposición Procrustes, un cálculo de distancias o un ordenamiento) ésta es gestionada por el route correspondiente. El route crea un nuevo subproceso en memoria que es el encargado de llevar a cabo la solicitud; una vez completada, se comunica con el thread principal y devuelve los resultados antes de ser desalojado de memoria. De esta manera es posible correr múltiples instancias de análisis para un mismo usuario y el event-loop que gestiona la sesión en tiempo real no es bloqueado. La implementación busca aprovechar al máximo la disponibilidad de recursos del servidor, optimizando el tiempo de respuesta del web service.
4.5 RPS Frontend
4.5.1 Entorno de Desarrollo de la Aplicación Web
Code, un IDE liviano que ofrece una interfaz familiar, con debugging y manejo de extensiones oficiales.
Al implementar una aplicación AngularJS se utiliza el gestor de módulos NPM de NodeJS. La versión de NodeJS que brinda soporte a la herramienta fue v8.9.3 y la versión de NPM fue v5.5.1. Los paquetes que se instalaron para el desarrollo de la web fueron:
• Angular CLI: este módulo permite la creación de un proyecto AngularJS. Provee herramientas para el debugging, la compilación del proyecto, la realización de unit-tests y de empaquetados.
• TypeScript: el framework AngularJS utiliza TypeScript como base del desarrollo. Este complemento otorga al entorno web un perfil orientado a objetos que facilita la comprensión del código en las eventuales modificaciones del proyecto.
4.5.2 Desarrollo
Se describe ahora el diseño de RPS Frontend, que estuvo focalizado en la en la usabilidad de la aplicación y en la visualización de los resultados de los análisis morfométricos.
El diagrama de clases (Fig. 10) consta de tres vistas: los módulos, los componentes principales MainRpsComponent y DashboardRpsComponent.
4.5.2.1 Vista de Módulos
Los bloques de construcción básicos en una aplicación AngularJS son los
NgModules; éstos recopilan código en conjuntos funcionales y proporcionan un contexto de compilación para los componentesprincipales. RPS Frontend consta de los NgModules: AppModule, MainRpsModule y DashboardRpsModule para gestionar la lógica de sus vistas Home y Dashboard.
AppModule es el módulo encargado de lanzar la aplicación; debe declararse obligadamente ya que es interpretado por AngularJS como el módulo raíz.
Los NgModule routers son los módulos de AngularJS que permiten definir una ruta de navegación entre los diferentes estados de la aplicación detectando jerarquías. El router mapea direcciones URL con vistas (en lugar de páginas); cuando un usuario hace click en un enlace, el router intercepta el comportamiento del navegador y muestra/oculta las jerarquías de la vista. Si el router determina que el estado actual de la aplicación requiere una funcionalidad particular no cargada en el navegador por el módulo que lo define, el router mismo puede cargar el módulo por demanda. AppModule contiene un módulo de routing AppRoutingModule que gestiona la navegación entre las dos vistas principales de la aplicación y sólo permite el acceso al Dashboard a los usuarios que poseen una cuenta en RPS Online. Esta característica encapsula toda la lógica de navegación en un solo módulo, brindando así un mayor control en el flujo de las vistas.
El control de la sesión de un usuario se realiza mediante la declaración de un
Guard sobre la vista solicitada. Como componente nativo de AngularJS, el Guard
condiciona el acceso a una vista por medio de una validación: por ejemplo, una lógica del lado del cliente o una solicitud de usuario y contraseña a cargo del web service como en este caso.
La creación de cuentas y la validación de los usuarios son llevadas a cabo por MainRpsModule, donde MainRoutingModule gestiona la navegación entre los formularios y el home de la aplicación. De modo análogo, DashboardRoutingModule
gestiona la creación de los análisis, la carga de los datasets, la visualización de los resultados, etc. para DashboardRpsModule.
4.5.2.2 Vista de Componentes
Los componentes de una aplicación AngularJS generalmente definen vistas, organizadas jerárquicamente. Cada aplicación tiene al menos un componente raíz que conecta una jerarquía con la página DOM. Cada componente define una clase que contiene los datos y la lógica de la aplicación, asociada a una plantilla HTML que define una vista. RPS Frontend define por defecto a AppComponent como raíz de la aplicación; AppComponent gestiona las vistas de MainRpsComponent y
MainRpsComponent
Gestiona el funcionamiento de NavbarMainComponent, quien se ocupa de la navegación mediante los componentes SignUpRpsComponent y
SignInRpsComponent. El primero es un formulario que captura y valida los datos
con los que se da el alta una nueva cuenta de usuario; se ocupa parcialmente del control de errores desde el servidor (chequear si un e-mail está asociado a otra cuenta, por ej.). Para disminuir el overhead, el control de dominio y la completitud los formularios se realizan del lado cliente sin necesidad de comunicarse con el web service o con la base. SignInRpsComponent, por su parte, se encarga de la validación de un usuario existente y de la recuperación de contraseñas; para ello interactúa con el web service y utiliza una API al enviar emails. Los dos componentes mencionados utilizan SharedDatasetService para el intercambio de datos entre componentes, implementando el patrón de diseño Observer.
Es importante mencionar el binding entre las entradas de los usuarios y la información enviada al web service. El web service maneja un protocolo REST que realiza intercambios a través de JSON; AngularJS habilita el binding a un objeto declarado en el controlador de la vista y en el request al servicio el objeto es enviado como string. Así, ninguna de las llamadas al servicio desde RPS Frontend tiene costo de pos-procesamiento.
El diagrama de clases que describe la jerarquía de MainRpsComponent
puede verse en el Anexo 1. DashboardRpsComponent
Para la segunda vista de la aplicación, DashboardRpsComponent es el componente encargado de la creación de proyectos, del cargado de datasets, de la realización de los análisis y de la actualización de los datos del perfil de usuario. Dentro de él, NavbarDashboardComponent gestiona la creación de proyectos, la carga de datasets y los cambios en el perfil de usuario a través de la visualizaciones de cuadros de diálogo (pop-up); éstos realizan las solicitudes a RPS Services para las tres operaciones. El control de dominio y de completitud de los formularios se realiza del lado cliente.
TreeViewComponent es la vista del árbol de proyectos que posee un usuario;