Desarrollo-de-una-herramienta-de-modelacion-de-human-centric ...
49
Transcript of Desarrollo-de-una-herramienta-de-modelacion-de-human-centric ...
UNIVERSIDAD DE CHILEFACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICASDEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
DESARROLLO DE UNA HERRAMIENTA DE MODELAMIENTO DEHUMAN-CENTRIC WIRELESS SENSOR NETWORKS
MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN
JORGE FELIPE GODOY MARDONES
PROFESOR GUÍA:SERGIO OCHOA DELORENZI
MIEMBROS DE LA COMISIÓN:ALEXANDRE BERGEL
BENJAMÍN BARROS ARANCIBIA
SANTIAGO DE CHILE2015
Resumen
Los avances en computación móvil y redes inalámbricas están posibilitando grandes opor-tunidades de desarrollar sistemas colaborativos. La concepción y diseño de estos sistemasrepresenta un desafío para los diseñadores de software debido a la heterogeneidad y dinamis-mo de las interacciones que deben ser soportadas. El poder modelar y evaluar el sistema enfase de diseño permite detectar errores y sugerir mejoras que ayuden al desarrollo dirigido aun producto �nal que realmente soporte el trabajo colaborativo.
En este contexto, investigadores del Departamento de Ciencias de la Computación de laUniversidad de Chile propusieron un lenguaje visual de modelamiento de sistemas colabo-rativos. El lenguaje asume que el sistema puede ser estructurado como una Human-centricWireless Sensor Network. Éste es un tipo de red que permite modelar y entender los �ujosde información de un sistema colaborativo que tiene como protagonistas a las personas. Ellenguaje de modelamiento permite representar un sistema colaborativo como un grafo, en elque se encuentran caracterizados sus participantes y la forma en que estos interactúan.
En este trabajo de memoria se diseñó e implementó una herramienta grá�ca destinada adiseñadores de software que permite el modelamiento de sistemas colaborativos usando el len-guaje propuesto por los investigadores. La herramienta fue desarrollada como una aplicaciónweb en la que interactivamente se pueden de�nir los participantes del sistema colaborativo ysus interacciones.
La representación de los escenarios en forma de grafo permite aplicar metodologías deanálisis en forma automática. En esta memoria se adaptaron e implementaron dos análisisque fueron desarrollados para un lenguaje similar. El primero es un análisis que permiteevaluar la coherencia en las interacciones entre los participantes. Para este análisis se desa-rrolló un algoritmo e�ciente que permitió la evaluación automática a medida que el diseñadorva realizando cambios en el modelo. El segundo análisis permite generar requerimientos ge-nerales de software que deben estar presentes en la aplicación colaborativa para soportarapropiadamente las interacciones modeladas. La lista de requerimientos se genera para cadaparticipante de la red, basado en como estos interactúan con los demás. La lista generadapuede ser re�nada por el diseñador del sistema, de acuerdo con las necesidades particularesde cada aplicación.
Se espera que la herramienta contribuya a fomentar el uso del lenguaje y de esta formafacilitar el desarrollo de sistemas colaborativos que aprovechen los nuevos e interesantesescenarios de colaboración que está permitiendo el auge de los dispositivos móviles.
i
A mi Nori, familia y amigos.
ii
Tabla de contenido
1. Introducción 11.1. Justi�cación de la Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Objetivos de la Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Marco Teórico 42.1. Human-centric Wireless Sensor Network (HWSN) . . . . . . . . . . . . . . . 4
2.1.1. Capa Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2. Capa Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3. Capa Information Persistence . . . . . . . . . . . . . . . . . . . . . . 62.1.4. Capa Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. El Meta-modelo HWSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3. Lenguaje de Modelamiento de Interacciones . . . . . . . . . . . . . . . . . . 8
3. Diseño de la Solución 123.1. Arquitectura Básica del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 123.2. Características del Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3. Sistema de Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4. Arquitectura de Software del Cliente . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1. Módulo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.2. Módulo Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.3. Módulo de Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4.4. Módulo de Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4.5. Módulo Barra de Herramientas . . . . . . . . . . . . . . . . . . . . . 20
3.5. Interfaz Grá�ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4. Evaluación del Modelo 224.1. Análisis para Ciclos de 3 Nodos . . . . . . . . . . . . . . . . . . . . . . . . . 244.2. Análisis de Ciclos de Más de 3 Nodos . . . . . . . . . . . . . . . . . . . . . . 254.3. Algoritmo de Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5. Reporte de Requerimientos 325.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.1. Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.1.2. Consistency and Availability . . . . . . . . . . . . . . . . . . . . . . . 335.1.3. Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1.4. Heterogeneity and Interoperability . . . . . . . . . . . . . . . . . . . 345.1.5. Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
iii
5.1.6. Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1.7. Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2. Match entre Requerimientos y Tipos de Interacción . . . . . . . . . . . . . . 365.3. Reporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6. Conclusiones y Trabajo Futuro 40
7. Bibliografía 42
iv
Índice de tablas
2.1. Tipos de nodos soportados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2. Tipos de enlaces soportados . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Cantidad de ciclos para grafos completos . . . . . . . . . . . . . . . . . . . . 27
5.1. Clasi�cación de requerimientos de acuerdo al tipo de interacción . . . . . . . 37
v
Índice de �guras
2.1. Arquitectura de una aplicación colaborativa basada en una HWSN . . . . . . 52.2. Meta modelo HWSNN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3. Representación visual de los tipos de simultaneidad . . . . . . . . . . . . . . 92.4. Modelo de interacción de un sistema de seguridad personal . . . . . . . . . . 11
3.1. Arquitectura básica del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 133.2. Diagrama modulo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3. Diagrama modulo vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4. Barra de herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5. Panel lateral con los tipos de nodos disponibles . . . . . . . . . . . . . . . . 213.6. Interfaz grá�ca de la herramienta implementada . . . . . . . . . . . . . . . . 21
4.1. Caminos entre A y C incoherentes . . . . . . . . . . . . . . . . . . . . . . . . 224.2. Caminos entre A y D incoherentes . . . . . . . . . . . . . . . . . . . . . . . . 234.3. Modelo HWSN con ciclos inválidos . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Modelo HWSN con ciclos inválidos . . . . . . . . . . . . . . . . . . . . . . . 385.2. Visualización del panel con lista de requerimientos del nodo seleccionado . . 39
vi
Capítulo 1
Introducción
El reciente crecimiento de las redes sociales junto a los avances en computación móvil ycomunicación inalámbrica han permitido a las personas trabajar en forma colaborativa parapoder alcanzar sus objetivos. Estos sistemas de computación colaborativa están apoyando ac-tividades personales como e-business, turismo, conducción de vehículos, o seguridad; así comotambién actividades grupales como el trabajo en hospitales o el dar respuesta a emergenciaspor parte de bomberos.
Aunque los sistemas que soportan estos nuevos escenarios de computación colaborativahan mostrado ser útiles para abordar varios problemas, su concepción y diseño representanun desafío para los diseñadores de software. Estos sistemas tienen una inherente complejidaden el modelamiento que está dado por la heterogeneidad y dinamismo de las interaccionesque deben ser soportadas en el escenario de la aplicación.
Es sabido que estos sistemas son altamente demandantes, en términos de interacciones.Además, como sus usuarios interactúan entre ellos en escenarios físicos heterogéneos, susinteracciones deben ser primeramente consideradas en el diseño de estas aplicaciones, conel �n de determinar si los servicios incluidos en el sistema son idóneos para soportar esasinteracciones o no. La falta de directrices para abordar este problema de modelamiento nosólo pone en peligro la pertinencia de estas aplicaciones, sino también implica que los serviciosprovistos por estos sistemas sólo pueden ser evaluados después de la implementación, lo cuales claramente caro y riesgoso.
Disponer de un lenguaje de modelamiento puede ayudar a los desarrolladores de softwarea entender un proceso y a diseñar una solución de software apropiada que lo soporte. Esto esespecialmente importante en escenarios de trabajo complejo, como aquellos que involucranmovilidad y colaboración. Herramientas de modelamiento de propósito general pueden noser apropiadas para representar trabajo colaborativo, ya que no pueden representar la �e-xibilidad y variabilidad de este tipo de actividades, y porque los sistemas colaborativos songeneralmente multidisciplinarios y de naturaleza técnicamente compleja.
Numerosas propuestas se han presentado para abordar la especi�cación y análisis de estosescenarios de interacción. Desafortunadamente, estas propuestas proveen sólo una solución
1
parcial, porque fueron concebidas para otros propósitos o para otros contextos. Por estarazón, investigadores del Departamento de Ciencias de la Computación de la Universidadde Chile, han trabajado en el desarrollo de un lenguaje de modelamiento para representar yanalizar las interacciones entre los participantes en un escenario de computación colaborativa[Mon14].
El lenguaje propuesto asume que el sistema colaborativo a ser modelado está estructuradocomo una Human-centric Wireless Sensor Network (HWSN) [Och15]. Éste es un tipo de redcolaborativa donde el �ujo de información va desde los sensores (o generadores de informa-ción) hasta los tomadores de decisiones (o ejecutores de acciones), dando un rol protagónicoa las personas, quienes pueden participar como generadores, procesadores o consumidores dela información.
Los investigadores formalizan la estructura de una HWSN, a través de un meta-modelo queestablece los componentes que pueden estar presentes en estos sistemas colaborativos [Mon14].En base a esa formalización, propusieron un lenguaje de modelamiento para representar elescenario de interacción que está presente en una HWSN. El lenguaje de modelamiento essimple y permite a diseñadores modelar sistemas de interacción complejos a través de laespeci�cación de relaciones punto-a-punto.
El lenguaje de modelamiento es visual y los diseños son representables a través de ungrafo. Los nodos de este grafo pueden de�nir distintos tipos de componentes del ecosistemacolaborativo, los cuales pueden estar encargados de generar, procesar, compartir informacióno realizar acciones especí�cas. Por otra parte, los enlaces representan el tipo de comunicaciónexistente entre dos nodos. Los enlaces se caracterizan en términos de simultaneidad e inter-mitencia. Cada uno de estos elementos tiene una representación visual distinta; con esto sebusca que el diseñador pueda rápidamente determinar el tipo de componente que representacada elemento del grafo.
Ya que el modelo de interacciones que describe un cierto ambiente de trabajo puede serrepresentado usando este lenguaje computable, el análisis y evaluación de un grafo puede serrealizado automáticamente por una aplicación de software. Esto permite a los diseñadores nosólo evaluar sus diseños de sistemas en fases iniciales, sino también mejorar estos modelos demanera incremental. Como este análisis es automático, el proceso es repetible, rápido y debajo costo. Estas características dan al lenguaje propuesto por los investigadores una ventajacomparativa importante sobre las otras propuestas disponibles.
En este trabajo de memoria se diseñó e implementó una herramienta computacional quepermite modelar diseños de sistemas colaborativos usando el lenguaje antes mencionado. Laherramienta proporciona además la capacidad de evaluar el modelo, reportando inconsisten-cias en las interacciones entre nodos y una lista de requerimientos que deben ser implemen-tados para que los participantes puedan realizar las interacciones modeladas.
La evaluación del modelo y la generación de la lista de requerimientos, tomó como base lainvestigación realizada por Valeria Herskovic en su tesis doctoral [Her10]. Herskovic propone yevalúa un lenguaje de modelamiento similar, pero que no considera los componentes presenteen una HWSN.
2
1.1. Justi�cación de la Memoria
La herramienta desarrollada permitirá a los diseñadores de software abordar el desafíode modelar sistemas colaborativos, mediante la representación de las interacciones entre losparticipantes de un proceso colaborativo. El modelo de interacción representado usando ellenguaje de modelamiento, permite un mejor entendimiento de las interacciones de sistemascomplejos de gran heterogeneidad y dinamismo.
Los participantes de estos sistemas pueden colaborar apropiadamente sólo cuando cuentancon los servicios adecuados. Por lo tanto, es fundamental que el diseñador del software tengaclaro (durante la fase de diseño), los �ujos de información entre los distintos componentesde la red y los servicios necesarios para que las interacciones tengan lugar. La herramientaimplementada ayuda al diseñador en estas tareas mediante la visualización y evaluación delmodelo colaborativo. La evaluación del modelo se realiza en base a los tipos de interaccionesy los roles de los componentes participantes del sistema modelado como una HWSN. Además,como el proceso de evaluación es rápido, de bajo costo y repetible, permite la realización demejoras incrementales a un diseño.
El trabajo de memoria involucró el desafío de diseñar e implementar dicha herramienta,considerando como características básicas la robustez y usabilidad para que tenga chance deser efectivamente usada en la práctica. La herramienta consta de las características habitua-les en software de edición de diagramas; esto es, dibujar distintos tipos de formas, moverelementos, crear y resaltar selecciones, crear enlaces entre elementos, importar y exportar,entre varias otras. La herramienta, además, incorpora algoritmos asociados al análisis y almanejo de grafos, los cuales permiten realizar la evaluación del modelo.
La herramienta desarrollada facilitará, a los investigadores del área, la experimentacióncon nuevos escenarios colaborativos que pueden contribuir a la re�nación del lenguaje demodelamiento. Además, se espera que la herramienta ayude a fomentar el uso del lenguajey el desarrollo de sistemas colaborativos que aprovechen los nuevos e interesantes escenariosde colaboración que está permitiendo el auge de la computación móvil.
1.2. Objetivos de la Memoria
Para esta memoria se propuso el objetivo de desarrollar una herramienta interactiva demodelamiento que permita diseñar y evaluar sistemas colaborativos usando el lenguaje visualpropuesto en [Mon14]. Esto con el propósito de ayudar a diseñadores de software a evaluar ymejorar (en la fase de diseño) el modelo de interacciones entre los participantes de un siste-ma colaborativo. Para cumplir el objetivo anterior, se establecieron los siguientes objetivosespecí�cos:
• Estudiar e identi�car las alternativas de evaluación de los sistemas colaborativos dise-ñados con el lenguaje de modelado de HWSN.
• Diseñar e implementar una aplicación para edición de grafos con los componentes vi-suales de una HWSN.
• Diseñar e implementar un sistema de evaluación con los resultados de la investigaciónanterior e integrarlo al editor de grafos.
3
Capítulo 2
Marco Teórico
La herramienta implementada permite modelar sistemas colaborativos usando el lenguajede modelamiento propuesto en [Mon14]. Este lenguaje asume que el sistema colaborativo estáestructurado como una Human-centric Wireless Sensor Network (HWSN). A continuación seresume el concepto de HWSN, cuya formalización se encuentra especi�cada en [Och15].
2.1. Human-centric Wireless Sensor Network (HWSN)
La HWSN es un framework conceptual que permite a los diseñadores de software caracte-rizar el rol de los participantes en sistemas colaborativos. De esta manera, se logra estructurarlas funcionalidades requeridas para estos sistemas.
Un sistema colaborativo modelado como una red HWSN se puede representar como ungrafo dinámico bidimensional.El modelo considera la participación no sólo de las personas(quienes interactúan a través de dispositivos computacionales), sino también sensores y dis-positivos autónomos que apoyan la comunicación y el compartimiento de información entrelos participantes. Los nodos de este grafo pueden de�nir distintos tipos de componentes delecosistema colaborativo, los cuales pueden estar encargados de generar, procesar, compartirinformación o realizar acciones. Por otra parte, los enlaces entre pares de nodos representanel tipo de comunicación existente entre ellos, en términos de los tiempos que disponen losnodos para colaborar y la intermitencia del vínculo de comunicación.
Los nodos participando en estas redes pueden ser de varios tipos: Human-based Sensors(HBS), Regulars Sensors (RS), Mules(Mu), Witness units (Wu) y Actuators (Ac). Dependien-do de la funcionalidad provista por los nodos, estos se distribuyen en la arquitectura de unaHWSN compuesta por las siguientes 4 capas (�g. 2.1): sensing, communication, informationpersistence y application.
La �gura 2.1 representa una infraestructura de aplicación crowdsensing basada en unaHWSN. La aplicación permite a las personas reportar y también ser noti�cadas de su con-dición de seguridad dependiendo de la ubicación en la que se encuentran y la situación de
4
Figura 2.1: Arquitectura de una aplicación colaborativa basada en una HWSN(obtenida de [Mon14])
contexto de la información (por ejemplo, hora, día de la semana, condición de luz). Los ciu-dadanos recolectan y comparten esta información de seguridad desde su entorno circulanteusando sus teléfonos móviles de manera anónima. La información recolectada permite a losparticipantes realizar un diagnóstico en línea de su riesgo actual y nivel de seguridad mientrasse desplazan por las áreas urbanas. Eventualmente, alarmas o mensajes vibrotáctiles puedenser simultáneamente liberados al teléfono inteligente del usuario y a los otros nodos de laHWSN (por ejemplo, vecinos o patrulla policial en el área) cada vez que el nivel de riesgo deuna persona supere cierto límite preestablecido.
A continuación se describen brevemente las 4 capas que componen una HWSN y los tiposde nodos participantes en cada una de ellas. Cabe destacar que los HBS y las mules puedenencontrarse presente en más de una capa.
2.1.1. Capa Sensing
La capa sensing es la capa más baja de una HWSN y está a cargo de capturar y proveerinformación al sistema colaborativo mediante el uso de regular sensors y human-based sen-sors(HBS). Los componentes pertenecientes a esta capa son sólo aquellos capaces de capturarinformación desde el ambiente y compartirlo a través de la red. La información capturadapuede tener un periodo limitado de validez y/o tener distintos niveles de relevancia de acuer-do al valor que le dé el sistema colaborativo, el cual podría depender de los roles o reputaciónde los usuarios, votaciones, entre otros.
5
Los HBS son las personas que usan un dispositivo computacional (móvil) para capturar,compartir y proveer información a otros participantes del ecosistema. Un ejemplo de HBS sonlos habitantes de una cierta área y transeúntes (HBS-1 y 2 en la �gura 2.1), quienes usan susteléfonos inteligentes para indicar la información de seguridad del lugar donde se encuentranubicados. Con el �n de evitar errores y reducir el esfuerzo de geolocalizar esa información,ellos usan la posición provista por el GPS (i.e un regular sensor) incluido en los dispositivos.Por lo tanto, los HBS usan sus sentidos y también información capturada desde un regularsensor para generar el conocimiento (o meta información) que será compartida con los otrosnodos de la red.
2.1.2. Capa Communication
La capa communication es responsable de proveer capacidad de interacción entre los nodosde la red. Esta capacidad de interacción está basada en el soporte de comunicación provistopor los communication units y mules. Un enlace entre dos nodos es siempre mediado por uncommunication unit. Las características de estos afectan el estado de los enlaces entre nodos,pudiendo tener una comunicación permanente o intermitente.
La comunicación de información entre los nodos de la red puede ser realizada usandocomunicación punto-a-punto (por ejemplo a través de una red celular o una red ad hoc) ousando mules. En el primer caso, communications units (CU) participan como mediadores,típicamente antenas, las cuales no almacenan ni procesan la información del sistema. Lasantenas sólo tienen la capacidad de conectar nodos ubicados dentro de cierto rango de comu-nicación. Los communications units no son nodos formales de la red, porque no almacenanla información compartida. Sin embargo, su presencia afecta al estado de los enlaces. La in-�uencia que estas infraestructuras de comunicación hacen en la capacidad de interacción delos usuarios es representada a través de los enlaces entre nodos.
La segunda estrategia que puede ser usada para comunicar información entre los nodosde la red involucra el uso de mules. Una mule es un nodo móvil, por ejemplo un teléfonointeligente de un transeúnte o un vehículo que posee un computador, el cual voluntariamenteofrece una porción de sus recursos para ayudar a diseminar la información provista por otrosnodos. En estas redes las mules podrían eventualmente tener una ruta y un periodo.
Las mules que realizan actividades de comunicación son representadas como nodos eneste grafo multicapas, ya que almacenan información. Estas unidades intentan transportarmensajes desde un nodo fuente a un nodo destino, aunque una ruta pueda no existir entreellos. Sólo el nodo destino puede procesar el mensaje transportado por una mule. Estosmensajes expiran después de un cierto periodo de tiempo.
2.1.3. Capa Information Persistence
La capa information persistence es responsable de almacenar y compartir información,disponibilizandola para los HBS que están actualmente activos en la capa application; es
6
decir, personas que están usando un sistema colaborativo en sus dispositivos móviles pararealizar cierta actividad. Los participantes en la capa information persistence son los witnessunits, mules y HBS (jugando el rol de witness unit). Los HBS almacenan la informacióncompartida por cortos periodos de tiempo, mientras que los otros tipos de nodos almacenanla información hasta cierto timeout.
Los witness units (WU) tienen el propósito de incrementar la disponibilidad de informaciónpermitiendo que nodos con distintos periodo de actividad puedan comunicarse. Los witnessunits también tienen la capacidad de fusionar información (es decir, combinarla de manerainteligente) para producir conocimiento que también puede ponerse a disposición de otrosnodos de la red. La fusión de información es realizada por agentes inteligentes incluidos enestas unidades. Los HBS también pueden servir como witness units por un corto periodo detiempo.
Los HBS y witness units pueden difundir la información en demanda (nodos pasivos) o enforma automática siguiendo un periodo predeterminado (nodos activos). Los nodos activostambién son conocidos como beacons o information sprinklers.
2.1.4. Capa Application
Por último, la capa application es responsable de proporcionar servicios directos y útilesa los usuarios �nales, usando la información compartida y colectada desde las tres capasinferiores. Esta información debe �uir desde la capa sensing hasta la capa application, consi-derando que el rol jugado por un nodo, particularmente en el caso de los HBS, puede cambiaren cortos periodos de tiempo.
En esta capa podemos encontrar presentes los actuators. Estos son dispositivos capaces derecibir una orden y realizar una acción de salida. Ejemplos de ellos pueden ser, una bocinaque emite sonidos cuando una orden de alarma es recibida o un teléfono inteligente de unHBS que vibra cuando su nivel de seguridad cae bajo cierto valor.
Estos dispositivos siempre realizan acciones de salidas, y no alimentan directamente elsistema. Eventualmente, un HBS puede usar la señal de salida de un actuator (por ejemploel sonido de una alarma) para crear conocimiento que luego es la información de entrada alsistema. La señal de salida de los actuators puede ser lanzada en demanda por un HBS, o au-tomáticamente cuando cierta situación (descrita por la información compartida) es detectadapor un witness unit (a través de agentes inteligentes).
La eventual interacción directa entre las personas que usan estos sistemas colaborativosestá soportado en esta capa. Este tipo de interacción puede estar o no presente en un sistema,dependiendo de la estrategia de colaboración diseñada para tratar con el problema que elsistema quiere solucionar.
7
2.2. El Meta-modelo HWSN
Soluciones colaborativas que usan un HWSN como soporte de interacción heredan dospotenciales bene�cios de estas redes: (1) La autonomía de nodos (en términos de datos yservicios) ya que estas estructuras promueven loosely-coupled computing, y (2) el comparti-miento de información puede ser evaluado y eventualmente mejorado en fase de diseño. Sinembargo, el obtener estos potenciales bene�cios requiere que la plataforma de apoyo a lainteracción usada por la aplicación colaborativa se adhiera a la estructura establecida poruna HWSN.
Con el �n de facilitar la comprensión de estas estructuras de red a los diseñadores desoftware, los investigadores de�nieron un meta-modelo inicial que identi�ca los componentesque pueden estar presente en una HWSN (�g. 2.2). Este meta-modelo también puede serusado para evaluar si un cierto diseño de sistema se adhiere a la estructura de este tipo deredes.
El meta-modelo también indica los servicios que cada tipo de nodo debiera proveer pordefecto. Como cada solución es potencialmente diferente dependiendo de los usuarios invo-lucrados y el escenario físico a abordar, los servicios incluidos en el meta-modelo deben serevaluados por los diseñadores de sistemas para determinar su inclusión en la nueva aplicación.Estos servicios son sólo aquellos requeridos para soportar el �ujo de información e interacciónentre los nodos de la red, es decir, no consideran los servicios particulares que cada usuarionecesitará para realizar su trabajo (también conocidos como business services).
2.3. Lenguaje de Modelamiento de Interacciones
Como se mencionó anteriormente, este lenguaje de modelamiento está basado en la pro-puesta de Herskovic [Her10], pero también considera los nodos y tipos relaciones que puedenestar presentes en un HWSN, de acuerdo al meta-modelo presentado en la �gura 2.2. Estelenguaje permite a los diseñadores representar las relaciones entre nodos como una relaciónpunto-a-punto, lo cual reduce la complejidad de diseñar. La agregación de estas relacionespermite representar el �ujo de la información compartida y la probabilidad de interacciónentre cualquier pareja de nodos de la red.
Con el �n de simpli�car la representación y entendimiento de los modelos, el lenguajees visual e involucra nodos y enlaces formando un grafo. Las tablas 2.1 y 2.2 muestran larepresentación visual de nodos y enlaces respectivamente.
Los enlaces son estereotipados para indicar el nivel de simultaneidad que la presencia dedos nodos tiene en el escenario modelado. El atributo de simultaneidad puede asumir unode 3 valores posibles: simultaneous, overlapped y disjoint. La Figura 2.3 indica como estosvalores pueden ser visualmente representados en el modelo de interacciones. Un enlace simul-taneous indica que los nodos enlazados están activos durante el mismo periodo de tiempo.Uno overlapped, indica que el periodo de actividad de los nodos está sobrepuesto, teniendo
8
Figura 2.2: meta modelo HWSNN (obtenida de [Mon14])
Figura 2.3: Representación visual de los tipos de simultaneidad (obtenida de [Mon14])
también partes de periodo en los que sólo hay un nodo activo. En el último caso, el enlacees disjoint si los periodos de actividad de los nodos son disjuntos. En este último tipo losnodos requerirán un nodo intermediario (por ejemplo, un witness unit) para intercambiarinformación y realizar interacciones asíncronas.
La intermitencia de los enlaces es determinada por el tipo de soporte de comunicacióndisponible para realizar las interacciones entre los nodos involucrados. Todos los nodos tienenuna o más interfaces de comunicación (es decir, antenas) que les permiten interactuar conotros nodos. Dependiendo del tipo de interfaces que ellos usen, la comunicación podría serpermanente (por ejemplo, una red satelital) o temporal (por ejemplo, una red móvil o unaad hoc basada en WiFi).
La relación entre dos nodos puede cambiar entre periodos de comunicación permanentee intermitente. En estos casos el diseñador debe asumir y representar la situación más des-favorable, con el �n de asegurar que incluso en esas situaciones la información �uirá entreellos.
9
Icono Signi�cado
Human based sensor
Mule
Witness Unit
Regular sensor
Actuator
Tabla 2.1: Tipos de nodos soportados
Icono Signi�cado
Permanent communication
Intermittent communication
No communication
Tabla 2.2: Tipos de enlaces soportados
En cuanto a los nodos de la red, los participantes pueden ser aquellos considerados enel meta-modelo HWSN. Todos los nodos tienen un rol único, excepto los HBS que puedenjugar varios roles simultáneamente. Este lenguaje de modelamiento no requiere manejar lasobre-escritura de roles, ya que se asume que un HBS puede jugar varios roles, y cada unode ellos puede ser activado o desactivado en demanda.
Un HBS puede estar activo (es decir, participando como un nodo formal de la red), almismo tiempo, en diferentes capas de una HWSN. La presencia de un HBS en una capa estádirectamente relacionada con los servicios que el nodo provee a otros en un cierto instante.Ya que el servicio de activación y desactivación puede ser realizado en tiempo de ejecución,la topología de esta red multicapa típicamente se mantiene cambiando la mayor parte deltiempo. Es importante notar que la topología de estas redes no está relacionada con ladistribución física y los enlaces de comunicación entre los dispositivos computacionales, sinoque a las capacidades de interacción entre los nodos a través del sistema colaborativo.
La �gura 2.4 muestra un ejemplo de modelo de interacciones usando el lenguaje de modela-miento. El diagrama muestra un sistema colaborativo destinado a proveer seguridad personal.En el diagrama se pueden apreciar los distintos de nodos y tipos de comunicación presentesen una HWSN.
10
Figura 2.4: Modelo de interacción de un sistema de seguridad personal(obtenida de [Mon14])
11
Capítulo 3
Diseño de la Solución
La herramienta de software se implementó como una aplicación web. Se pre�rió esta pla-taforma por sobre una aplicación desktop debido a que los requerimientos de hardware sonmínimos y las tecnologías actualmente disponibles en los navegadores permiten implemen-tar la aplicación. Además, un desarrollo web tiene la ventaja de ser multiplataforma, norequerir instalación, se pueden liberar fácilmente actualizaciones, fácil diseño de interfaces einteractividad. A la vez también presenta desafíos, los browsers no tienen implementado losestándares web al 100%, por lo que es necesario tomar las medidas adecuadas para respon-der ante características no implementadas y que son requeridas por la aplicación. Algunas deestas características pertenecen al estándar HTML5, por lo que se debe usar un navegadormoderno para disponer de todas las funcionalidades de la aplicación.
La capacidad de cómputo y memoria requeridas para la visualización y análisis del grafoson mínimos, por lo que todo el proceso se realizará en el mismo navegador. La única tareadel servidor será servir los archivos con el contenido estático de la aplicación.
3.1. Arquitectura Básica del Sistema
La arquitectura básica del sistema se adhiere al modelo cliente-servidor (Fig. 3.1) dondeel cliente es un browser. El browser es quien comienza la comunicación solicitando al servidorel documento html de la aplicación, una vez recibido lo interpreta y solicita los recursosadicionales. Dadas las características de la aplicación, el servidor sólo se encarga de responderlas solicitudes del browser con los archivos estáticos solicitados. En un trabajo futuro se podríaagregar lógica adicional en el lado del servidor, por ejemplo, para almacenar documentos opermitir la colaboración entre usuarios. Una vez realizada la transferencia inicial de recursosno se hacen más solicitudes al servidor.
12
Figura 3.1: Arquitectura básica del sistema
3.2. Características del Cliente
Todo el cómputo, visualización e interacción se realizará en el navegador. Las tecnologíaspresentes en los principales navegadores que permiten cumplir con los requerimientos de laaplicación son los siguientes:
Scalable Vector Graphics (SVG): Es una especi�cación para describir grá�cos vectoria-les redimensionables en formato XML. Esta especi�cación es recomendada por la W3C1
desde el año 2001, por lo que está totalmente soportado por los principales navegadores.Con SVG se pueden describir elementos geométricos vectoriales como puntos, rectas,curvas y formas, así como también textos e imágenes. Una de las características que lohacen idóneo para su uso en la herramienta es el soporte de manejadores de eventosque se pueden aplicar directamente a cualquier elemento dibujado. Es decir, tal comose puede aplicar un manejador eventos que se ejecute al hacer click sobre un título,también es posible aplicar un manejador de eventos para un círculo SVG. Los estilosdescritos mediante CSS para los demás elementos del sitio también son aplicables a loselementos SVG.
HTML5 File API: Especi�cación que permite leer y escribir archivos locales mediantejavascript. La API no permite leer archivos directamente por motivos de seguridad.Para leer un archivo se procede tal como si intentará subirlo al servidor, es decir,cuando el usuario invoca la acción de leer un archivo, se despliega el menú del sistemaoperativo para elegir el archivo, luego de eso, la API permite leer el archivo seleccionadopor el usuario. Para el caso de escribir un archivo, primero se procede a crear unarepresentación binaria de los datos llamada blob, luego se invoca la descarga sobre esosdatos, con lo cual se realiza el proceso de escritura.
Estas características están presentes en los browsers Firefox, Chrome, Safari e IE10+. Paraevitar comportamientos inesperados debido a la falta de estas características, se realiza unchequeo al inicio de la aplicación. Si el browser no cuenta con alguna de estas característicasse muestra un mensaje de advertencia con la funcionalidades de la aplicación que no estarándisponibles. De todos modos, como los usuarios objetivos de la herramienta son diseñadoresde software es de esperar que accedan a través de uno de los principales navegadores enalguna de sus versiones más recientes.
1World Wide Web Consortium (W3C) es una comunidad internacional que desarrolla estándares abiertospara asegurar el crecimiento a largo plazo de la Web.
13
3.3. Sistema de Módulos
La creación de contenido dinámico e interacción se implementa en el browser mediante ellenguaje javascript. La versión actual de este lenguaje no ofrece ningún sistema de módulos,tampoco lo hace el estándar HTML5, el que sólo ofrece la capacidad de cargar y ejecutararchivos javascript.
La forma más sencilla de organizar el código, es creando un namespace, donde cada archivoagrega propiedades a un objeto global. Este esquema no escala bien, cada nuevo archivonecesita ser agregado en el html de la aplicación mediante un tag <script>. Además, losarchivos son sensitivos al orden, ya que sus dependencias deben ser cargadas previamente.Cada nuevo tag <script> signi�ca un nuevo request al servidor, lo que puede llevar a undelay innecesario al comienzo de la aplicación. Todo esto hace difícil refactorizar o manteneraplicaciones construidas de esta manera.
Para evitar estos problemas en el desarrollo de la aplicación se usó una librería que permiteusar el sistema de módulos estandarizado, CommonJS. Cada módulo de�ne sus dependenciasy exporta su interfaz. Luego en una fase de construcción se crea un sólo archivo con todo elcódigo de la aplicación.
Esta librería resuelve los problemas de agregar demasiados tag <script>, el orden de losarchivos y permite organizar de una forma mucha más entendible los módulos, ya que cadauno lista explícitamente sus dependencias.
var Person = require("./ Person");
var p = new Person ({});
exports.p = p;
El proceso de empaquetamiento se realiza en forma automática luego de una con�guracióninicial. El hecho de que todo el código quede empaquetado en un sólo archivo no di�cultalas tareas de debugging ya que en la fase de construcción se puede generar un archivo sourcemap que posibilita a las herramientas de debugging de los browsers, mostrar exactamente laestructura de directorios.
Usar un sistema de módulos no es algo habitual en el desarrollo de sitios web. En esteproyecto, por su complejidad, fue necesario usar uno para estructurar el código separando losdistintos componentes y funcionalidades, sin tener que lidiar con el orden en que los archivosdeben ser cargados en el browser.
3.4. Arquitectura de Software del Cliente
Una aplicación web se de�ne con los mismos lenguajes que una página web. Sin embargo,debido a que ofrece mayor interacción con el usuario y procesamiento de información, éstadebe estar diseñada y estructurada de forma similar a una aplicación de escritorio.
La aplicación está formada principalmente por archivos html (contenido y estructura), css
14
(estilo), imágenes y javascript (interacción). Como se vio en la sección anterior, el lenguajede programación en el lado del cliente es javascript. Si bien este lenguaje es orientado aobjetos, no proporciona en forma nativa el concepto de clase, ya que su modelo de herenciase basa en prototipos y delegación. Sin embargo, la �exibilidad del lenguaje permite emularel concepto de clase. Para ello se utilizó la librería llamada Backbone, la cual además deproporcionar un sustituto para clase, permite estructurar la aplicación bajo el patrón Modelo-Vista-Controlador. Las instancias de clases creadas usando Backbone tienen la capacidadde emitir eventos y de permitir a otras instancias suscribirse a esos eventos para ejecutaracciones.
Otra librería usada durante el proyecto es D3. Esta librería para javascript facilita lamanipulación de elementos de la vista basados en datos. Su uso está destinado a la visua-lización de datos en forma interactiva, por lo que incorpora funcionalidades que facilitancomportamientos como arrastrar un elemento o hacer zoom, entre muchos otros.
El código de la aplicación está estructurado en distintos módulos que se describen en cadauna de las siguientes secciones. A continuación se describen algunos términos usados duranteeste capítulo.
Callback: En javascript las funciones son �rst-class citizens, es decir se pueden asignar avariables, pasar como argumentos y ser retornadas como valores por otras funciones.Un callback es una función que se pasa como argumento a otra función con el propósitode que sea llamada cuando se cumplan ciertas condiciones.
DOM: Document Object Model, es una interfaz de programación que proporciona un con-junto estándar de objetos para representar, añadir y modi�car dinámicamente el con-tenido de documentos en formato HTML y XML. Mediante la manipulación de estosobjetos es como se puede cambiar la estructura y contenido de una página web desdejavascript.
3.4.1. Módulo de Datos
Una HWSN se representa como un grafo, donde los nodos y enlaces tienen atributos quede�nen sus características. Los nodos y enlaces se representan mediante objetos simples dejavascript, mientras que el grafo se representa mediante la clase Graph. La razón por la cuallos nodos y enlaces no se crean mediante una clase, es porque la librería D3 con la cual secalcula las posiciones de los nodos en la visualización, realiza la manipulación directa de losobjetos considerando a estos como objetos simples de javascript.
La clase Graph expone la lista de nodos y enlaces mediante arreglos. Además, expone unaserie de métodos que permiten agregar, modi�car o eliminar elementos de estas listas. Si bienestas operaciones pueden realizarse directamente sobre las listas expuestas, se deben usar losmétodos de la clase Graph, ya que una vez realizada la modi�cación, publican el evento decambio para que los subscritores, como el renderizador del grafo, se actualicen.
15
La clase Graph adicionalmente integra la funcionalidad de los siguientes submódulos quese encuentran en archivos aparte.
Submódulo validación: Este módulo realiza la validación de las interacciones en el grafomediante el algoritmo explicado en detalle en el capítulo 4. La funcionalidad de estemódulo es integrada a la clase Graph.
Submódulo selection: Agrega funcionalidad para obtener los nodos y enlaces selecciona-dos.
Figura 3.2: Diagrama modulo de datos
3.4.2. Módulo Vista
La clase GraphView es la encargada de renderizar un grafo en un contenedor SVG. Estaclase recibe como argumentos al momento de su creación un elemento DOM de tipo SVGy una referencia al grafo. GraphView utiliza dos submódulos: NodeView y EdgeView. Éstosexponen métodos para crear y actualizar la visualización de un nodo y enlace respectivamente.GraphView se suscribe a los eventos emitidos por una instancia de la clase Graph. Cuandose agrega, modi�ca o elimina un elemento del grafo se recibe una noti�cación. Si se agregaun elemento, se crea un contenedor y se llama a la funcionalidad de NodeView o EdgeViewsegún corresponda, para crear la de�nición del elemento. Por otra parte si se elimina un nododel grafo, se recibe la noti�cación, se busca el elemento asociado y se llama a la funcionalidadnecesaria para borrar la �gura de la interfaz.
Los eventos que desencadenan el renderizado pueden ocurrir más de una vez en un lotede ejecución de código. Para evitar renderizar múltiples veces, la función de renderizado seposterga para el siguiente lote de ejecución, donde se renderizan todos los cambios acumuladosde una sola vez.
El módulo GraphView integra funcionalidades que se de�nieron en módulos aparte, acontinuación se describen esos módulos.
Submódulo force: Este módulo se encarga del layout de los nodos. Su implementación con-siste en la con�guración de una funcionalidad de la librería D3 llamada force. El proceso
16
Figura 3.3: Diagrama modulo vista
de cálculo de las posiciones es un proceso iterativo basado en reglas de atracción y derepulsión entre nodos. En cada iteración la funcionalidad de�ne las nuevas posicionesdirectamente en los nodos y llama un callback que invoca al proceso de actualizar elrenderizado de GraphView. El proceso se repite hasta que los nodos alcanzan posicionesestables.
Submódulo Selection: Este módulo de�ne los handlers necesarios para realizar la selec-ción mediante click sobre nodos o enlaces y mediante la selección por áreas. Tiene enconsideración si el usuario está presionando la tecla control, lo cual se interpreta comoadición a la selección previa. Cuando la selección cambia se emite un evento al queotros módulos pueden subscribirse.
Submódulo Zoom: Este módulo agrega la funcionalidad para hacer zoom in, zoom out ypanning interpretando los eventos scroll y dragging. Su implementación consiste bási-camente en con�gurar la funcionalidad de zoom de la librería D3, agregando la lógicanecesaria para restablecer los valores correctos de escala y translación cuando se desac-tiva y reactiva la funcionalidad. El principio básico de cómo funciona es mediante doscontenedores SVG anidados. Cuando se reciben eventos scroll o dragging el contene-dor interno se escala y traslada apropiadamente logrando el efecto esperado, sin tenerque manipular los elementos individuales. Los handlers registrados por panning son losmismos que el de la selección por área, por lo que fue necesario agregar la lógica parapermitir que sólo uno de los dos esté activo.
Submódulo addEdge: Este módulo de�ne la funcionalidad para agregar nuevos enlaces.En su implementación se de�ne un handler para el evento de cambio en la selecciónemitido por el módulo selection. Si detecta que sólo hay un nodo seleccionado y que elusuario no está haciendo dragging, ni está en medio de una selección, ni tiene la tecla
17
ctrl presionada, entonces agrega un icono lateral al nodo con el símbolo de adición.Este icono es el que permite crear un nuevo enlace mediante su arrastre. Cuando secomienza a arrastrar el icono se registran listeners en todos los nodos para saber cuándose está posado sobre uno de ellos. A medida que se va moviendo se dibuja una líneatemporal del futuro enlace, a la vez se resalta el nodo sobre el cual se pasa. Una vezque se acaba el dragging, se determina si se �nalizó sobre un nodo, si es así, se crea elenlace correspondiente y se selecciona automáticamente.
Submódulo editText: Este módulo agrega la funcionalidad necesaria para poder cambiarel texto de los nodos. Inicialmente establece handlers para el evento doble click sobrelos nodos. Cuando se ejecuta la acción, crea un campo de texto temporal que posicionaexactamente sobre el nodo. El campo de texto tiene registrado un handler que guardael texto cuando pierde el foco o se presiona la tecla enter. Si en cambio se presiona latecla escape se cancela la operación.
Submódulo validation: Este módulo invoca la evaluación del grafo. A todos los ciclos queresultan ser inválidos aplica los estilos necesarios para que el usuario pueda identi�carlosen la visualización del grafo.
3.4.3. Módulo de Algoritmos
En este módulo se integran varios algoritmos genéricos que se usan al momento de realizarla evaluación del grafo en busca de incoherencias en las interacciones. A continuación sedescriben los algoritmos implementados. Las complejidades se expresan en términos de n ym, donde n es la cantidad de nodos y m la cantidad de enlaces:
AdjacencyList: Crea un diccionario de adyacencia. A cada nodo se le asocia un arreglo conlos nodos que le son adyacentes. Esta función recibe como argumento un grafo y tienecomplejidad O(n + m).
AdjacencyListFromEdges: Crea un diccionario de adyacencia a partir de los enlaces re-cibidos como argumento. Los nodos involucrados se obtienen de los atributos de losenlaces. Esta función tiene complejidad O(m).
FindTriangles: Encuentra los ciclos formados por 3 enlaces en el grafo que recibe comoprimer argumento. Como segundo argumento recibe una función callback que se invocacada vez que se encuentra uno de estos ciclos. Cada nodo posee un identi�cador nu-mérico único con el cual se puede establecer un orden. Por cada nodo se realiza unabúsqueda en profundidad siguiendo los nodos adyacentes en cada nivel. Para evitartriángulos duplicados, sólo se avanza al siguiente nivel de profundidad si el nodo tieneorden de identi�cador mayor que el anterior. La complejidad de este algoritmo es O(n3).
EdgeMatrix: Crea una matriz de adyacencia de n · n. La celda (i, j) referencia al enlaceentre nodo i y el nodo j, en caso de existir. Esta función recibe como argumento ungrafo y su complejidad es O(n + m).
18
UndirectShortPath: Busca la secuencia de enlaces que generan el camino más corto entreun nodo u y un nodo v. Recibe como argumentos una lista de adyacencia y una matrizde enlaces. Como todos los enlaces tienen costo 1 no es necesario realizar el tradicionalmétodo Dijkstra, en cambio se puede usar un algoritmo más e�ciente, el Bread FirstSearch, que corresponde a hacer una búsqueda en anchura. Su complejidad es O(n+m).
3.4.4. Módulo de Acciones
Las acciones son funciones que se invocan para manipular los datos o realizar una operacióncon ellos. A diferencia de las herramientas de interacción explicadas en el módulo vista, éstasno establecen handlers en los elementos visuales del grafo ni en el lienzo. Las acciones sepueden clasi�car en dos tipos: acciones a aplicar sobre una selección y acciones a aplicarsobre el documento completo. La forma en cómo se pueden invocar estas acciones se verácuando se trate el módulo de barra de herramientas.
Las acciones que se realizan sobre una selección, solicitan la selección actual a la vista,luego realizan las modi�caciones correspondientes usando los métodos dispuestos en la claseGraph, de esta forma los cambios realizados son noti�cados y la vista puede re�ejar esoscambios. Las acciones disponibles de este tipo son las siguientes:
Eliminar: Elimina todos los elementos seleccionados.
Cambiar atributo de los enlaces: Éstas son acciones que permiten cambiar el valor delatributo de simultaneidad y tipo de comunicación de los enlaces seleccionados. Si en laselección también se encuentran nodos, estos son ignorados.
Las acciones que pueden realizar sobre el documento completo están relacionados con lalectura, escritura y análisis del grafo. A continuación se describen las acciones disponibles:
Crear documento: Borrar el grafo actual para comenzar uno nuevo.
Abrir documento: Permite cargar un grafo almacenado en el sistema de archivos local delusuario. Para leer el archivo se usa la API de HTML5 FileReader, cuya compatibilidades IE10+. Javascript no puede acceder directamente al sistema de archivos del usuario.Cada archivo que se desea leer debe ser expresamente autorizado por el usuario, lo quesigni�ca que el funcionamiento de la API sigue el mismo procedimiento de como si setratara de subir un archivo a un servidor remoto.
Guardar documento: Permite guardar un archivo con la representación del grafo en elsistema local de archivos del usuario. Esta función codi�ca la información del grafo enformato JSON. Luego para generar el archivo se usa el constructor de objetos binarioBlob de HTML5. Blob tiene compatibilidad IE10+. Luego se invoca la descarga sobreel blob generado, con lo que se consigue el guardado del archivo.
19
Exportar a SVG: Genera un archivo SVG con la visualización del grafo. Funciona iguala la acción anterior, pero en vez de guardar la representación en formato JSON delgrafo, se guarda la serialización del contenedor SVG en el que se encuentra renderizadoel grafo.
Validar: Invoca la funcionalidad de validar incoherencias en las interacciones de GraphView.
3.4.5. Módulo Barra de Herramientas
Este módulo se encarga de las interacciones externas al lienzo, es decir, se encarga deresponder a los click en los botones y menús de la barra de herramientas y a la creación denuevos nodos mediante el arrastre de los iconos del panel lateral.
Figura 3.4: Barra de herramientas
El menú File simplemente invoca a las acciones asociadas al documento y que fueronexplicadas en la sección anterior.
Los siguientes dos botones permiten elegir entre la herramienta de panning o la de selecciónpor área. En el módulo vista se vio que la herramienta de panning del submódulo zoom teníacon�ictos con la herramienta selección por área del submódulo selection. Sólo una de estasherramientas puede está disponible a la vez porque ambas interpretan el evento de arrastrede forma distinta. Cabe destacar que independiente de cual esté seleccionada la herramientade zoom mediante scroll y la selección por click siempre están disponibles.
El botón con el icono de basurero invoca la acción eliminar sobre todos los elementosseleccionados. Luego se encuentran 3 botones que permiten cambiar el tipo de simultaneidady 2 que permiten cambiar el tipo de comunicación de todos los enlaces seleccionados. Loshandlers de los botones sólo invocan las acciones correspondientes que fueron descritas en lasección anterior. Cada uno de estos 5 botones tienen un shortcut de una sola tecla que invocala misma acción. La teclas s, o y d cambian la simultaneidad a simultaneous, overlapped ydisjoint respectivamente, en tanto que las teclas p e i cambian el tipo del enlace a permanente intermitent respectivamente.
Los siguientes dos botones están asociados a los análisis que se pueden realizar sobre elmodelo. El primero muestra con colores verde o rojo el estado de la validación de coherenciasen las interacciones. La validación se realiza en forma automática cuando modi�ca la cantidado los atributos de los enlaces del modelo. Los detalles se describen en el capítulo 4. El segundobotón muestra el panel donde se despliega el resultado del análisis de requisitos a implementar.Los detalles se encuentran en el capítulo 5.
El panel lateral donde se encuentran los nodos (�g. 3.5) tiene una implementación máscompleja. Su funcionamiento consiste en arrastrar un nodo al lienzo para agregar un nuevonodo al grafo. Cuando se comienza a arrastrar el botón se crea un elemento DOM sustituto
20
Figura 3.5: Panel lateral con los tipos de nodos disponibles
que se posiciona justo encima del botón. Este elemento tiene posición absoluta respecto allienzo, esto permite chequear una vez que el usuario lo suelte, si lo soltó dentro de los límitesdel lienzo o no. Cuando se suelta dentro del lienzo se agrega un nodo del tipo seleccionadoen la posición donde se soltó teniendo en cuenta la escala en la que se encuentra el lienzo.
3.5. Interfaz Grá�ca
En la �gura 3.6 se aprecia la interfaz grá�ca de la herramienta. En la parte superior seencuentra la barra de herramienta con botones que permiten realizar acciones sobre todo eldocumento o sobre la selección actual. En el lado izquierdo se encuentra el panel con lostipos de nodos disponibles. Para agregar un nodo se debe arrastrar uno de los iconos delpanel hacia el lienzo. En el lado derecho se muestra un panel ocultable con los resultados delanálisis de requisitos del nodo seleccionado. La selección de nodos y enlaces se destaca conun color naranjo. Los errores de incoherencia en las interacciones se destacan con color rojo.
Figura 3.6: Interfaz grá�ca de la herramienta implementada
21
Capítulo 4
Evaluación del Modelo
El lenguaje de modelamiento HWSN representa la interacción entre los participantes me-diante enlaces. Estos enlaces son caracterizados por los periodos de tiempo que los participan-tes disponen para comunicarse (simultaneity) y por la estabilidad del medio de comunicación(type). Entre dos nodos del grafo, puede existir más de un camino (secuencia de interac-ciones) para comunicarse entre ellos. Todos los caminos posibles entre dos nodos deben sercoherentes entre sí, de acuerdo con los atributos con los que se describen las interacciones.
Figura 4.1: Caminos entre A y C incoherentes
En la �gura 4.1 se presenta un ejemplo de incoherencia. Se puede apreciar que hay dosformas en que puede ocurrir la comunicación entre los nodos A y C: directamente entre Ay C, o usando como nodo intermediario a B. Estos dos caminos son incoherentes. El nodoB trabaja durante los mismos periodos de tiempo(simultaneous) que A y C, entonces no esposible que los nodos A y C trabajan durante periodos distintos(disjoint).
Evaluar la coherencia entre todos los caminos posibles entre dos nodos, signi�ca tomartodas las combinaciones de dos caminos y chequear si son coherentes. La unión de cadapar posible de caminos puede tener enlaces en común, pero siempre forma al menos unciclo, ya que los caminos son distintos y ambos parten y terminan en un origen y destinocomún. Supongamos que los caminos tienen enlaces en común. Estos enlaces en común formancaminos únicos que no es necesario evaluar. Solo es necesario evaluar la parte de los caminosque forman un ciclo. Sin embargo, esa validación se realizará cuando se consideren los nodosorigen y destino que están en el ciclo. Por lo tanto, sólo es necesario realizar la validacióncuando la unión de los caminos forma un ciclo completo. En el modelo de la �gura 4.2,
22
no es necesario validar la coherencia entre los caminos posibles entre A y D, ya que estosdos caminos poseen un enlace en común. La incoherencia que se muestra en la �gura serádetectada cuando se haga la evaluación entre los dos caminos posibles entre A y C, o los doscaminos entre A y B, o B y C.
Figura 4.2: Caminos entre A y D incoherentes
Del análisis anterior se deduce que los enlaces de un ciclo serán considerados en unaevaluación de coherencia tantas veces como pares de nodos distintos hayan en el ciclo. Elproblema inicial de tomar cada par de nodos distintos, encontrar todos sus caminos posiblesy chequear su coherencia, es equivalente a encontrar todos los ciclos de un grafo y para cadaciclo evaluar la coherencia de los dos caminos posibles entre cada par de nodos distintos.
La metodología utilizada para evaluar las interacciones de cada ciclo se basan en la pro-puesta de Herskovic realizada para su lenguaje de modelamientos de sistemas colaborativos.
La propuesta de modelamientos de sistemas colaborativos de Herskovic es similar a la deHWSN. En ambas el sistema colaborativo se representa como un grafo. En el modelamientode Herskovic los nodos representan actores y son de un sólo tipo, en las HWSN los nodosrepresentan agentes especializados habiendo 5 tipos distintos. En ambos casos, los enlacesrepresentan comunicación entre los nodos, sin embargo hay diferencias en como esta comuni-cación es caracterizada. En el modelo de Herskovic la comunicación se representa mediantelas variables recheability y simultaneity. La variable recheability indica que existe un me-dio de comunicación por el cual dos actores pueden comunicarse. Sus valores posibles sonreacheable, si existe el medio de comunicación, o unrecheable si no existe. La otra variable,simultaneity expresa los tiempos en los que dos actores se encuentran disponibles para reali-zar la comunicación. Sus valores posibles son simultaneous si los dos actores están disponiblespara comunicarse durante los mismos periodos de tiempo o non simultaneous si se encuentrandisponibles en periodos distintos. Las HWSN también representan la comunicación con dosvariables, type y simultaneity. La variable type es el equivalente a la variable recheability,pero sus valores posibles son distintos: permanent, si hay un medio de comunicación estableentre los nodos, e intermitent si existe un medio de comunicación pero la conexión presentaintermitencias. Si no existe un medio de comunicación entre los nodos, entonces no se re-presenta mediante un enlace. La variable simultaneity es el equivalente a su homónima enel modelamiento de Herskovic, sin embargo, ésta puede tomar tres valores posibles: simulta-
23
neous cuando los dos nodos se encuentran disponibles para comunicarse durante los mismosperiodos de tiempo, overlapped, cuando los actores comparten tiempo en común, pero ambosposeen adicionalmente tiempo en trabajan en forma independiente, y disjoint, cuando notienen periodos de tiempo en común para realizar la comunicación.
A pesar de que el lenguaje de modelamiento de Herskovic posee un sólo tipo de nodo yel HWSN 5, el método de evaluación es perfectamente aplicable, ya que no se basa en lascaracterísticas de los nodos sino en la comunicación que ocurre entre ellos. Para el caso delvalor de simultaneidad adicional, se agregaron las reglas necesarias basadas en los conceptoscon los cuales se crearon las reglas para los otros valores de simultaneidad.
El método de evaluación de coherencias en las interacciones expuesto por Herskovic consis-te en evaluar la comunicación que ocurre en los ciclos presentes en el grafo del modelo. Paraello hace la distinción entre ciclos de 3 nodos y múltiples nodos. Las reglas que determinaen un ciclo de 3 son del tipo: dada la comunicación entre dos pares de nodos del triángulo,entonces el tercer par necesariamente debe cumplir con cierto tipo de comunicación.
A continuación se presenta en detalle las reglas a aplicar en los ciclos de las HWSN, creadasa partir de la metodología utilizada por Herskovic.
4.1. Análisis para Ciclos de 3 Nodos
Cuando tres nodos colaboran entre ellos, se puede estudiar los escenarios de interaccionespara asegurar consistencia. En la �gura, los nodos n1, n2 y n3 interactúan, formando un ciclon1n2n3n1. Analicemos, por ejemplo, la forma en que n1 y n3 pueden comunicarse. Existen doscaminos posibles, uno es de n1 a n3 directamente y el otro es usando a n2 como intermediario.Estos dos caminos deben ser coherentes. Si sabemos cómo n1 y n2 interactúan y cómo n2 yn3 interactúan, entonces se pueden inferir ciertas características que la interacción entre n1
y n3 debe cumplir para que ambos caminos sean coherentes.
De�nición 4.1 La interacción entre los nodos n1 y n2 se notará como e1,2.
Lema 4.2 Considerando un ciclo formado por los nodos n1, n2 y n3, si e1,2 es simultaneousy e2,3 es simultaneous, entonces e3,1 es también simultaneous.
Demostración. Si n1 y n2 trabajan simultáneamente, esto signi�ca que durante todo el tiempoen que n1 está activo, n2 también está activo. Si e2,3 es simultaneous, signi�ca que durantetodo el tiempo en que n2 está activo, también lo está n3. Esto es, mientras n2 está activo,tanto n1 como n3 están activos, lo que signi�ca que n1 y n3 también interactúan de formasimultánea.
Considerando las distintas opciones para el atributo simultaneity que pueden tomar e1,2 ye2,3 y siguiendo la misma lógica anterior se pueden inferir las siguientes reglas de coherencia.
24
e1,2 e2,3 Regla e3,1
Simultaneous Simultaneous Simultaneous
Simultaneous Overlapped Overlapped
Simultaneous Disjoint Disjoint
Overlapped Overlapped Cualquiera de los 3
Overlapped Disjoint Overlapped o Disjoint
Disjoint Disjoint Cualquiera de los 3
Consideremos por un momento, que ninguna de las interacciones tiene valor simultaneous,entonces las reglas a aplicar serían las siguientes:
e1,2 e2,3 Regla e3,1
Overlapped Overlapped Overlapped o Disjoint
Overlapped Disjoint Overlapped o Disjoint
Disjoint Disjoint Overlapped o Disjoint
Es decir, un triángulo formado sólo por enlaces overlapped o disjoint siempre es coherente.Y por tanto las reglas interesantes de aplicar son sólo las siguientes:
e1,2 e2,3 Regla e3,1
Simultaneous Simultaneous Simultaneous
Simultaneous Overlapped overlapped
Simultaneous Disjoint Disjoint
En palabras, esto signi�ca que si existe un enlace simultaneous, los otros dos enlacesdeben tener el mismo valor, ya sea simultaneous, overlapped o disjoint. Por lo tanto, no esnecesario analizar la coherencia de los caminos para las 3 formas distintas de elegir dos nodosen un triángulo, sino que basta con recorrer una sola vez todos los enlaces para determinarla coherencia.
Para el atributo type, se siguió la misma lógica de análisis realizada para el atributosimultaneity. Se concluye que si uno de los enlaces es permanent, entonces los otros dosdeben tener el mismo valor, ya sea permanent o intermitent.
4.2. Análisis de Ciclos de Más de 3 Nodos
Al principio de este capítulo se mencionó que para evaluar un ciclo se debía analizar los doscaminos posibles para las distintas formas de elegir dos nodos del ciclo. Sin embargo, basadosen la metodología de evaluación de Herskovic no es necesario realizar todas esas evaluacionespor separado, ya que basta con recorrer los enlaces del ciclo una sola vez para determinar si
25
esas evaluaciones son todas coherentes o todas incoherentes. Como se vio anteriormente, estotambién es válido para los ciclos de 3 nodos, por tanto, ahora en adelante, nos referiremos aciclos inválidos cuando para cualquier par de nodos del ciclo, los caminos posibles entre ellossean incoherentes.
Para la evaluación de ciclos de más de 3 nodos se siguen los mismos principios que paralos ciclos de 3 nodos. Las variables type y simultaneity se consideran independientes. Ambasvariables sólo tienen un tipo de regla aplicable:
Lema 4.3 Considerando un ciclo de k nodos n123..k, si todos los ei,i+1 para i ∈ [1, k − 1] sonsimultaneous, entonces ek,1 debe ser simultaneous también.
Lema 4.4 Considerando un ciclo de k nodos n123..k, si todos los ei,i+1 para i ∈ [1, k − 1] sonpermanent, entonces ek,1 debe ser permanent también.
Las reglas anteriores permiten determinar que hay una incoherencia en la interacciónocurrida dentro de un ciclo. Sin embargo, no se puede aplicar corrección automática ya quelas modi�caciones necesarias a realizar dependen del sistema modelado, por tanto el usuariode la herramienta debe revisar los errores presentados y corregir de acuerdo a su criterio.
4.3. Algoritmo de Evaluación
El algoritmo para evaluar las coherencias presentado por Herskovic, consiste en encontrartodos los ciclos, luego separarlos en ciclos de largo 3 y ciclos de largo mayor a 3, y �nalmenteaplicar las reglas de validación a ambos tipos de ciclos en forma separada. A continuación sepresenta el seudo código de su algoritmo de evaluación:
BEGIN MCM -V ALGORITHM
Graph graph = getGraph ();
Vector <Triangle > T = graph.getTriangles ();
for {each triangle t in T}
if {! t is valid according to rules}
report inconsistency in triangle t
end if
end for
Vector <Cycle > C = graph.getCycles (); // excludes triangles
for each cycle c in C,
for i = 1,...,N
if (! s(i,i+1) is valid given path r(i+1,...,i))
report inconsistency in cycle c
end if
end for
end for
END
26
De acuerdo con Herskovic el algoritmo de validación presentado tiene la siguiente comple-jidad, donde n es la cantidad de nodos, m la cantidad de enlaces, c la cantidad de ciclos, yk una constante.
• Encontrar todos los ciclos: O((n + m)c)
• Chequear la consistencia de las reglas en cada triángulo: O(k)
• Chequear la consistencia de cada ciclo de largo mayor a 3: O(n)
Lo que da como resultado una complejidad total de O(c(2n + m + k)).
Esto signi�ca que encontrar y evaluar cada ciclo toma tiempo polinomial. Sin embargo, lacantidad de ciclos en un grafo crece exponencialmente en la medida que aumenta la diferenciaentre enlaces(m) y nodos(n).
El peor de los casos es el grafo completo. A continuación se muestra una tabla con lacantidad de ciclos para grafos completos con distintas cantidades de nodos.
n m ciclos
3 3 1
4 6 7
5 10 37
6 15 197
7 21 1.172
8 28 8.018
9 36 62.814
10 45 556.014
11 55 5.488.059
12 66 59.740.609
Tabla 4.1: Cantidad de ciclos para grafos completos con n nodos y m enlaces
Estas cifras sirven para ilustran el crecimiento exponencial de la cantidad de ciclos. Enel uso habitual de la herramienta es poco probable que se llegue a tan elevada cantidad deciclos, pero aun así puede ser una gran cantidad. Considerando que el ambiente de ejecuciónde la aplicación es el browser, el usuario podría llegar a tener retardos de algunos segundosen la respuesta del análisis, con el correspondiente bloqueo de la interactividad en la interfazsi no se realiza un procesamiento por lotes.
Con el �n de disminuir el efecto exponencial de los ciclos se investigó los distintos algorit-mos disponibles para encontrar todos los ciclos de un grafo.
Un grafo de n nodos ym enlaces posee un árbol cobertor que usa n−1 enlaces. Cada enlaceadicional forma un ciclo independiente. Por lo tanto, la cantidad de ciclos independientes o
27
base que puede tener un grafo son m − (n − 1). Se dice que estos ciclos son independientesporque cada uno posee un enlace que no pertenece a ningún otro ciclo. Todos los demás ciclosse pueden obtener realizando diferencias simétricas entre dos o más ciclos base, pero ésta noes la forma más e�ciente de encontrar todos los ciclos.
Los primeros algoritmos para encontrar todos los ciclos datan de los años 70 y estabandestinados a grafos dirigidos. Entre estos se encuentran:
• Tarjan [Tar73], O(nmc)
• Johnson [Joh75], O((n + m)c)
• Szwarc�ter and Lauer [Szw76], O(n + mc)
Cabe destacar que usar un algoritmo para grafos dirigidos en un problema de grafo nodirigidos añade ine�ciencias y entregan más ciclos de los que corresponden, por lo que sedebe modi�car el algoritmo, y/o �ltrar posteriormente los grafos equivalentes.
Por su sencillez se implementó el algoritmo de Tarjan y el Szwarc�ter-Lauer. Los cualesen la práctica tuvieron rendimiento similar.
Posteriormente se encontró un algoritmo para grafos no dirigidos del año 2012, Birmelé etal [Bir12], el cual tiene complejidad optima de O(m+
∑c∈C(G) |c|), donde C(G) es el conjunto
de todos los ciclos de un grafo G.
La implementación de este algoritmo requiere de muchos más pasos y complejidad que losalgoritmos de Tarjan o Szwarc�ter-Lauer. La implementación de este algoritmo se postergóinicialmente, y luego como se explica más adelante no fue necesario.
Con el �n de disminuir el tiempo de ejecución se buscó hipótesis que permitieran evaluarel modelo sin tener que encontrar todos los ciclos. Por ejemplo, se consideró como hipótesisque si todos los ciclos base de un grafo son válidos entonces todos los demás ciclos generadosmediante la diferencia simétrica de ciclos base es también válida. Esta hipótesis lamentable-mente es falsa, incluso cuando el conjunto base de ciclos son triángulos, como lo muestra la�gura 4.3, donde una base posible son los 4 triángulos que se forman tomando dos nodos ex-teriores adyacentes más el nodo central. En la �gura se puede apreciar que estos 4 triángulosson válidos, no así el ciclo externo.
Finalmente se dio con un algoritmo e�ciente basado en los siguientes principios:
• Un ciclo invalido de k enlaces está formado por k − 1 enlaces simultaneous y 1 nosimultaneous(es decir, overlapped o disjoint), o por k − 1 enlaces permanent y 1 nopermanent(es decir, intermitent).
• No es necesario mostrar todos los ciclos inválidos a la vez, sino sólo uno que el usuariodeba corregir.
El algoritmo es el siguiente:
Inicialmente se cuenta con una representación del grafo como una tabla de adyacencia, yuna matriz de enlaces. Si no existen estas estructuras, se pueden crear en O(m).
28
Figura 4.3: Modelo HWSN con ciclos inválidos
Primero se procede a buscar los triángulos del grafo, cuando se encuentra uno, se valida conlas reglas de coherencias para triángulos. Si no es válido, el algoritmo termina y se muestraal usuario el triángulo inválido para que lo corrija.
Si el paso anterior recorre todos los triángulos y no encuentra ninguno inválido, se procedea buscar los ciclos de largo mayor a 3 inválidos. Para ello se toman todos los enlaces del grafoy se clasi�can en simultaneous, no simultaneous, permanent y no permanent. A continuaciónse realiza separadamente la evaluación de los atributos simultaneity y type. Para el atributosimultaneity, primero se crea una tabla de adyacencia sólo con los nodos de los enlacesclasi�cados como simultaneous. Luego por cada enlace clasi�cado como no simultaneous,llamémoslo nsEdge, se busca el camino más corto entre los nodos que forman nsEdge usandola tabla de adyacencia recién creada. La razón de buscar el camino más corto, es para mostraral usuario el ciclo más pequeño que es inválido debido al enlace nsEdge.
Si se encuentra un camino, entonces existe un ciclo inválido, ya que el camino está formadosolo por enlaces simultaneous y el enlace nsEdge que cierra el ciclo es non simultaneous. Luegose procede a terminar el algoritmo y mostrar al usuario el ciclo inválido para que lo corrija.Para el atributo type se debe seguir la misma metodología.
Si se quisiera presentar visualmente al usuario todos los ciclos inválidos causados, porejemplo, por un enlace no simultaneous, se puede modi�car el algoritmo anterior para queen vez de retornar el camino más corto, retorne la lista de enlaces de la unión de todos losciclos inválidos. Como no es necesario individualizar los ciclos inválidos, se puede realizar enO(m + n) con un algoritmo que retorne la componente biconectada donde se encuentre elenlace no simultaneous, del subgrafo G(V , E) ⊆ G(V,E), donde E es subconjunto de todoslos enlaces simultaneous de E union el enlace nsEdge, y V los nodos de los enlaces en E.
El algoritmo de evaluación en seudo código es el siguiente:
29
BEGIN HWSN -V ALGORITHM
Graph graph = getGraph ();
Vector <Cycle > anInvalidTriangle = validateTriangles(graph);
if anInvalidTriangle is not null
return anInvalidTriangle
end if
simultaneousList = []
nonSimultaneousList = []
permanentList = []
nonPermanentList = []
for each Edge e in graph
if e is simultaneous
simultaneousList.add(e)
else
nonSimultaneousList.add(e)
end if
if e is permanent
permanentList.add(e)
else
nonPermanentList.add(e)
end if
end for
AdjacencyList A = buildAdjacencyListFromEdges(simultaneousList)
for each Edge e in nonSimultaneousList
path = findPath(A, source(e), target(e))
if path is not null
invalidCycle = path.add(e)
return invalidCycle
end if
end for
AdjacencyList A = buildAdjacencyListFromEdges(permanentList)
for each Edge e in nonPermanent
path = findPath(A, source(e), target(e))
if path is not null
invalidCycle = path.add(e)
return invalidCycle
end if
end for
END
La complejidad de este nuevo algoritmo es la siguiente:
• Encontrar todos los triángulos O(n3).
• Clasi�car los enlaces en simultaneous, no simultaneous, permanent y no permanenttiene costo O(m).
• Encontrar los ciclos mayores a 3 inválidos = encontrar los ciclos inválidos para el atri-buto simultaneity + encontrar los ciclos inválidos para el atributo type.
• Encontrar los ciclos inválidos del atributo simultaneity = crear la lista de adyacencia
30
+ encontrar el camino más corto para cada enlace no simultaneous. Para crear la listade adyacencia se deben recorrer todos los enlaces simultaneous, lo cual es O(m). Elcamino más corto se puede encontrar mediante el algoritmo de Breadth First Searchen O(m + n). El costo total por tanto es O(m + m(m + n)).
• Encontrar los ciclos inválidos para el atributo type. Este paso al igual que el anteriortiene costo O(m + m(m + n)).
Por tanto la complejidad total del algoritmo es O((n3) + 3m + 2m(n + m)). Como lacantidad de enlaces posibles m es menor a n2. La complejidad �nal en términos de n esO(n4).
Debemos notar que el output de este algoritmo es distinto al algoritmo de Herskovic. Estealgoritmo retorna sólo el primer ciclo inválido que encuentra, mientras que el de Herskovicretorna todos los ciclos inválidos. El hecho de que el algoritmo de Herskovic almacene enmemoria todos los ciclos antes de empezar a evaluar es una limitación en su implementación,pero no un factor relevante en el análisis ya que no hay motivos para no hacer la validación delos ciclos a medida que se van encontrando. En el presente algoritmo se consideró que bastabacon presentar un ciclo inválido al usuario para que hiciera la corrección. Presentar más de unosólo abrumaría al usuario, más aun, el hecho de corregir un enlace signi�ca necesariamentetener que realizar la evaluación nuevamente.
La complejidad de este algoritmo no depende de la cantidad de ciclos, lo que en la prácticaresulta en una buena performance, al punto que se decidió realizar la evaluación de maneracontinua. Es decir, cada que vez que se cambia la cantidad o atributos de los enlaces, seejecuta automáticamente la evaluación, desplegando en la interfaz inmediatamente los ciclosinválidos.
31
Capítulo 5
Reporte de Requerimientos
Hay varios requisitos generales que deben ser considerados cuando se desarrolla cualquiertipo de software. La mayoría de ellos corresponden a requisitos de calidad, como mantenibi-lidad, �exibilidad y con�abilidad. Algunos requerimientos especí�cos han sido descritos paratipos de sistemas especí�cos, por ejemplo, sistemas colaborativos. Nos referiremos a estasnecesidades recurrentes como requerimientos generales. Tener una lista de requerimientosgenerales para sistemas colaborativos puede reducir la complejidad en el proceso de desarro-llo. Estos requerimientos están usualmente relacionados con procesos en background a cargode proveer mecanismos de soportes para habilitar la colaboración en un escenario de traba-jo colaborativo. Desafortunadamente, estos requerimientos generales no son visibles para lamayoría de los usuarios y desarrolladores. Por lo tanto, los desarrolladores pueden pasar poralto la consideración de estos requerimientos en el proceso de desarrollo o pueden incluirlosdemasiado tarde, poniendo en peligro el éxito del proyecto.
5.1. Requerimientos
Herskovic en su tesis doctoral [Her10] hizo un estudio de los requisitos generales que pue-den estar presentes en sistemas colaborativos. Una vez identi�cados hizo un match con losdistintos escenarios de colaboración presentes en su lenguaje de modelamiento considerandolas dimensiones de simultaneity y reacheability. A continuación se resume los distintos requi-sitos identi�cados por Herskovic, luego se presenta una adaptación del match al lenguaje demodelamiento de HWSN.
5.1.1. Flexibility
Los sistemas colaborativos deben soportar frecuentes cambios en tamaño de grupo y es-tructura, debido a que los participantes pueden conectarse o desconectarse del grupo. Algunosde los mecanismos que proveen �exibilidad son los siguientes:
32
Automatic peer detection: El espacio de trabajo colaborativo debe automáticamente co-lectar y mantener información de los participantes alcanzables. Además, el sistema debealmacenar la información relacionada a la disponibilidad del participante. Basado enesa información contextual el sistema colaborativo puede implementar mecanismos deawareness.
User connection / disconnection: Las aplicaciones pueden permitir a los usuarios tra-bajar o�ine la mayor parte del tiempo y cambiar a modo online en demanda. De estaforma, los participantes son capaces de elegir su propio nivel de involucramiento en lacolaboración de acuerdo a sus necesidades.
5.1.2. Consistency and Availability
Desconexiones frecuentes y trabajo autónomo usualmente causan inconsistencias e indis-ponibilidad de recursos que están siendo compartidos por miembros del grupo. Algunos de losrequerimientos que apoyan la consistencia y disponibilidad de información son los siguientes:
Explicit data replication: Durante periodos de conexión, un usuario debe poder compar-tir información con otro, de manera que esta información este disponible para amboscuando ellos ya no estén conectados.
Caching: Cuando los usuarios estén colaborando, se debe replicar automáticamente tantainformación como sea posible en el espacio de trabajo de cada usuario, con el propósitode proveer a cada usuario con la información más actualizada cuando estén haciendotrabajo autónomo.
Con�ict resolution: Cuando los usuarios del sistema colaborativo realizan trabajo autó-nomo, pueden actualizar información local. Eventualmente, esto puede generar incon-sistencias en la información compartida. La sincronización de información requiere dealgoritmos de resolución de con�ictos para reconciliar la información con el propósitode tener una vista común de la información compartida.
5.1.3. Connectivity
Muchos escenarios de trabajo carecen de una infraestructura de comunicación wireless ola posibilidad de implementar una. En estos casos, la aplicación puede usar una red móvil ad-hoc (MANET). Los problemas de conectividad deben ser transparentes para el usuario �nal,de otra manera, la capacidad de colaboración estaría en riesgo. Los siguientes mecanismospueden ayudar a proveer conectividad a los usuarios de aplicaciones colaborativas móviles.
Automatic connection: La red MANET debe ser formada y mantenida automáticamentepor las aplicaciones colaborativas corriendo en cada nodo participante. Esto incremen-ta las capacidades de interacciones entre los participantes y también incrementa ladisponibilidad de recursos compartidos.
33
Service and device discovery: servicios y dispositivos disponibles deben ser automática-mente detectados e integrados perfectamente en el ambiente colaborativo. Esto puedeapoyar el proceso de colaboración durante interacciones casuales.
Message routing: Este mecanismo de comunicación usa workers móviles como intermedia-rio para proveer un camino de comunicación entre dos nodos que tienen más de unsalto de distancia entre ellos. El ruteo de mensajes convierte una red one-hop en unamulti-hop.
User gossip: Este servicio está basado en mensajes gossip enviados por un usuario (interesa-do en comenzar un proceso colaborativo) a un participante no alcanzable directamente,a través de nodos vecinos intermediarios. El movimiento de esos nodos (y del nodo noalcanzable) puede eventualmente permitir la entrega del mensaje. El mensaje usual-mente lleva información acerca de la ubicación del solicitante en un futuro cercano. Esainformación (si es recibida por el participante no alcanzable) puede facilitar el comienzode la comunicación.
5.1.4. Heterogeneity and Interoperability
Sin importar el dispositivo usado para acceder a la aplicación colaborativa, una personadebe ser capaz de interactuar con cualquier colaborador usando la misma aplicación. Lasdiferencias entre dispositivos son una carga para los usuarios que el sistema colaborativodebe facilitar. Los requerimientos que deben ser considerados son los siguientes:
Heterogeneity: La colaboración puede involucrar dispositivos heterogéneos como note-books o teléfonos inteligentes. Estos dispositivos tienen diferentes características dehardware y de computo. Los sistemas colaborativos móviles deben ser diseñados parasoportar al menos el paso de mensajes entre los varios tipos de dispositivos.
Interoperability: Es recomendado diseñar una versión de la aplicación colaborativa paracada tipo de dispositivo móvil considerado en el proceso colaborativo. Esto asegura quela aplicación tomará las ventajas de las características particulares de cada dispositivo.La interoperabilidad de datos y servicios debe estar asegurada para cada versión delsistema con el propósito de prevenir que los usuarios queden aislados involuntariamente.
5.1.5. Communication
Los usuarios de sistemas colaborativos necesitan comunicarse entre ellos, y un mecanismopara hacer eso es el intercambio de mensajes (por ejemplo, notas, documentos, alarmas).Como los usuarios pueden estar en movimiento para llevar a cabo sus actividades, algunosde ellos pueden estar no disponibles durante algún tiempo. Por lo tanto, los sistemas debenproveer mecanismos para la comunicación síncrona/asíncrona y el envío de mensajes de formaatendida o desatendida. Algunos de estos mecanismos son los que se describen a continuación:
34
Synchronous messaging: Cuando dos usuarios están simultaneamente disponibles y hayun medio de comunicación, ellos pueden intercambiar mensajes para sincronizar suespacio de datos compartidos o recibir noti�caciones.
Asynchronous messaging: Cuando dos usuarios trabajan en diferentes momentos, el sis-tema debe permitirles enviar mensajes que recibirá el otro usuario cuando esté nueva-mente disponible. Ejemplos de mensajería asíncrona son los correos electrónicos, o elenvío de mensajes cuando un usuario se conecta a un servidor.
File transfer: Los colaboradores del sistema pueden llevar a cabo tareas débilmente inter-dependientes. Típicamente los miembros de un grupo de trabajo particular mantienen,en el espacio de trabajo local, los recursos que son relevantes para realizar sus tareasasignadas. Los nuevos miembros asignados al grupo de trabajo pueden requerir obtenerla información compartida desde los otros participantes con el propósito de empezar arealizar una tarea particular. La transferencia de archivos es un mecanismo requeridopara tratar con esta necesidad y varios otros servicios de un sistema colaborativo, comola colaboración espontánea entre dos usuarios.
Pushing noti�cations: Los mensajes son entregados a los usuarios móviles en el momentoen que ellos se conectan al servidor. Típicamente una ventana pop-up puede ser usadapara desplegar los mensajes pendientes en la interfaz de usuario.
5.1.6. Awareness
Para soportar el trabajo colaborativo el sistema debe proveer los mecanismos de aware-ness para mejorar el entendimiento entre los usuarios. La información que presentan estosmecanismos debe ser actualizada a medida que se recibe nueva información. La informaciónse debe presentar a medida que ocurre, pero sin abrumar a los receptores, lo cual podríadisminuir la habilidad de percibirla. Algunos de los tipos de awareness que podrían estarsoportados son los siguientes:
Online awareness: Ejemplos de online awareness son las listas de usuarios conectados,ubicaciones de usuario y su actividad actual.
O�ine awareness: Ejemplos de o�ine awareness son las últimas modi�caciones disponiblespara un documento y su autor.
Transition awareness: Awareness relacionadas a la transición entre conexión y descone-xión, como el awareness de conexión de un usuario o el awereness de la entrega de unmensaje.
5.1.7. Protection
El sistema colaborativo debe incorporar las medidas que aseguren que el trabajo de cadausuario está protegido. Algunas de estas medidas se mencionan a continuación:
35
Ad-hoc work sessions: La interacción entre usuarios debe estar protegida con el propósitode evitar la participación no autorizada en el grupo y el acceso inválido a recursoscompartidos entre ellos. Sesiones de trabajo ad-hoc son mecanismos para tratar conesta necesidad.
User privacy: Cada usuario debe poder elegir que información compartir y algunas accionespueden ser realizadas privadamente. Los usuarios están más dispuestos a colaborar sisu privacidad es respetada.
Security: El trabajo de cada usuario debe estar protegido de manera que nadie puede ma-liciosamente o por error, borrar el trabajo de alguien más.
Naturalmente, estos son una fracción de todos los requerimientos del backend de un sistemacolaborativo. Otros requerimientos deberían también ser considerados, por ejemplo, reque-rimientos que permitan soportar el trabajo autónomo que los usuarios hacen en periodosde trabajo aislado. Ignorar los presentes requerimientos puede causar que los desarrollado-res construyan un sistema que carezca de los componentes fundamentales que soportan ofacilitan la colaboración. Por supuesto, algunos requerimientos pueden ser intencionalmenteignorados de acuerdo a las necesidades particulares de la aplicación que se esté desarrollando.Por ejemplo, una aplicación móvil cuyo objetivo es tener tantos usuarios como sea posibleleyendo y comentando noticias probablemente no necesite implementar sesiones de trabajoad-hoc para proteger la información compartida.
5.2. Match entre Requerimientos y Tipos de Interacción
Cada participante del sistema colaborativo debe implementar una selección de los reque-rimientos mencionados anteriormente dependiendo de la forma en como interactua con losdemás participantes.
Los requerimientos descritos se pueden agrupar de acuerdo al tipo de colaboración en elcual ellos son necesitados. Cada requerimiento puede estar presente en uno o más tipos deinteracción. Algunos requerimientos (service and device discovery, heterogeneity, interopera-bility, user privacy y security) no fueron agregados porque no están relacionados a la situaciónde colaboración entre dos participantes.
Herskovic hizo un match entre los requisitos y los distintos escenarios de colaboración desu lenguaje de modelamiento considerando las dimensiones de simultaneity y recheability[Her10]. Adaptar su match al lenguaje de HWSN no fue un proceso directo debido a la dife-rencia en como se caracterizan los participantes y la comunicación entre ellos. Por ejemplo,en el lenguaje de Herskovic, si dos nodos tienen comunicación non-simultaneous recheable, sesugiere el requerimiento de mensajería asíncrona, ya que se asume implícitamente la existen-cia de un servidor intermediario. En el caso de las HWSN, si dos nodos tienen comunicaciónDisjoint-Intermitent, no existe comunicación posible. Para que esos dos nodos se puedan co-municar mediante mensajería asíncrona requieren de por ejemplo, un servidor intermediario,con capacidad de almacenamiento y procesamiento para entregar el mensaje. Pero ese servi-
36
dor corresponde a un Witness Unit, un nodo formal en las HWSN, con el cual los otros dosnodos tendrían comunicación Overlapped-Intermitent. Por lo tanto, dos nodos con periodosde trabajo disjoint no se pueden comunicar directamente. Solo lo pueden hacer a través deun intermediario que corresponde a un nodo formal de la red.
Entre mayor es la incertidumbre de cómo tomará lugar la comunicación, mayor es la can-tidad de requisitos que deben ser soportados. Por ejemplo, cuando dos nodos interactuan deforma Overlapped-Intermitent, hay periodos en que los nodos trabajan en forma separada yotros en forma simultanea, así mismo hay periodos donde está disponible el medio de comuni-cación y otros no. Para dar soporte a la colaboración ante estas incertidumbres es necesario lapresencia de la mayoría de los requisitos descritos. Por otro lado, cuando hay más certeza de laforma en como ocurre la colaboración, son mucho menos los requerimientos necesitados, porejemplo, en el caso en que los nodos que se comunican de manera Simultaneous-Permanent.
La tabla 5.1 presenta la clasi�cación de los requerimientos en los distintos tipos de inter-acción posible: Simultaneous-Permanent (SP), Simultaneous-Intermitent (SI), Overlapped-Permanent (OP), Overlapped-Intermitent (OI), Disjoint-Permanent (DP) y Disjoint-Intermitent(DI).
Requirement SP SI OP OI DP DI
Adhoc work sessions X X X X
Asynchronous messaging X X X
Automatic connection X X X
Automatic peer detection X X X
Caching X X X
Con�ict resolution X X X X
Explicit data replication X X X
File transfer X X X X
Message routing X X
O�ine awareness X X X
Online awareness X X X
Pushing noti�cations X X X
Synchronous messaging X X X X
Transition awareness X X X
User connection/disconnection X X X
User gossip X X
Tabla 5.1: Clasi�cación de requerimientos de acuerdo al tipo de interacción
Clasi�car los requerimientos para sistemas colaborativos de acuerdo a los tipos de inter-acciones posible permite darnos cuenta que no todas las colaboraciones toman lugar de lamisma manera. Por lo tanto, los requerimientos que deben estar presente en un una aplicacióndependen de los tipos de interacciones que los usuarios necesiten.
37
La generación de requerimientos realizada por Herskovic, así como la presente, están limi-tadas por el hecho de considerar solo la comunicación con los vecinos directos. Por ejemplo,en la �gura 5.1, el nodo A interactúa con el nodo B en forma Simultaneous-Intermitent, lomismo ocurre para los nodos D y E. La lista de requerimientos para estos 4 nodos sugiereimplementar user gossip. En tanto, el nodo C sólo se comunica con sus vecinos de maneraSimultaneous-Permanent, por lo que no se le sugiere implementar user gossip. Si el nodo Aquisiera enviarle un mensaje al nodo E, usando el mecanismo user gossip, el mensaje no lellegaría, ya que C puede no tener implementado el mecanismo. La mejora en la generaciónde la lista considerando este tipo de situaciones, requiere un análisis e implementación máselaborada, por lo que se dejó como trabajo futuro.
Figura 5.1: Modelo HWSN con ciclos inválidos
5.3. Reporte
La forma en que se presenta la lista de requerimientos en la herramienta de modelamientoes mediante un panel �otante que se muestra al habilitar el botón correspondiente en la barrade herramientas.
Cada nodo posee requerimientos distintos de acuerdo a como interactúa con los demásnodos. En el panel �otante se muestra la lista y estado de los requerimientos para el nodoseleccionado (�g 5.2). Si el usuario selecciona otro nodo, el panel se actualiza para mostrarla información correspondiente al nuevo nodo seleccionado. Si no tiene seleccionado un nodo,o tiene seleccionado más de uno, se le indica en el panel una sugerencia para volver a verinformación de requisitos.
La tabla que se muestra en el panel tiene 3 columnas. La primera muestra la lista derequerimientos. La segunda muestra un checkbox que indica si el requerimiento debe es-tar presente. La tercera muestra otro checkbox en el que el diseñador puede registrar si elrequerimiento ya fue implementado.
Cuando se pasa el mouse por encima de una �la se resaltan los enlaces del nodo seleccio-nado que hacen que ese requisito sea necesario.
Si el diseñador considera que ciertos requerimientos no son necesarios para la aplicaciónque está desarrollando puede desmarcar el requisito en la segunda columna. También, siconsidera que un requisito no necesario debe ser implementado, entonces puede marcarlo. Laforma en como se visualiza el checkbox de la segunda columna, depende de si el requisito esnecesitado y si está habilitado o no. Esto permite identi�carlos fácilmente si en un futuro
38
Figura 5.2: Visualización del panel con lista de requerimientos del nodo seleccionado
se quiere deshacer las modi�caciones realizadas a los resultados del análisis. En la �gura5.2, con�ict resolution era recomendado, pero se deshabilitó, visualizándose como un puntopequeño. En cambio, user gossip no era recomendado y se habilitó, visualizándose con uncolor más claro.
Las modi�caciones que realiza el diseñador con respectos a los requerimientos que debenestar presentes, junto con la información de los requisitos ya implementados, se almacenan enlos nodos del grafo, guardándose junto al modelo cuando se genera un archivo del documento.Los requerimientos no modi�cados no se almacenan ya que se generan en el momento que elusuario seleccione un nodo. Esto permite generar fácilmente la lista de requerimientos si lasinteracciones del nodo cambian.
Los requerimientos presentados en la lista están asociados a procesos de background porlo que generalmente no son visibles para la mayoría de los desarrolladores. Comenzar adesarrollar teniendo esta lista de requerimientos puede facilitar el desarrollo del software,especialmente para desarrolladores sin mucha experiencia en el área. Ignorar la presente listapuede causar que los desarrolladores construyan un sistema que carezca de componentesfundamentales que soporten o faciliten la colaboración.
39
Capítulo 6
Conclusiones y Trabajo Futuro
Diseñar software colaborativo es una tarea compleja debido a la heterogeneidad y dina-mismo de las interacciones que deben ser soportadas en el escenario de la aplicación. Apoyarla fase de diseño de este tipo software, ayuda al entendimiento del sistema y a prever lainclusión de características que de otro modo se agregarían demasiado tarde, poniendo enriesgo el éxito del proyecto.
La herramienta de software desarrollada facilita la creación de modelos usando el lenguajepropuesto por los investigadores del DCC. La herramienta presenta un lienzo sobre el cualse puede crear y modi�car en forma interactiva los participantes del sistema colaborativo ycomo estos interactuan entre sí. Su comportamiento es similar a otros software de edición dediagramas por lo que se espera una fácil adopción, sin embargo, para su uso es fundamentalconocer y entender el lenguaje de modelamiento.
El lenguaje de modelamiento es simple y permite a los diseñadores modelar escenarios deinteracción complejos mediante la especi�cación de las relaciones punto-a-punto. La caracte-rización de los participantes y la forma en que estos interactúan forman un grafo, sobre el cualse puede computar análisis de forma automática. El grafo presenta una vista general del esce-nario de colaboración, por tanto permite a los desarrolladores entender el sistema, comunicarprácticas de trabajo, determinar requerimientos y diseñar una aplicación apropiada.
Uno de los análisis que se puede computar a partir del grafo, es la evaluación de coherenciade las interacciones entre los participantes del sistema modelado. El algoritmo de evaluacióndesarrollado durante esta memoria, presenta mejoras signi�cativa de rendimiento, compara-do al previamente existente, permitiendo que la evaluación se realice en forma automática amedida que se va construyendo el modelo. De esta forma el diseñador va agregando mejo-raras incrementales estando seguro de que entiende las interacciones del escenario que estámodelando.
Otro análisis implementado en la herramienta es la generación de requerimientos generalesasociados a dar soporte a la colaboración. Cada participante del sistema tiene sus propiosrequerimientos de acuerdo a los tipos de interacciones que debe soportar. La lista de requeri-mientos generada puede ser re�nada por el diseñador de acuerdo a las necesidades particulares
40
de la aplicación que está desarrollando. Comenzar a desarrollar teniendo esta lista de reque-rimientos puede facilitar el desarrollo del software, especialmente para desarrolladores sinmucha experiencia en el área, ya que estos requerimientos usualmente están ocultos. Ignorarla presente lista puede causar que los desarrolladores construyan un sistema que carezca decomponentes fundamentales que soporten o faciliten la colaboración.
La herramienta desarrollada facilitará a los investigadores del área la experimentación connuevos escenarios colaborativos que pueden contribuir a la re�nación del lenguaje. El fácilacceso, puede incentivar a otros investigadores a utilizar el lenguaje y de esta forma obtenerfeedback de situaciones no consideradas que se pueden traducir en mejoras.
Como trabajo futuro se puede implementar cuentas de usuario y almacenamiento en ellado del servidor que faciliten el versionamiento de los modelos. Con respecto a esto, seríainteresante contar con utilidades que permitan visualizar la evolución del modelo, así comoestadísticas en el progreso de la implementación de los requisitos generales.
Además, se podrían agregar más análisis, como por ejemplo, un análisis de la conectividadde la red que permita determinar cuales son los enlaces de comunicación más vulnerables,que en caso de fallar pueden dejar aislada una parte de la red colaborativa.
Se espera que la herramienta contribuya a fomentar el uso del lenguaje, y de esta forma,facilitar el desarrollo de sistemas colaborativos que aprovechen los nuevos e interesantesescenarios de colaboración.
41
Bibliografía
[Bir12] E. Birmelé, R. Ferreira, R. Grossi, A. Marino, N. Pisanti, R. Rizzi, G. Tominaga,and M. Sagot. Optimal Listing of Cycles and st-Paths in Undirected Graphs. CoRR,abs/1205.2766, 2012.
[Her10] V. Herskovic. Evaluation of Mobile Shared Workspaces to Improve their Support forCollaboration. Ph.D. thesis, Universidad de Chile, 2010.
[Joh75] D. Johnson. Finding All the Elementary Circuits of a Directed Graph. SIAM Journalon Computing, 4(1):77�84, 1975.
[Mon14] A. Monares, S. Ochoa, V. Herskovic, R. Santos, and J. Pino.Modeling interactions inhuman-centric wireless sensor networks. In Computer Supported Cooperative Workin Design (CSCWD), Proceedings of the 2014 IEEE 18th International Conferenceon, pages 661�666. May 2014.
[Och15] S. Ochoa and R. Santos. Human-centric wireless sensor networks to improve infor-mation availability during urban search and rescue activities. Information Fusion,22(0):71 � 84, 2015.
[Szw76] J. Szwarc�ter and P. Lauer. A search strategy for the elementary cycles of a directedgraph. BIT Numerical Mathematics, 16(2):192�204, 1976.
[Tar73] R. Tarjan. Enumeration of the Elementary Circuits of a Directed Graph. SIAMJournal on Computing, 2(3):211�216, 1973.
42
