Statistical Comparison of GC and HPLC

Como se ha explicado anteriormente, después de la etapa de descripción, el ciclo de vida de las aplicaciones de Calvin llega a la etapa de Conexión. En dicha etapa de conexión, se define lo que se llama el Data Flow Graph, es decir, la representación del flujo de datos de una aplicación concreta. Para ello, se hace uso de un lenguaje de scripting fácil de utilizar y compacto llamado CalvinScript, que permite la conexión de los actores entre sí, entre otras cosas. El siguiente apartado describe este lenguaje de Scripting y explica brevemente su funcionamiento.

3.4.1.1 Calvin Script

El CalvinScript se define como un archivo con extensión “.calvin”, y únicamente tiene que cumplir las 2 siguientes características:

- Se deben especificar todos los actores que participaran en la ejecución de la aplicación. - Se deben describir todas las conexiones y reglas que definen el flujo de datos de la

aplicación.

A continuación, se explica un ejemplo de CalvinScript:

FIGURA 10:EJEMPLO DE CALVINSCRIPT.RECUPERADA DE [33] 1.

2. # Actors

3. trigger : std.Trigger(tick=1, data=null) 4. sense : sensor.Temperature() 5. print : io.Print() 6. 7. /* Connections */ 8. trigger.data > sense.measure 9. sense.centigrade > print.token 10.

En este ejemplo, recuperado de la documentación de la plataforma (ver enlace figura anterior): - Se han definido tres actores: trigger, que es un actor básico de tipo std.Trigger; sense, que es un actor de tipo sensor.Temperature y out, que es otro actor más básico, de tipo

io.Print. Ambos son actores previamente definidos y disponibles en el Actor Store de la plataforma.

- El flujo de datos se podría traducir de la siguiente forma:

o Cuando trigger.data es True, se envía un mensaje al actor sense, haciendoque

el valor en el puerto measure sea True. Es decir que cada 1 segundo, se activa la medición.

o Sense escribe entonces los datos disponibles en el puerto de salida centigrade.

Teniendo sus datos de salida listos, Sense remite el mensaje al actor print

- Como se puede apreciar, el conjunto de actores de la plataforma se divide en Namespaces, o Espacios de Nombres, para facilitar la organización y utilización de estos.

Por lo tanto, el actor print redirigirá los datos recibidos a la consola, ya que tiene definida la siguiente tarea:

1.

2. @stateguard(lambda self: calvinsys.can_write(self.stdout)) 3. @condition(action_input=['token'])

4. def write(self, data):

5. calvinsys.write(self.stdout, data)

Al estar la lógica definida en el propio actor, han conseguido implementar un lenguaje de Scripting de alta simplicidad y altamente reutilizable que puede facilitar y acelerar muchísimo el desarrollo de aplicaciones IoT ya que la mayoría de los actores necesarios ya han sido implementados en desarrollos previos. Esto permite dejar que el desarrollador se centre en el desarrollo de la aplicación en sí, y no tenga que preocuparse, en la medida de lo posible, por el manejo de las capas subyacentes (por ejemplo, la capa de comunicación).

En adición a las entidades descritas anteriormente, queda comentar que el lenguaje CalvinScript soporta la definición de Componentes (ver wiki mencionada anteriormente). A nivel conceptual, un componente es simplemente una entidad que agrupa varios actores y define su flujo de datos de tal forma que ofrece una funcionalidad concreta a la aplicación. Por lo tanto, para la aplicación, un componente tendrá exactamente las mismas características y los mismos comportamientos que un actor, y aporta al framework una flexibilidad adicional, ya que así se consigue también la reutilización de flujos de datos previamente definidos. Los siguientes ejemplos, extraidos del repositorio de ejemplos de la plataforma, muestran cómo se define un componente a partir de actores.

1.

2. component LoggerPrefixed(logname, loglevel) data -> { 3. prefix: text.PrefixString(prefix=logname) 4. snk : io.Log(loglevel=loglevel) 5. 6. .data > prefix.in 7. prefix.out > snk.data 8. }

1. component DelayedCounter(delay) -> integer {

2. """ Counts from 0 and up, waiting 'delay' seconds between numbers """ 3. counter : std.Counter() 4. delay : std.ClassicDelay(delay=delay) 5. 6. counter.integer > delay.token 7. delay.token > .integer 8. } 9.

Luego, se podrán utilizar dichos componentes de la misma forma que se utiliza un actor, conectando sus puertos para formar un flujo concreto de datos.

3.4.1.2 La interfaz gráfica de Calvin – Calvin GUI

Para facilitar todavía más el desarrollo y sobre todo enfocarlo en el desarrollo de la aplicación, también se está desarrollando una herramienta visual llamada Calvin GUI, para la generación de CalvinScripts a partir de graficas que describen el flujo de datos.

FIGURA 11:INTERFAZ GRÁFICA DE CALVIN.

RECUPERADA DE [32]:

Como se detalla en la wiki referenciada en la imagen anterior, desde esta interfaz de usuario se tienen acceso a:

“

1. La lista de actores disponibles, listados y agrupados por sus respectivos espacios de

nombres.

2. La documentación del actor seleccionado, si existe.

3. El “canvas”, o espacio de trabajo donde se define el dataflow, es decir los actores de

la aplicación y sus conexiones.

4. El inspector, donde aparece la información útil del actor que este seleccionado. Sirve

para saber y, si así se desea, modificar el nombre y los parámetros iniciales de la instancia de un actor.

5. La pestaña de Runtime Overview, que ofrece información útil sobre los distintos Runtimes desplegados y sus capacidades.

6. Detalles de las capacidades soportadas en un Runtime concreto.

”

Se puede encontrar la información adicional necesaria sobre como instanciar y utilizar la GUI de Calvin en la parte correspondiente [32] de la documentación oficial de la plataforma.