Universidad Politécnica de Madrid

Facultad de Informática

Paradigmas de Programación

Comparación de los lenguajes de Dataflow LabVIEW y VEE

Javier Isaac Espinosa Muñoz

MUSS

Enero 2015

2

ÍNDICE DE CONTENIDOS

1. INTRODUCCIÓN…………………………………………………………… 3

1.1 PERSPECTIVA HISTORICA……………………………………. 3

2. CARACTERÍSTICAS DEL PARADIGMA DE DATAFLOW…………… 4

3. DATAFLOW………………………………………………………………… 5

4. ESTRUCTURA DE UN PROGRAMA EN DATAFLOW……………….. 7

5. LENGUAJES DATAFLOW……………………………………………….. 9

6 LABVIEW……………………………………………………………………. 11

6.1 DESARROLLO DE UN EJEMPLO EN LABVIEW…………… 16

7 AGILENT VEE……………………………………………………………… 17

7.1 DESARROLLO DE UN EJEMPLO EN AGILENT VEE……… 20

8. RESULTADOS……………………………………………………………... 21

8.1 VENTAJAS DE LABVIEW ……………………………………… 22

8.2 VENTAJAS DE VEE …………………………………………….. 23

8.3 INCONVENIENTES DE LABVIEW …………………………….. 24

8.4 INCONVENIENTES DE VEE …………………………………… 24

9. OPORTUNIDADES DE INVESTIGACIÓN………………………………. 26

10. CONCLUSIONES ………………………………………………………… 27

11. FUENTES Y BIBLIOGRAFIA …………………………………………… 30

3

1. INTRODUCCIÓN

El desarrollo de la programación gráfica ha cambiado dramáticamente la forma en

que el software de prueba y medida se utilizan en la actualidad. Además ha hecho

posible la creación de software y prototipos de forma más sencilla y rápida qué

antes.

En este trabajo se abordara la perspectiva histórica, hasta llegar a la parte qué

comprende la comparación, qué más qué eso es ver las cualidades, ventajas y

desventajas qué tienen ambos lenguajes frente a la filosofía de dataflow, para

realizar esto de la manera justa, se tratara un ejemplo idéntico con aplicación en

ambos entornos.

1.1 PERSPECTIVA HISTORICA

La motivación original para la investigación en el flujo de datos fue la explotación

del paralelismo masivo. Por lo tanto, se trabajó mucho para desarrollar la forma de

programar procesadores paralelos. Sin embargo, una escuela de pensamiento

sostenía que los procesadores "Von Neumann" convencionales eran

inherentemente inadecuados para la explotación del paralelismo, esto debido a su

contador del programa global y a la memoria qué al igual actualiza de manera

global, estas dos cualidades se convirtieron en un cuello de botella para el modelo.

Así qué la alternativa propuesta fue la arquitectura basada en flujos de datos

(dataflow) [1]. Lo que evita estos cuellos de botella es el uso de memoria sólo

local y mediante la ejecución de instrucciones tan pronto como sus operadores

estén disponibles. El nombre de dataflow viene de la idea conceptual que un

programa usado en un computador mediante el paradigma dataflow es un grafo

dirigido y que los flujos de datos entre instrucciones, a lo largo de sus arcos, hasta

pasar por los nodos o transformadores qué serán elementos pasivos en el modelo

[2].

Junto con el desarrollo del paradigma de flujo de datos, también lo hizo la

arquitectura basada en dataflow para hardware, frente a esto, los investigadores

encontraron problemas en la compilación de lenguajes de programación

imperativo convencionales para ejecutarse en hardware de flujo de datos, en

particular los relacionados con los efectos secundarios y localidad, la manera de

resolver esto fue hacer uso de modelos híbridos entre dataflow y “Von Neumann”

de manera qué se pudiera agrupar instrucciones y ejecutadas de manera

secuencial, esto último basado siempre en el principio del modelo de ejecución de

dataflow [3].

4

En la década de los 90s se vio un crecimiento en el campo de lenguajes de

programación visual de flujo de datos. Algunos de estos, tales como LabVIEW y

HP VEE se debió principalmente a la industria, y se han convertido en un producto

comercial exitoso que sigue siendo utilizado en la actualidad. Fueron creados

para la investigación. Todos tienen en la ingeniería de software como su principal

motivación, mientras que programación de flujo de datos fue tradicionalmente se

ocupa de la explotación del paralelismo.

2. CARACTERÍSTICAS DEL PARADIGMA DE DATAFLOW

En el modelo de ejecución del flujo de datos, un programa es representado por un

gráfico directo. los nodos del gráfico son instrucciones primitivas tales como las

