una herramienta web para el análisis morfométrico resistente
TRANSCRIPT
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
Codirector: Sebastián Torcida
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.
Guillermo
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
3.9 Decisiones de Implementación
4.1 Introducción
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
COMENTARIOS FINALES 54
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.
CAPÍTULO 1: INTRODUCCIÓN
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;
› realizar otros tipos de consultas y actualizaciones en la base de datos.
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.
• El trabajo concluye con un resumen de lo realizado.
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
de los puntos que las determinaban. Y por lo tanto no siempre conseguían capturar
CAPÍTULO 2: MARCO TEÓRICO
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
Figura 1: (A) Landmarks del tipo I, II y III
(B) Medidas lineales
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.
Figura 2: Interpretación geométrica de las transformaciones de una superposición Procrustes:
las diferencias de posición, escala y orientación son eliminadas para comparar las formas.
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
Figura 3: Resultados SPCM vs SPR al comparar la forma de dos paralelepípedos.
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
eficiente. Intuitivamente, el ajuste resistente entre dos configuraciones de landmarks
se logra superponiendo perfectamente aquellos landmarks que no cambian (Fig. 3,
A); de éste modo, las verdaderas diferencias de forma quedan evidenciadas en la
falta de ajuste de los landmarks que sí cambian. Desde un punto de vista
estadístico, un método resistente es aquel que impide que cambios significativos en
una pequeña porción de los datos tengan un impacto decisivo en los resultados de
un ajuste o de un análisis (Huber, 1981). Se puede probar que cambiando hasta la
mitad menos uno de un conjunto de valores, la mediana repetida del nuevo conjunto
permanecerá igual: ésto representa un breakdown value de casi el 50% (Slice,
1982) que es el máximo valor posible de flexibilidad. Una superposición Procrustes
resistente basada en medianas repetidas (SPR, de ahora en más) conseguirá
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 al paso 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
Luego de obtener una superposición Procrustes interesa medir las diferencias
de forma resultantes entre cada par de configuraciones de landmarks. Es útil
entonces calcular una distancia multivariada que cuantifique esas diferencias; para
cada método de superposición RPS Online permite obtener una matriz de distancias
coherente.
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
La visualización de los cambios en una forma biológica constituye el corazón
de la MG: al estar basados en puntos claramente identificables, los cambios pueden
representarse gráficamente o en animaciones computacionales. Una buena
visualización suele comunicar los cambios de forma más eficazmente que una tabla
de coeficientes. Y en el caso de la MG los cambios morfológicos se visualizan en su
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.
Uno de los inconvenientes principales de las aplicaciones morfomométricas
de escritorio está vinculado al gran volumen de datos que se manejan, consumiendo
disco y memoria tanto en el procesamiento y almacenamiento de los datos como en
la instalación y uso de las aplicaciones. Otro inconveniente es que obligan a utilizar
el propio equipo: si el equipo no está no está accesible tampoco lo están la
aplicación y a los datos. Como alternativa, una aplicación web se abstrae del SO y
sólo necesita una conexión a internet (lo que puede ser un inconveniente en
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.
Las funcionalidades incorporadas son: la creación de cuentas de usuario para
la gestión de los proyectos y los análisis; la recuperación de clave y contraseña de
usuario; la edición del perfil del usuario; la exportación de los resultados y gráficos;
la edición de un dataset para eliminarle objetos y/o landmarks.
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
CAPÍTULO 3: TECNOLOGÍAS UTILIZADAS
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
(www.postegresql.org) que es de libre distribución, se adhiere ampliamente
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,
hecha pública por Facebook. Ofrece grandes beneficios en términos de performance
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.
La ventaja de es que el servidor se libera de trabajo: simplemente envía
los datos al cliente a través de JSON y es éste quien se encarga de producir el
HTML necesario. Pero no sólo representa una mejora para el servidor en cuanto
términos de procesamiento: también lo es en términos de bits, porque es más rápido
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
Figura 4: Diagrama de ejecución de una aplicación AngularJS
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).
Al tratarse de un proyecto de código abierto, favorece desarrollo más
transparente con una comunidad activa y comprometida detrás. Permite escribir
aplicaciones y bibliotecas que se ejecutan sin modificaciones en todos los 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.
Figura 5: Modelo de la dinámica de ejecución del motor NodeJS
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
correr código R desde un servidor web. es un R package que facilita la creación
desde R Studio de aplicaciones web interactivas, permitiendo a los usuarios tener
vínculo con sus datos sin tener que manipular el código. Cada app es una carpeta
que contiene un archivo server.R y comúnmente un archivo ui.R; server.R contiene
las instrucciones que constituyen los componentes R de la aplicación, en tanto que
ui.R es una descripción de la interfaz de usuario (la página web que muestra la
aplicación).
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.
• Como Backend se decidió desarrollar el web service RPS Services, cuyo
objetivo es aportar una capa de procesamiento de las funcionalidades
morfométricas brindadas por RPS package y ser a la vez una interfaz hacia R
y hacia PostgreSQL; se logra así desacoplar el procesamiento y la
visualización de los datos, quitando carga de trabajo al cliente web y
permitiendo que sea invocado desde otra aplicación. .Net Core ofrece las
características buscadas, pero presenta dificultades en la gestión de memoria
a medida que la aplicación escala; al contar con recursos físicos limitados
para la implementación, esta tecnología fue descartada. Por su parte, Shiny
de R Studio presentó limitaciones en el manejo de eventos asíncronos no
bloqueantes ante el volumen de datos involucrados en los análisis
morfométricos. Por todo lo anterior se decidió utilizar un web service REST
desarrollado sobre NodeJS, que facilita el uso de JSON como documento de
intercambio: se trata de un entorno sumamente liviano con una arquitectura y
una gestión de memoria adecuadas para un servidor de aplicaciones con
bajos recursos. El gestor de módulos NPM permite la interacción con R y con
PostgreSQL mediante r-script, file-system y pg (el intercambio de datos entre
NodeJS y R y el cliente PostgreSQL nobloqueante, respectivamente).
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
Figura 6: Arquitectura del sistema
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.
Figura 7: Pantalla principal de RStudio.
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.
El conjunto de k puntos en
p dimensiones cuyas
distancias euclideas
aproximan D (aprox. CM).
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
SpmedcrudoCalcula la mediana espacial de las
filas de la matriz de entrada.
Una matriz cuyas filas
representan los mismos
landmarks de distintos
especímenes.
Un vector que es la
mediana espacial de las
filas de la matriz de
entrada
SpatialmedCalcula la mediana espacial de un
conjunto de matrices.
Un conjunto de matrices
que representan los
especímenes de un
dataset.
Una matriz cuyas filas son
las medianas especiales
de las respectivas filas de
las matrices de entrada.
scaleSpecimenAjusta la de escala de un conjunto
de 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.
rotationEstima la matriz de rotación
resistente 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.
initialFocusCentrado resistente de un conjunto
de matrices.
Un conjunto de matrices
que representan los
especímenes de un
dataset
Un conjunto de matrices
que representan los
especímenes luego del
centrado resistente.
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.
Así, se decidió transformar el DERExt inicial en uno alternativo en el cual la
representación de landmarks y especímenes se tratara como un tipo de dato
semiestructurado. La implementación en el modelo físico se realizó utilizando un tipo
de dato JSON para almacenar las matrices que representan los datasets,
manteniendo el resto de los datos con un enfoque relacional. Las capacidades pos-
relacionales de PostgreSQL permitieron integrar en el modelo de datos físico datos
estructurados y semi-estructurados.
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:
Figura 8: Diagrama definitivo de la Base de Datos
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
A continuación se describe las estructura de cada uno de los campos JSON
utilizados en las diferentes tablas de la base de datos.
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
Figura 9: Diagrama de la implementación de RPS Services
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
So
licitu
des
GE
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.
So
licitu
des
PO
ST
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.
4.4.2 Módulos de Procesamiento
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
implementa cada uno de los análisis que brinda RPS OnLine. Si se deseara
incorporar nueva funcionalidad a RPS Service, sólo sería necesario implementar la
interfaz en este módulo.
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
El desarrollo de la aplicación web comenzó configurando el entorno de
desarrollo; al no contarse con experiencia en éste tipo de aplicaciones, se apuntó a
un IDE (Integrated Development Environment) que proporcionara un ambiente
confiable, robusto y fácil de utilizar. Se decidió entonces emplear Visual Studio
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.
Figura 10: Vista de Módulos en el diagrama de clases de RPS Frontend
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
DashboardRpsComponent.
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;
con sólo un click, el usuario puede seleccionar y correr los análisis que desee. Cada
análisis está a su vez representado por un componente diferente, formularios que
se visualizan en cuadros de diálogo.
En las primeras versiones para obtener un análisis se presionaba el botón
correspondiente en la barra del Dashboard, pero ésta solución tenía algunos
inconvenientes: se perdía la referencia directa al dataset, que debía buscarse en el
DOM de la página. La acción estaba a cargo de un módulo NPM, pero las
referencias con frecuencia se perdían y los resultados no se correspondían con los
datos. Se decidió entonces una simplificación: al hacer click derecho sobre un ítem
del árbol, el usuario puede seleccionar el análisis que desea correr. El árbol contiene
cuatro tipos de elementos: proyectos, datasets (originales o los resultantes de una
suposición Procrustes), distancias y ordenamientos. Cada tipo sólo habilita aquellos
análisis que tienen sentido: los datasets permiten que a partir de ellos se obtengan
superposiciones Procrustes y matrices de distancias (distance); las matrices de
distancias permiten generar ordenamientos. Es posible eliminar cada tipo de
elemento, para los que tienen elementos relacionados en la jeraquía del árbol, éstos
se eliminaran en cascada. Existe una excepción para el tipo de elemento proyecto
(project), el cual no debe poseer elementos que dependan de él; sólo será posible
su eliminación cuando el usuario ha eliminado previamente los datasets que lo
componen. Al hacer click en un proyecto aparece su descripción y su nombre,
dichos campos pueden editarse.
Hay tres componentes que interactúan entre sí de forma permanente:
TreeViewComponent/GraphicsDashboardComponent/ResultDashboardComponent.
Cuando se realiza un análisis TreeViewComponent debe actualizar sus ítems,
GraphicsDashboardComponent debe generar la visualización del resultado y
ResultDashboardComponent tiene que construir las grillas correspondientes a los
datos del resultado. Por este motivo se utiliza SharedDatasetService para el
intercambio de datos entre componentes permitiendo la actualización de manera
paralela de los componentes mencionados.
Figura 11: Diagrama de la secuencia de procesamiento de una superposición Procrustes.
Sobre GraphicsDashboardComponent se utiliza la librería PlotlyJS para
generar las visualizaciones en 2D o 3D. GraphicsDashboardComponent es el
módulo que crea los gráficos, con una carga de procesamiento importante para la
máquina del usuario. Es claro que el tamaño del dataset impacta de lleno en el
rendimiento de la visualización; por ello, PlotlyJS genera los gráficos partir de un
JSON de entrada generado por el web service, alivianando el procesamiento en la
máquina del cliente.
Cabe destacar finalmente la utilización de la librería pdfMake
(http://pdfmake.org/#/), que gestiona la descarga de los resultados desde el browser
en formato pdf.
DistanceAnalysisComponent, ProcrustesAnalysisComponent, OrdinationAnalysisComponent
Estos componentes ejecutan los análisis morfométricos. El usuario puede
editar el rótulo identificador del análisis realizado, pero por defecto se utilizan los
prefijos que existían en la versión de escritorio de RPS.
ProcrustesAnalysisComponent corresponde a la superposición Procrustes de
un dataset. Cuando el usuario selecciona la opción resistente, es posible modificar
los valores por defecto de la cantidad de iteraciones y la tolerancia utilizados en la
ejecución del algoritmo en R.
DistanceAnalysisComponent y OrdinationAnalysisComponent presentan la
misma configuración y sólo se diferencian en su salida: el primero genera una matriz
de distancias y el segundo obtiene un ordenamiento (que por defecto es un gráfico
en 2D, más fácil de interpretar).
Existe además un control sobre los nombres de los proyectos (únicos por
usuarios) y de los datasets (únicos por proyecto).
El diagrama describiendo la jerarquía en DashboardRpsComponent puede
verse en el Anexo 2.
4.5.3 Servicios AngularJS Desarrollados
Los componentes denominados Servicios proporcionan a la aplicación web
funcionalidades específicas no directamente relacionadas con las vistas. Los
servicios pueden inyectarse como dependencias, haciendo que el código sea
modular, fácilmente reutilizable y eficiente.
Los servicios AngularJS implementados buscaron agrupar las solicitudes al
web service en función del elemento lógico afectado (usuario, proyecto, dataset,
etc.). Tanto la búsqueda de información, la actualización de la bases de datos (altas,
bajas y modificaciones) o el procesamiento resultaron así modularizados.
Se describen a continuación los servicios desarrollados AngularJS:
• ProcrustesService: ésta clase gestiona las superposiciones Procrustes de la herramienta.
• DistanceService: gestiona el cálculo de las matrices de distancias.
• OrdinationService: gestiona los ordenamientos.
• ProjectService: gestiona los proyectos, etc.
• DatasetService: gestiona altas, bajas y modificaciones de datasets, y lectura de los mismos.
• UserService: gestiona el alta de usuarios y sus actualizaciones.
• RemoveService: gestiona la eliminación de datasets, análisis y proyectos.
• InitializeService: gestiona la inicialización de los componentes de la aplicación (carga de
países en el Sign up, carga de perfiles de usuario, etc.)
• AuthService: se utiliza como puente entre el estado de auth-guard y la vista para restringir el
acceso al Dashboard.
• Auth-guardService: implementa la interfaz CanActivate que proporciona AngularJS, se
implementó para realizar la validación de un usuario al ingresar a su cuenta. El
funcionamiento del mismo. Se basa en permitir la transición a una vista dependiendo del
resultado de la validación del usuario: sólo se podrá acceder a las vistas del Dashboard
mientras el usuario esté logueado en la sesión.
Para la puesta en producción de esta herramienta se empleó una máquina
virtual Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0.-130-generic x86_64), utilizando el
módulo NPM:forever (0.15.3) que asegura la ejecución de los servicios
constantemente. Se instaló una base de datos PostgreSQL 9.5.13 y una R-base
3.2.3.
5.1 RPS Online vs. RPS Desktop
Se detallan en ésta sección las mejoras de RPS Online en comparación con
la versión de escritorio.
La vista principal de RPS Desktop puede apreciarse en la Fig. 12. En el
sector de la izquierda se gestionan los análisis (recuadro 1) y puede visualizarse la
información específica de cada landmark (recuadro 2); en el sector central que
ocupa el mayor espacio se visualizan los gráficos de los datasests/análisis y los
reportes correspondientes (recuadros 3 y 4); a la izquierda aparece el árbol de
proyectos, con sus datasets/especímenes/landmarks (recuadro 5).
Una nueva funcionalidad de RPS Online es la posibilidad de crear perfiles de
usuario (Fig. 13 y Fig. 14, globo 4), habilitando la persistencia de los proyectos con
sus datasets y sus análisis. Los perfiles constan de un nick único y una dirección de
email que se utiliza para recuperar la clave de la cuenta; la información ingresada
por el usuario puede ser actualizada en todo momento.
CAPÍTULO 5 : MEJORAS Y TESTEO
Figura 12: Vista principal de RPS Desktop
El procesamiento asíncrono de RPS Online hace posible la ejecución de los
análisis mientras el usuario continúa con otras actividades (Fig.14, globo 2). Cuando
un análisis ha finalizado, la solapa Processing completed lo indica en su contador
(Fig. 14, globo 3). Los análisis finalizados que no han sido vistos por los usuarios se
almacenan en la base datos; cuando el usuario ingrese a su cuenta nuevamente
podrá visualizarlos en el Analysis Repository (Fig. 14, globo 1) y presionando
reubicarlos automáticamente en los proyectos respectivos (Fig. 14, recuadro verde).
Para solicitar un análisis en RPS Online basta con hacer click derecho sobre
un ítem en el árbol de proyectos del Dashboard (Fig. 14, recuadro verde), un
mecanismo mas intuitivo que el disponible en RPS Desktop.
Figura 13: Edición del perfil de usuario en RPS Online
Figura 14: Vista del Dashboard de RPS Online
Con respecto a la carga de datasets en el sistema, en RPS Desktop el
usuario debía seleccionar previamente el proyecto para luego ir al menú File y allí
seleccionar el dataset; con frecuencia, el usuario olvidaba la selección del proyecto
y la operación no se realizaba. En RPS Online el usuario cuenta con un menú
intuitivo y simple que lo guía en la gestión de los datasets (Fig. 15); RPS Online
cuenta además con un formato de entrada adicional, .txt de MorphoJ, muy popular
en el ambiente morfométrico.
Figura 15: Menú de gestión de datasets en RPS Online
Figura 16: Tabs simultáneas de gráficos y resultados en RPS Online
También se realizaron mejoras en el tratamiento de gráficos y resultados. En
RPS Desktop ambas solapas estaban separadas (Fig. 12, recuadro 3) dificultando la
visualización conjunta de los resultados correspondientes a un determinado gráfico.
En RPS Online existen dos tabs verticales que comparten la pantalla del Dashboard,
donde es posible visualizar en simultáneo gráficos y resultados (Fig.16, recuadros
rojo y azul).
En cuanto a los resultados numéricos, la visualización de RPS Desktop
empleaba un formato .txt (texto libre) que permitía editarlos pero no exportarlos.
RPS Online presenta los resultados en un formato de grilla (Fig. 16, recuadro azul)
que se mantiene al exportarlos como .csv o .pdf (Fig. 17 y 18).
Figura 17: Vista de la exportación en formato PDF de una superposición Procrustes.
Cuando el usuario señala con el cursor un landmark en un gráfico de RPS
Online, se muestra la información de sus coordenadas y el espécimen al que
pertenece (Fig. 19). En RPS Desktop la misma información aparecía al seleccionar
el landmark en el árbol de proyectos de la aplicación (Fig. 12, recuadro 2) pero no
era posible identificarlo en el gráfico.
RPS Online cuenta también con mejoras respecto a RPS Desktop en la barra
de herramientas gráficas. En ella, las operaciones posibles pueden aplicarse de
manera específica e independiente para cada gráfico y no globalmente. Por
ejemplo:
Figura 19: Visualización de la información de los landmarks en RPS Online
Figura 18: Vista del formato CSV
al exportar una superposición
Procrustes.
permite descargar una captura en formato .png de un gráfico.
permite editar el gráfico desde el dashboard de PlotlyJS.
permite, naturalmente, un zoom en el gráfico.
desplaza la cámara de visión.
permite recuadrar sólo una parte del gráfico.
permite marcar un lazo que solo incluya lo dibujado dentro del mismo.
permite el zoom in/out.
controla la autoescala.
resetea los ejes.
proyecta el valor sobre los ejes del grafico.
muestra la información de las etiquetas.
muestra las leyendas de los objetos.
El cálculo de las matrices de distancias y de los ordenamientos (llamados
proyecciones en RPS Desktop) no tuvo grandes modificaciones respecto a la
versión anterior. En la superposición Procrustes resistente, el análisis más
importante de la aplicación, el usuario puede editar el valor de tolerancia para la
convergencia y la cantidad máxima de iteraciones del algoritmo (Fig. 20, globo 1)
Figura 20: Menú de configuración de la SPR en RPS Online
Pueden encontrarse más detalles sobre el funcionamiento de RPS Online en
el manual de usuario disponible en http://rps.pladema.net/downloadTutorial.
5.2 Test de Precisión del RPS Package
Los algoritmos estadístico-matemáticos implementados en RPS Online son
producto de la migración al lenguaje R de rutinas interpretadas por Matlab. Como
prueba de precisión de la nueva implementación se evaluó un conjunto de datos en
2D (Craneos2D, Fig. 21) y otro en 3D (Mandibulas3D, Fig. 22), comparando los
resultados ofrecidos por RPS Desktop y por RPS Online. La medida utilizada fue la
diferencia Matlab–RPS Package coordenada a coordenada para todos los
especímenes del dataset resultado, luego de una SPR. Esas diferencias se volcaron
posteriormente en los histogramas que se muestran a continuación.
FIgura 2: Histograma del diferencial obtenidos de los analisis sobre el dataset Craneos2D
Figura 21: Histograma de las diferencias de precisión Matlab-RPS Package luego de la SPR del dataset Craneos2D
Figura 22: Histograma de las diferencias de precisión Matlab-RPS Package luego de una SPR del dataset Mandibulas3D
Debido a la simetría de los histogramas y considerando que la mayor
concentración de las diferencias se produce en torno al cero, puede concluirse que
la precisión de ambas versiones de RPS es aproximadamente equivalente.
Los datasets utilizados en para el testeo pueden descargarse desde el
repositorio: https://github.com/GuillermoPachecoGit/TestRPS_Dataset
5.3 Test de Compatibilidad de RPS Online
Las páginas web deben actualizar su implementación para mantener la
compatibilidad con los navegadores. Por ello se realizó un test de compatibilidad a
RPS Online, que evaluaría su funcionamiento sobre distintas plataformas. La
herramienta utilizada fue la popular BrowserShots (Kaalra y Gowthaman, 2014) que
combina más de 120 navegadores y sistemas operativos. Los resultados obtenidos
fueron satisfactorios: RPS Online funcionó en más del 50% de las alternativas; cabe
señalar que aproximadamente el 30% de las combinaciones navegador/SO son
obsoletas y no reciben mantenimiento alguno. Los resultados del test se visualizan
en la tabla que sigue:
SO/Browser Windows Linux (Debian,Ubuntu) macOS
Chrome >= 10 V V V
Opera >= 51 V Error V
Edge > 16 V n/a V
Safari > 10 n/a n/a V
Firefox > 60 V V n/a
IE 9 10 11 V n/a n/a
Test de Compatibilidad de RPS Online: resultados
Este trabajo consistió en el desarrollo de RPS Online:
http://rps.pladema.net/main/home, una herramienta que pone por primera vez a
disposición de la comunidad morfométrica una aplicación web con un enfoque
resistente básico, novedoso e integral para el estudio descriptivo de la forma de
objetos representados por landmarks.
Como parte del desarrollo de la aplicación web se elaboró RPS package, un
paquete implementado en el entorno de capacidades estadísticas y gráficas R. RPS
package contiene todas las funcionalidades morfométricas ofrecidas en RPS Online
y ha sido testeado y publicado por el R Developtment Core Team en el CRAN, el
repositorio oficial de R packages. Desde el momento de su publicación en julio de
2018, el RPS package cuenta con casi 150 descargas en todo el mundo.
Las capacidades gráficas de RPS Online, por otro lado, son superiores a las
de su antecesor RPS Desktop en términos de una mayor flexibilidad y eficacia en la
visualización y la edición de la información de landmarks y/o especímenes en los
gráficos 2D y 3D. El diseño de la interfaz de usuario permite además apreciar en
simultáneo gráficos y resultados numéricos.
La etapa de testeos arrojó resultados razonables y positivos tanto en la
precisión numérica como en la compatibilidad con diferentes plataformas.
Es posible afirmar que los objetivos de éste trabajo han sido alcanzados
ampliamente: las funcionalidades morfométricas de RPS Desktop, implementadas a
través del RPS package, fueron ahora integradas con el motor de bases de datos
PostgreSQL. Así, RPS Online permite la gestión y el almacenamiento de los
proyectos de cada usuario incluyendo datasets, landmarks y análisis. Toda ésta
información almacenada puede editarse: es posible eliminar especímenes y
landmarks. Los resultados de un análisis se pueden exportar en formatos populares
como .pdf, .txt y .csv; los gráficos, en formato .png. El diseño modular y flexible de
RPS Online es otro un punto a destacar: será fácil reutilizar sus componentes o
incorporarle otras (por ejemplo, métodos resistentes para llevar a cabo análisis
COMENTARIOS FINALES
filogenéticos o métodos para el análisis de formas representadas por superficies en
lugar de puntos, por nombrar sólo un par de posibles extensiones).
Para el autor, éste trabajo significó: fortalecerse en el desarrollo de
aplicaciones web, ser capaz de integrar diferentes tecnologías, poder organizar su
trabajo individual comunicando periódicamente sus progresos e incorporarse a un
espacio grupal de discusión y toma de decisiones técnicas. La experiencia
acumulada en todo este proceso podrá trasladarse y adaptarse al trabajo
profesional cuando resulte conveniente.
BIBLIOGRAFÍA
● Adams D. C. y Otárola Castillo E. (2013) ‐ Geomorph: an R package for the
collection and analysis of geometric morphometric shape data. Met. in Ecol.
Evol. 4(4): 393-399.
● Adams D C., Rohlf F. J. y Slice D. E. (2004). Geometric morphometrics: ten
years of progress following the ‘revolution’. It. Journal of Zool. 71(1):5-16.
● Agarwal A., Phillips J. M. y Venkatasubramanian S. (2010). Universal
multidimensional scaling. En KDD’10: Proceedings of the 16th ACM SIGKDD
international conference on knowledge discovery and data mining (pp. 1149–
1158). New York: ACM
● Bookstein F. L. (1989) Principal warps: thin-plate splines and the
decomposition of deformations. IEEE Trans. Pattern Anal. Mach. Intell. 11:
567–585.
● Bookstein F. L. (1991). Morphometric tools for landmark data: geometry and
biology. Cambridge University Press.
● Bookstein F. L. (1996). Biometrics, biomathematics and the morphometrics
synthesis. Bull. Math. Biol. 58:313–365
● Bootstrap (website oficial): https://getbootstrap.com
● Catalano S. A., y Goloboff P. A. (2012). Simultaneously mapping and
superimposing landmark configurations with parsimony as optimality criterion.
Syst. Biol. 61(3):392-400.
● Csardi G. y Nepusz T. (2006). The igraph software package for complex
network research. Inter. Journal Comp. Syst. 1695(5):1-9.
● ExpressJS (website oficial): https://expressjs.com
● Ferraggine V. E., Torcida S. y Perez S. I. (2017) RPS (Resistant Procrustes
Software): una herramienta novedosa para el Análisis Morfométrico
Resistente. En el 4to. CONAISSI (Congreso Nac. de Ingeniería en Informática
y Sist. de Información). Salta, Argentina
● Goodall C. R. (1991) Procrustes methods in the statistical analysis of shape.
J. R. Statist. Soc. B 53:285–339
● Gower J. C. (1975) Generalized Procrustes analysis. Psychometrika
40:33–51
● Gunz P., Mitteroecker P. y Bookstein F. L. (2005). Semilandmarks in three
dimensions. En Modern morphometrics in physical anthropology (pp. 73-98).
Springer, Boston MA.
● Hallgrimsson B. y Lieberman D. E. (2008). Mouse models and the
evolutionary developmental biology of the skull. Integ. Comp. Biol.
48(3):373-384.
● Huber P. J. (1981). Robust Statistics. New York, Chichester.
● JQuery (website oficial): https://jquery.com
● Kaalra B. y Gowthaman K. (2014). Cross Browser Testing Using Automated
Test Tools. Int. J. of Adv. Studies Comp. Sci. Eng. 3(10):7-12
● Kendall, D. (1977). The diffusion of shape. Advances in Applied Probability 9:
428-430.
● Klingenberg C. P. (2011) MorphoJ: an integrated software package for
geometric morphometrics. Mol. Ecol. Res. 11(2):353-357
● Marcus L. F. (1990) Traditional morphometrics. En Proceedings of the
Michigan Morphometrics Workshop (pp. 77-122). Univ. Mich.
● Mitteroecker P. y Gunz P. (2009). Advances in geometric morphometrics.
Evol. Biol. 36(2):235-247.
● Website de software morfométrico: http://life.bio.sunysb.edu/morph/soft-
tps.html
● Nordhausen K., Sirkia S., Oja, H. y Tyler D. E. (2012). ICSNP: Tools for
Multivariate Nonparametrics, R-package 1.0-9.
● Plotly (website oficial): https://plot.ly
● PostgreSQL (website oficial): https://www.postgresql.org/about/
● Richtsmeier J. T., Burke Deleon V., y Lele S. R. (2002). The promise of
geometric morphometrics. Am. J. Phys. Ant. 119(35):63-91.
● Rohlf F. J. y Slice D. E. (1990). Extensions of the Procrustes method for the
optimal superimposition of landmarks. Syst. Zool. 39:40–59.
● Rohlf F. J. y Marcus L. F. (1993). A revolution in morphometrics. Trends Ecol.
Evol. 8:129–132.
● Rohlf F. J. (2015) The tps series of software. Hystrix It. J. Mamm. 26(1):9–12
● Siegel, A. F. (1982) Robust regression using repeated medians. Biometrika
69(1): 242–244
● Siegel A. F. y Benson R. H. (1982). A robust comparison of biological shapes.
Biometrics 38: 341–350.
● Slice D. E. (1996). Three-dimensional generalized resistant fitting and the
comparison of least-squares and resistant fit residuals. En L. F. Marcus et al.,
(Eds.), Advances in morphometrics (pp.179–199). New York, Plenum Press.
● Slice D. E. (2007) Geometric morphometrics. Annu. Rev. Anthropol. 36:261-
281.
● Torcida S., Perez S. I. y Gonzalez P. N. (2014). An integrated approach for
landmark-based resistant shape analysis in 3D. Evol. Biol. 41(2):351-366.
● van der Linde, K., y Houle, D. (2009). Inferring the nature of allometry from
geometric data. Evol. Biol. 36(3):311-322.
● Vazquez Ortíz, Y., Mier Pierre, L., León, S. y Anthony, R. (2016).
Características no relacionales de PostgreSQL: incremento del rendimiento
en el uso de datos JSON. Rev. Cub. de Cs. Informáticas 10:70-81.
● Weiszfeld, E. (1937) Sur le point pour lequel la somme des distances de n
points donnes est minimum. Tohoku Math.l Journal 43:355–386
● Zelditch M. L., Swiderski D. L., Sheets H. D. y Fink, W. L. (2004). Geometric
morphometric for biologists: A primer. London, Academic Press
ANEXO 1
ANEXO 2