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;

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.