operaciones aritméticas o de comparación. Los arcos dirigidos entre los nodos

representan las dependencias de datos entre las instrucciones. De forma

conceptual, los flujos de datos actúan como señales a lo largo de los arcos que se

comportan como canales ilimitados de datos, primero en entrar, primero en salir

(first-in, first-out-FIFO) esto en las colas de entrada. Los arcos que fluyen hacia el

ánodo se dice que son los arcos de entrada a ese nodo, mientras que los que

provienen de distancia se dice que son los arcos de salida de ese nodo.

Cuando comience el programa, la activación especial de nodos da lugar a los

datos en ciertos arcos de entrada clave, lo que provocó que el resto del programa

.Siempre qué un conjunto específico de los arcos de entrada de un nodo llamado

firingset tiene datos en él, el nodo se dice que es fireable. Un nodo fireable se

ejecuta en un tiempo indefinido después de que se activado. El resultado es que

elimina un dato contador de cada nodo en el conjunto de disparo, realiza su

operación, y coloca una nueva muestra de datos sobre todos o algunos de sus

arcos de salida. Ella a continuación, deja de ejecución y espera para convertirse

fireable de nuevo. Por este método, las instrucciones están programadas para su

ejecución tan pronto como sus operadores estén disponibles. Este se encuentra

en contraste con el modelo de ejecución “von Neumann”, en el que una instrucción

es sólo se ejecuta cuando el contador de programa la alcanza,

independientemente de que se pueda ejecutar antes.

La ventaja clave es que, en el dataflow, más de una instrucción puede ser

ejecutada a la vez. Por lo tanto, si se convierten en fireable varias instrucciones al

mismo tiempo, pueden ser ejecutadas en paralelo. Este sencillo principio ofrece la

posibilidad de masiva paralela la ejecución en el nivel de instrucción.

5

3. DATAFLOW

Un ejemplo de flujo de datos en comparación con un programa secuencial

tradicional se muestra en la Figura 1(a) se coloca un fragmento de código de

programa secuencial y la Figura 1 (b) muestra cómo esto se representa como un

grafica de flujo de datos .las flechas representan arcos y los círculos representan

los nodos de instrucciones. El cuadrado representa un valor constante, con código

de duro en el programa. Las letras representan donde los flujos de datos entran o

salen del resto del programa. Cuando más de una flecha emana de una misma

entrada dada, significa que el valor único se duplica y transmitida por cada ruta o

arco.

X Y 10

+ /

*

C

(a) (b)

Fig.1. Un simple programa secuencial (a) y su equivalente en dataflow (b)

Bajo el modelo de ejecución “von Neumann”, el programa en la Figura 1 (a) sería

ejecutar secuencialmente en tres unidades de tiempo(ciclos de procesador). En 1,

se añaden y se asignan a la unidad de A. En tiempo 2 Y se divide por 10 y se

asigna a B. En unidad de tiempo 3, A y B se multiplican entre sí y se asignan a C.

Bajo el modelo de ejecución de flujo de datos, donde el gráfico de la figura 1 (b) es

el código de la máquina, la adición y la división son tanto inmediatamente fireable

(activados), ya que todos sus datos están presentes inicialmente. En unidad de

tiempo 1, X e Y se añaden en paralelo con Y se divide por 10. Los resultados se

colocan en los arcos de salida, que representa las variables A y B.

A:= X+Y B:= Y/10 C:= A*B

6

En la unidad de tiempo 2, el nodo de la multiplicación se convierte en fireable y se

ejecuta, la colocación de la resultado en el arco que representa la variable C. (En

el flujo de datos, cada arco puede decirse que representa una variable.) en este

escenario, la ejecución toma sólo dos unidades de tiempo bajo un modelo de

ejecución en paralelo.

Está claro que el flujo de datos proporciona el potencial de proporcionar una

mejora en la velocidad sustancial, mediante la utilización de las dependencias de

datos para localizar el paralelismo. Además, si el cálculo debe ser realizado sobre

más de un conjunto de datos, los cálculos en la segunda ola de valores de X y Y

puede comenzar antes de los de la primer conjunto se ha completado. Es

conocido como flujo de datos encauzados ( pipelined data flow) [1] y puede utilizar

un grado sustancial de paralelismo, en particular en bucles, aunque existen

técnicas para utilizar mayor paralelismo en bucles. Un gráfico de flujo de datos que

produce un único conjunto de fichas de salida para cada conjunto único de fichas

de entrada se dice que es de buen comportamiento.

Otro punto clave es que la operación de cada nodo es funcional. Esto se debe a

que los datos nunca se modifica (nuevas fichas de datos se crea cuando un nodo

es fireable, ningún nodo tiene efectos secundarios, y la ausencia de un almacén

de datos global significa que existe localidad de efecto. Como resultado de ser

funcional, y el hecho de que los datos viajan en las colas ordenadas, un programa

expresado en el modelo de flujo de datos pura es determinista. Esto significa que,

para un determinado conjunto de entradas, un programa producirá siempre el

mismo conjunto de salidas.

Esto puede ser una propiedad importante en ciertas aplicaciones. Algunos han

realizado investigaciones sobre las consecuencias de un comportamiento no

determinada, pero ese tema no se abarcara en este trabajo de investigación.

En la Figura 1 (b) los dos arcos que emanan de la entrada Y significan que ese

valor está listo para ser duplicado. Bifurcar arcos de esta manera es esencial si un

contador de datos es necesario por dos nodos diferentes. Una ficha de datos que

llega a un arco en forma de horquilla se duplica y una copia enviada por cada

rama. Esto preserva la independencia de los datos y la funcionalidad del sistema.

Para preservar la determinación del modelo de red en el flujo, no está permitido

fusionar arbitrariamente dos arcos durante el flujo de fichas de datos. Si esto se

permite, los datos podrían llegar a un nodo fuera de orden y poner en peligro el

cálculo. Es obvio, sin embargo, que sería difícil el hecho de expresar un programa

7

en el modelo de flujo de datos si arcos sólo podían ser divididas y nunca se

fusionaron.

Así, el modelo de flujo de datos proporciona nodos de control especiales llamadas

puertas que permiten pasar dentro de unos límites bien controlados.

T F

(a) Mezcla Control (b) Switch Control

T F

Fig.2. Puertas en el gráfico de dataflow

La Figura 2 (a) muestra una puerta de mezcla. Estas puertas llevan dos arcos de

entrada de datos, con la etiqueta de verdadero y falso, así como un arco de

entrada "control" que lleva un valor booleano. Cuando se dispara el nodo, el

testigo de control se absorbe primero. Si el valor es verdadero, el token en la

entrada verdadera se absorbe y se coloca en la salida. Si es falso, entonces el

token en la entrada falsa se absorbe y se coloca en la salida. La Figura 2 (b)

muestra una puerta Switch. Esta puerta opera de la misma manera, excepto que

hay una sola entrada y la señal de control determina en cuál de las dos salidas se

coloca.

4. ESTRUCTURA DE UN PROGRAMA EN DATAFLOW

En el paradigma dataflow de forma teórica, existen dos formas de implementar un

programa.

1. Modelo dirigido por los datos (Data-Driven model)

Este término es un poco engañoso ya que ambos enfoques se puede decir que

sea impulsado por los datos, en la medida en que siguen los principios de flujo de

datos. Este enfoque debería ser realmente denominado el enfoque basado en

datos de disponibilidad (data-availability-driven) [1] impulsado porque la ejecución

depende de la disponibilidad de datos. Esencialmente un nodo está inactivo

mientras los datos no lleguen a sus entradas. Es responsabilidad de un dispositivo

de gestión global para que notifique y active nodos cuando sus datos han llegado.

El enfoque basado en datos es un proceso de dos fases donde:

1. Un nodo se activa cuando sus entradas están disponibles

2. Recibe sus entradas y coloca las fichas (Tokens) en sus arcos de salida.

8

2. Modelo dirigido por la demanda (Demand-Driven model)

En este enfoque, un nodo se activa sólo cuando se recibe una solicitud de datos

de sus arcos de salida. En este punto, exige datos de todos los arcos de entrada

correspondientes. Una vez que haya recibido sus datos, ejecuta y coloca las fichas

de datos sobre sus arcos de salida.

El enfoque basado en la demanda es por tanto un proceso de cuatro fases [4] en

la que:

1. Las solicitudes de entorno de datos de un nodo.

2. El nodo se activa y solicita los datos de su entorno.

3 El medio ambiente responde con datos.

4. El nodo coloca fichas en sus arcos de salida.

La ejecución del programa se inicia cuando el entorno del gráfico exige alguna

salida.

Cada uno de estos enfoques de implementación tiene ciertas ventajas. El enfoque

basado en datos (Data-Driven model) tiene la ventaja de que no tiene la

sobrecarga adicional de propagar las peticiones de datos el gráfico de flujo de

datos. Por otra parte, el enfoque basado en la demanda (Demand-Driven model)

tiene la ventaja de que ciertos tipos de nodos pueden ser eliminados, Esto es

porque sólo los datos necesarios serán exigidos.

Por ejemplo, el nodo de conmutación (switch), que se muestra en la Figura 2 (b),

no se requiere bajo un enfoque basado en la demanda, ya que sólo una de las

salidas Verdadero o Falso exigirá la entrada, pero no ambos.

Por lo tanto, ambos pueden estar unidos directamente a la entrada. Este es un

ejemplo de cómo la programación con el flujo de datos puede ser afectada por la

elección de la implementación física, o al menos por la elección del modelo de

ejecución.

También se puede argumentar que el enfoque basado en la demanda (Demand-

Driven model) impide la creación de ciertos tipos de programas. Por ejemplo, en

el software moderno es a menudo basado en eventos, como por ejemplo los

desarrollos en tiempo real. En estos no es suficiente para el entorno simplemente

exigir de entrada. Este ejemplo parece requerir un enfoque impulsado por los

datos (Data-Driven model).

9

5. LENGUAJES DATAFLOW

Desde la creación del paradigma dataflow han sido diversos el número de

lenguajes propuestos para desarrollar este enfoqué de programación, algunos de

ellos se describen a continuación:

TDFL. (The Textual Data-Flow Language) fue desarrollado por Weng en 1975,

como fue uno de los primeros lenguajes de flujo de datos. Fue diseñado para ser

compilados en un gráfico de flujo de datos con flujos de datos de una manera

relativamente sencilla y con el apoyo de detección de estancamientos de tiempo

durante la compilación.

Un programa expresado en TDFL consistió en una serie de módulos, de forma

análoga a los procedimientos en otros Lenguajes de programación. Cada módulo

se compone de una serie de declaraciones que eran o asignaciones que

obedecen la regla de asignación individual (single-assignment rule), sentencias

condicionales, o una llamada a otro módulo. La iteración no se proporcionaba

directamente, pero los módulos podía llamarse a sí mismos de forma recursiva.

LAU. Desarrollado en 1976 por el Grupo de Estructuras de ordenador de ONERA-

CERT en Francia.

Era una lengua de asignación única e incluyó bifurcación condicional y bucle que

eran compatibles con esta regla mediante el uso de la palabra clave de edad (the

old keyword). Era uno de los pocos lenguajes de flujo de datos que proporcionaron

paralelismo explícito a través de la palabra clave que especifica ampliar

asignación paralela. LAU tenía algunas características que eran similares a los

lenguajes orientados a objetos, tales como la capacidad de encapsular los datos y

operaciones.

Lucid. Originalmente desarrollado de forma independientemente del campo de

flujo de datos por Ashcroft y Wadge en 1977, Lucid era un lenguaje funcional

diseñado para permitir pruebas formales. La recursividad se consideraba

demasiado restrictivo para construcciones de bucle, pero se dio cuenta de que la

iteración introdujo dos características no matemáticas en la programación: la

transferencia y asignación.

10

Por lo tanto, Lucid fue diseñado para permitir la iteración de una manera que era

matemáticamente respetable, a través de la asignación individual y el uso de la

palabra clave definir el valor de la variable en la siguiente iteración. Pronto se hizo

evidente, sin embargo, que la semántica de asignación funcionales e individuales

de Lucid fueron similares a las requeridas para las máquinas de flujo de datos, y

Ashcroft y Wadge en 1985 publico un libro en el que estableció firmemente la

afirmación de Lucid de ser un lenguaje de flujo de datos.

Desde la perspectiva de la ingeniería de software, la principal novedad en flujo de

datos en los últimos 25 años ha sido el crecimiento de programación visual de flujo

de datos (dataflow visual programming languages). Aunque la teoría detrás

DFVPLs ha estado en existencia durante muchos años, es sólo la disponibilidad

hardware gráfica de bajo costo en los años 90’s que ha hecho que sea una

práctica y fructífera área de investigación.

Las investigaciones de DFVPLs han indicado muchas soluciones a los problemas

existentes en ingeniería de software, un punto que se ampliará a continuación.

También tiene conducido a la introducción de nuevos problemas y desafíos,

particularmente aquellos asociados con los lenguajes de programación visuales en

general, así como la persistencia de los problemas, como la representación de

estructuras de datos y estructuras de control de flujo.

La investigación ha sido bastante intensa en la última década, y es el tema de

esta sección para identificar algunas de las principales tendencias en la

programación de flujo de datos durante este período.

11

6. LABVIEW

LabVIEW es un DFVPL de conocido desarrollado a mediados de la década de

80’s, nace con el objetivo de permitir la construcción de instrumentos "virtuales"

para el análisis de datos en los laboratorios. Como tal, fue diseñado para ser

utilizado por personas que no eran ellos mismos los programadores profesionales.

Un programa en LabVIEW se construye mediante la conexión de funciones

(nodos) predefinidos visualizados como cajas con iconos, además usando arcos

de rutas de datos. Cada programa también tiene una interfaz visual para permitir

el diseño del instrumento virtual. Los componentes que tienen una representación

visual aparecen tanto en la interfaz y el programa, mientras que las funciones sólo

aparecen en la ventana del programa.

Todo el programa se ejecuta según las reglas de flujo de datos.

LabVIEW hace que la experiencia de programación menos engorrosa

proporcionando construcciones iterativas y una forma de refinamiento paso a paso

mediante el cual los programadores pueden producir sus propios nodos de

función.

12

LabVIEW, cuenta con dos tipos de bucle, un bucle for y un bucle while.

Un bucle for es un nodo especial que encierra todos los nodos a ser ejecutado de

forma iterativa. A diferencia de Show-and Tell, tiene un puerto de entrada adicional

que especifica el número de veces que el ciclo se va a ejecutar. Todos los demás

valores que se emiten puertos conceptualmente vuelven a entrar en los puertos de

entrada idénticos. Otro puerto visible sólo dentro del bucle especifica el valor

actual de la variable de bucle.

El bucle while opera de una manera similar, excepto que no tiene la variable de

bucle. En cambio, tiene un puerto único visible dentro del bucle que termina

después de la iteración actual una vez que se recibe un valor de "falsa". Una

construcción única de LabVIEW permite a los horarios del bucle que se

especifiquen, por ejemplo, bucle cada 250 ms. Esto es debido a su aplicación de

lectura de instrumentos científicos.

13

Además de esto es necesario qué en las estructuras de bucle los objetos queden

dentro de la área circundante por la función, esto con la finalidad de se repitan en

dentro un cuadro la estructura o función. Los Pines de entrada y salida en el

cuadro se pueden configurar para indexar los datos entrantes o salida. Los

Registros de desplazamiento también se pueden añadir al bucle para pasar

información de una iteración a la siguiente.

Para el desarrollo de los programas se utilizan objetos gráficos, los cuales se

utilizan para cuatro funciones básicas:

1. Crear flujos de datos

2. Analizar flujos de datos

3. Tratar flujos de datos

4. Mostrar los resultados del flujo de datos

Los objetos en LabVIEW son llamados VI’s (Virtual Instrument)

Un PIN es un punto de un objeto que indica que una conexión puede hacerse en

esa ubicación.

Las líneas o arcos representan los datos y/ o pueden ser entradas al objeto o

salidas del objeto, también pueden ser utilizados para secuenciar la ejecución del

objeto.

Tipo de línea Escalar Arreglo 1D Arreglo 2D Color Numérico Naranja (Punto flotante)

Numérico Azul (Entero)

Booleano Verde

Cadena Rosa

El color y el estilo de las líneas indican el tipo de datos representados por las

líneas [6].

14

Estos objetos se seleccionan de dos distintos paneles de instrumentos, uno para

la vista del panel frontal y otro para la vista de diagrama de bloques, con sólo

hacer clic sobre estos y se arrastran hacia donde se decida colocar.

En la barra de menús tenemos las siguientes opciones:

File: Las opciones de este menú son para realizar las operaciones estándar con

archivos como Abrir, Guardar, Imprimir, Salir...

Edit: Operaciones de edición en el VI, como Cortar, Copiar, Pegar, Búsqueda...

15

Operate: Control de la ejecución del archivo activo, como Ejecutar, Parar,Cambiar

a Modo de Ejecución...

Tools: Varias utilidades como Guía de Soluciones DAQ, Historial del VI...

Browse: Menú para ver diversos aspectos del VI actual, como archivos que llaman

al VI, los subVIs que utiliza este VI, Puntos de Ruptura...

Window: Acceso y personalización de diferentes vistas del VI, como Ver

Diagrama, Ver Lista de Errores, y opciones para las paletas y ventanas

Help: Acceso a varios tipos de ayuda como Ayuda LV, ejemplos de VIs y enlaces a

los recursos de ayuda de National Intruments en internet.

Para crear una prueba en LabVIEW, la herramienta de la prueba debe ser utilizada

para seleccionar una línea. Una nueva ventana aparecerá para mostrar los datos

que fluyen en la línea seleccionada. La etiqueta de la nueva ventana coincide con

16

una etiqueta pegada a la línea seleccionada. Los datos sólo aparecen en la nueva

ventana si el programa está en ejecución

6.1 DESARROLLO DE UN EJEMPLO EN LABVIEW

La mejor manera de comparar estos dos lenguajes de programación es examinar

un programa idéntico escrito en ambos entornos de programación.

Partimos de una función inicial:

Encontramos el equivalente en diagrama de flujo.

X Y 10

+ /

*

C

Generamos el equivalente usando el Lenguaje G en LabVIEW

A:= X+Y B:= Y/10 C:= A*B

17

7. AGILENT VEE

Al igual que LabVIEW se utilizan objetos gráficos, los cuales se utilizan para cuatro

funciones básicas:

1. Crear flujos de datos

2. Analizar flujos de datos

3. Tratar flujos de datos

4. Mostrar los resultados del flujo de datos

Los objetos en Agilent VEE son llamados funciones de usuario (User function)

Un PIN es un punto de una función que indica que una conexión puede hacerse

en esa ubicación.

Las líneas o arcos representan los datos y/ o pueden ser entradas a la función

del usuario o salida, también pueden ser utilizados para secuenciar la ejecución de

la función.

Los Bucles VEE se definen mediante objetos y pasadores de secuencia. Un

objeto de coleccionista se utiliza para recoger datos salientes en una matriz.

Estos objetos se seleccionan del panel de instrumentos con sólo hacer clic sobre

estos y se arrastran al área de trabajo

18

El color y el estilo de las líneas indican el tipo de datos representados por las

líneas.

Tipo de línea Dato Color Entero o Real Azul obscuro

Complejo Azul obscuro

Cadena Naranja

Secuencia de salida

Gris

Tipo de dato desconocido

Negro

Error Rojo

destacado Magenta

Bucles en VEE se expresan más de cerca al modelo de flujo de datos puros, es

decir, a través de ciclos en el gráfico. Sin embargo, el modelo ha sido aumentado

con un número de nodos adicionales a fin de simplificar la aparición de los ciclos.

En un bucle for, genera una serie de índices de un rango que están en la cola. El

programador no tiene que preocuparse por incrementar y retroalimentar la variable

de bucle, ser libre en lugar de concentrarse en los valores que se calculan. Un

bucle while se puede configurar mediante el uso de tres nodos relacionados.

19

El nodo until break activa repetidamente el gráfico que está conectado a, hasta

que el gráfico se activa un nodo break relacionado que detiene la repetición. En

lugar de datos que llegan en el nodo next, este desencadena la próxima iteración.

Para crear una prueba en Agilent VEE, la herramienta de la prueba debe ser

utilizada para seleccionar una línea. Una nueva ventana aparecerá para mostrar

los datos que fluyen en la línea seleccionada. La etiqueta de la nueva ventana

coincide con una etiqueta pegada a la línea seleccionada. Los datos sólo

aparecen en la nueva ventana si el programa está en ejecución, la diferencia

respecto a LabVIEW es qué no es necesario ejecutar el programa para hacer la

prueba

20

7.1 DESARROLLO DE UN EJEMPLO EN AGILENT VEE

La mejor manera de comparar estos dos lenguajes de programación es examinar

un programa idéntico escrito en ambos entornos de programación.

Partimos de una función inicial:

Encontramos el equivalente en diagrama de flujo.

X Y 10

+ /

*

C

Generamos el equivalente en Agilent VEE.

(a) muestra la función con bloques cerrados

A:= X+Y B:= Y/10 C:= A*B

21

(b) muestra la función con bloques abiertos

8. RESULTADOS

LabVIEW:Para llegar a cabo el programa fue necesario realizar cuatro iteraciones.

El programa soporta errores de tipo lógico (valor/0).

22

Agilent VEE:Para llegar a cabo el programa fue necesario realizar 6 iteraciones.

El programa no soporta errores de tipo lógico (valor/0) y aborta.

8.1 VENTAJAS DE LABVIEW

● Los objetos al ser bastante gráficos, sugieren al usuario su utilización durante el

desarrollo del programa, por lo que también ayuda a entender a personas ajenas

al proyecto, ya que con solo mirar las formas, colores y etiquetas sabrá cual es la

finalidad de cada parte del programa.

● Los tipos de datos de LabVIEW y las formas son muy similares a los tipos de

datos lenguaje de programación tradicionales

● El programa soporta errores de tipo lógico (valor/0).

23

8.2 VENTAJAS DE VEE

● Las funciones de usuario pueden cambiar las proporciones de tamaño gráfico

● Las funciones de usuario tienen dos vistas (cerrado y abierto)

● Las funciones tienen pasadores de secuencia: Un pasador en la parte superior

del objeto y uno en la parte inferior. Estas patillas se utilizan para el flujo de

ejecución de la secuencia y típicamente se usan sólo si el flujo de ejecución del

programa no puede seguir el flujo de datos o si hay flujo disponible para la

secuenciación hay datos.

● Los cables de unión entre las funciones convierten al tipo de dato qué es

necesario, evitando qué el programador se preocupe por esta tarea.

● Para realizar alguna extracción de datos de un arreglo sólo es necesario

especificar el tipo de dato qué se requiere.

● Las funciones de usuario se pueden colocar en el diagrama y cablear con datos,

pero pueden ser llamados desde un objeto fórmula o secuenciador.

24

8.3 INCONVENIENTES DE LABVIEW

● El detalle con los objetos es qué para cambiar el tamaño es necesario agregar

más entradas o salidas al mismo con el consecuente cambio en el flujo del

programa.

● Los objetos de LabVIEW no disponen de pines de secuencia. Los objetos se

secuenciaran por el flujo de datos y sí esto no es posible, entonces se utilizará un

sistema de ventana se requiere de múltiples capas.

● A pesar que los cables de unión entre nodos usan color para comunicar el tipo

de dato que llevan, este no convierte el a este tipo de dato, sólo es para fin

informativo.

● Programadores de LabVIEW necesitan utilizar objetos específicos para el tipo

de datos con los que trabajan y el tipo de extracción que quieren llevar a cabo. La

matriz o clúster junto con las constantes se debe conectar al objeto de extracción

para extraer los datos deseados

● Para llamar a un VI de LabVIEW que tiene que ser colocado en el diagrama de

cableado y con los datos

8.4 INCONVENIENTES DE VEE

25

● las funciones de usuario dentro del entorno son bastante parecidas unas a otras,

por lo que si otra persona ajena al proyecto desea entender el código ,le resultara

bastante más complejo, ya que tendrá qué leer las etiquetas de cada función para

saber cuál es su función dentro del programa.

● En Agilent VEE los tipos de datos y las formas son más específicos para el

campo de prueba y medición. Si los tipos de datos únicos en Agilent VEE son

útiles depende de qué tipo de manipulación de datos el programa requiere,

haciendo más complicado de aprender y recordar para el programador.

● Estructuras de bucle en Agilent VEE son más difíciles de identificar que la

estructura del bucle en LabVIEW.

26

9. OPORTUNIDADES DE INVESTIGACIÓN

Es ampliamente aceptado que hay muchas aplicaciones que en realidad requieren

estados de no determinación. Se trata de sistemas que están operando

fundamentalmente en entornos no deterministas, como los sistemas de reserva y

sistemas de acceso a la base de datos.

Esto fue reconocido tempranamente en el desarrollo de flujo de datos. De manera

que se probó que el modelo era muy limitado, ya que podría producir programas

sólo deterministas.

La fusión no determinística parece ser capaz de resolver muchos de los problemas

asociados con la falta de la no determinación.

Semánticamente, es un nodo que tiene dos arcos de entrada y un arco de salida y

fusiones las dos corrientes en una forma completamente arbitraria. En la mayoría

de los casos, como una reserva sistema, esto es todo el no determinismo que se

requiere.

La ventaja de esto es que el no determinismo puede identificarse fácilmente.

Incluso es posible tener sub-programas no deterministas dentro de un gráfico que

en otro caso sería siempre determinado. Por lo tanto, puede ser posible aplicar los

principios matemáticos para el gráfico incluso si no tiene secciones no

deterministas.

La dicotomía en cuanto a no determinismo parece ser el resultado de una división

entre aquellos que desean utilizar el flujo de datos como un medio para facilitar la

prueba formal y el análisis de los programas y los que desean utilizar el flujo de

datos para todas las variedades de problemas de programación. Mientras que este

último requiere funciones no determinísticas como algo esencial. Además de tener

el inconveniente qué para realizar pruebas formales, las funciones no

determinísticos, hacen más engorroso el proceso de ingeniería de software al

hacer una depuración más difícil. Por lo tanto, la cuestión es cómo controlar con el

uso de sistemas híbridos en los programas de flujo de datos, sin perder nunca de

vista la prestación inicial de permitir al ingeniero de software escribir programas

utilizables de manera sencilla y rápida.

Otro de los puntos bastante importante es el desarrollo de representaciones para

estructuras de control en flujos de datos, así como su visualización de la

ejecución.

27

10. CONCLUSIONES

Los entornos basados en DFVPLs como LabVIEW y Agilent VEE permiten al

desarrollador proceder con el diseño e implementación de su propio orden, con lo

que el diseño es más libre y fácil en comparación con un lenguaje no gráfico.

En cuanto a la elección del programador de cuál es el mejor lenguaje o entorno de

comparación, de una de las cuestiones más complicadas de responder.

Lo qué se puede concretar es conocer ambas opciones y dependiendo de ese

conocimiento y del problema que se enfrente es lo que hará realizar la elección de

la forma más correcta, aunque se puede concluir que LabVIEW es el que cumple

de manera rigurosa el uso del paradigma de dataflow, mientras que Agilent VEE

utiliza un modelo hibrido de dataflow basado en diagramas de flujo y tablas de

decisión.

Para la gran mayoría de aplicaciones comerciales en la industria y en el ámbito de

investigación qué involucre adquisición de señales, comunicación análoga y

digital, el uso de este tipo de software para desarrollo de prototipos rápidos es

altamente recomendado, además qué ambos soportan Multithreading y Multi-core

para aumentar el rendimiento de la prueba, esto significa que el compilador

incorporado trabaja continuamente en segundo plano para identificar las secciones

paralelas de código. Siempre que el código G tiene alguna secuencia paralela de

nodos en el diagrama, el compilador intenta ejecutar el código en paralelo dentro

de un conjunto de hilos que LabVIEW maneja automáticamente.

En términos informáticos, esto se llama "paralelismo implícito" porque no es

necesario que el programador escriba código específicamente con el propósito de

ejecutarlo en paralelo; el lenguaje G se encarga de paralelismo por su cuenta.

En el caso de Multithreading en un sistema Multi-core, G puede proporcionar aún

mayor ejecución en paralelo mediante la ampliación de la programación gráfica

implementada para dispositivos FPGAs, estos son chips de silicio reprogramables

que trabajan de forma masiva en paralelo, con cada tarea de procesamiento

independiente asignado a una sección específica del chip sin estar limitados por el

número de núcleos de procesamiento disponibles. Como resultado, el rendimiento

de una parte de la aplicación no se ve afectada negativamente cuando se añade

más procesamiento.

28

Históricamente, la programación FPGA fue diseñada para un experto

especializado con un profundo conocimiento de hardware digital de lenguajes de

diseño.

Cada vez más, los ingenieros sin experiencia FPGA quieren utilizar hardware

personalizado basado en FPGA para la sincronización única y rutinas de

activación, el control de ultra alta velocidad, interfaz con protocolos digitales,

procesamiento de señal digital (DSP), RF y las comunicaciones, y muchas otras

aplicaciones que requieren alta velocidad confiabilidad del hardware, la

personalización, y el determinismo apretado. G es especialmente adecuado para

la programación FPGA, ya que representa claramente el paralelismo y el flujo de

datos y está creciendo rápidamente en popularidad como una herramienta de

elección para los desarrolladores que buscan el procesamiento paralelo y

ejecución determinista.

Ambos entornos permiten combinar el lenguaje G con otros basados en texto.

La Formula Node en LabVIEW es un cómodo nodo, basado en texto que se puede

utilizar para realizar operaciones matemáticas complicadas en un diagrama de

bloques utilizando la sintaxis de C ++.

29

Otro punto a tomar en consideración es la condición actual del mercado.

En la gráfica comparativa vemos el interés relativo a través del tiempo qué tiene

un término de búsqueda respecto a otro.

El último dato de Diciembre 2014 qué se obtuvo, muestra una relación de 61 a 3

respecto al volumen de búsquedas global usando Google como buscador.

Este grafico representa el volumen de búsqueda relativa con la ubicación de la

misma, esto es de suma importancia para elegir la tecnología adecuada para el

proyecto o empresa, ya que así no cometeremos el error de usar una tecnología

que tiene a desaparecer.

30

En el caso de Agilent VEE, de manera relativa sólo dos países muestran el interés

por el producto, esto puede causar una alerta a la hora de elegir un producto.

11. FUENTES Y BIBLIOGRAFIA

[1] Johnston, Wesley M.; Hanna, J. R. Paul.; Millar, Richard J.:” Advances in

dataflow programming languages”. ACM Computing Surveys, 2004.

[2] Alonso, F.; Lara, J. A.; Lizcano, D.; Martínez, L.: "Paradigmas de

Programación". Administración Digital, 2013.

[3] Klaus Erik Schauser, David E. Culler, Thorsten von Eicken.:” Compiler-Controlled

Multithreading for Lenient Parallel Languages”. Computer Science Division- Electrical

Engineering and Computer Science- University of California, Berkeley.1991.

[4] Alan L. Davis, Robert M. Keller.;” Data Flow Program Graphs”. IEEE Computer Society

Computer (Volume: 15 , Issue: 2 );1982

[5] Bruce Elliott.: “Cuiting your test development time with HP VEE, an iconic programming

language” .Hewlett-Packard Professional Books.1994

[6] Agilent Technologies.:” VEE Advanced Techniques”. Manual.2004