LENGUAJES DE PROGRAMACION VISUAL: UNA SOLUCIÓN …
68
1 LENGUAJES DE PROGRAMACION VISUAL: UNA SOLUCIÓN PARA LAS DIFICULTADES DE LA PROGRAMACIÓN INFORMÁTICA COMUN Oscar Fernando García Alvarado Asesor Silvia Takahashi, PH.D. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, 2008
Transcript of LENGUAJES DE PROGRAMACION VISUAL: UNA SOLUCIÓN …
1
LENGUAJES DE PROGRAMACION VISUAL: UNA SOLUCIÓN PARA LAS DIFICULTADES DE LA
PROGRAMACIÓN INFORMÁTICA COMUN
Oscar Fernando García Alvarado
Asesor Silvia Takahashi, PH.D.
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ,
2008
i
Tabla de contenido
1. Introducción .........................................................................................................................1
2. El lenguaje gráfico ...............................................................................................................4
2.1. Sintaxis gráfica .............................................................................................................5
2.1.1. El espacio gráfico .................................................................................................8
2.1.2. Los objetos gráficos ..............................................................................................9
2.1.3. Los atributos visuales ...........................................................................................9
2.2. Las estructuras sintácticas .......................................................................................... 10
2.3. Relaciones Objeto-Objeto........................................................................................... 11
2.3.1. Separación mediante un separador ...................................................................... 12
2.3.2. Alineación .......................................................................................................... 12
2.3.3. Enlace mediante un conector .............................................................................. 13
2.3.4. Contención mediante un contenedor ................................................................... 14
3. La programación visual y sus avances en el tiempo ........................................................... 15
3.1. Lenguajes más importantes en la programación visual ............................................... 15
3.1.1. DDN ................................................................................................................... 15
3.1.2. GPL .................................................................................................................... 16
3.1.3. FGL .................................................................................................................... 16
3.1.4. Grunch ................................................................................................................ 16
3.1.5. ARK ................................................................................................................... 17
3.1.6. LabView ............................................................................................................. 18
3.1.7. Prograph ............................................................................................................. 25
3.1.8. Drakon ................................................................................................................ 29
3.2. Análisis realizado a los lenguajes de programación visuales ...................................... 40
4. PFC como propuesta de solución ....................................................................................... 43
4.1. Los componentes ........................................................................................................ 44
4.1.1. Componentes modulares ..................................................................................... 44
4.1.2. Componentes de métodos ................................................................................... 45
4.1.3. Componentes de importación ............................................................................. 46
4.2. Drakon y los componentes ......................................................................................... 47
5. Descripción del prototipo de PFC....................................................................................... 48
5.1. Edición de flujos ......................................................................................................... 50
5.2. Creación de componentes de métodos ........................................................................ 57
5.3. Creación de componentes de importación .................................................................. 59
5.4. Agregar variables complejas....................................................................................... 60
ii
5.5. Conversión a Java2SE ................................................................................................ 60
6. Análisis de PFC .................................................................................................................. 61
7. Conclusiones ...................................................................................................................... 63
8. Referencias Bibliográficas.................................................................................................. 65
1
1. Introducción
Los avances en la computación crecen a ritmos acelerados. De la misma manera, los
proyectos informáticos cada vez resultan ser más grandes y complejos. Los
programadores cada vez utilizan más tiempo en el entendimiento del código,
aumentando los costos de desarrollo y mantenimiento, presentándose mayores
dificultades en la comunicación del cliente con el desarrollador. Este problema afecta en
un alto grado a profesionales no relacionados con la programación, los cuales usan la
informática como una herramienta en el desempeño de sus respectivas disciplinas; la
poca experiencia y el tiempo de aprendizaje de un lenguaje de programación, el cual
puede ser de varios meses, incluso años, son los principales problemas que tienen este
tipo de profesionales, lo cual hace que se presenten dificultades en el entendimiento del
código y en el proceso de aprendizaje de un lenguaje de programación.
Los proponentes de la programación visual la ven como una posible solución a todos
estos inconvenientes, basados en que la mayoría de las personas piensan y recuerdan
cosas en términos de imágenes. La programación visual permite expresar ideas usando
representaciones gráficas, teniendo un amplio éxito en temas específicos como la
robótica, el procesamiento de imágenes y la producción de audio. Sin embargo la
programación visual no ha sido contundente en la creación de aplicaciones de propósito
general.
David y Keller en 1982 [12], reconocían lo difícil de implementar lenguajes visuales por
los pocos avances en computación gráfica que existían en la época, ahora se cuenta con
avanzadas técnicas en hardware y software en la producción de gráficos. Esta es la
principal motivación de este proyecto, investigar los avances y dificultades que han
tenido los lenguajes visuales de propósito específico con el fin de entender sus
debilidades y proponer soluciones específicas.
2
Este proyecto tiene como objetivos:
Establecer la situación actual de los lenguajes de programación visual, mediante
la investigación de los lenguajes más relevantes.
Identificar los impedimentos que presenta el uso de lenguajes de programación
visual.
Proponer una solución para mejorar algunos aspectos de la programación
visual.1
Buscar nuevas alternativas para solucionar problemas de los lenguajes visuales,
usando la experiencia de la propuesta.
Dar a conocer al lector los beneficios que trae la programación visual, con el fin
de incentivar la contribución en esta área.
Este documento está compuesto de cuatro secciones principales: la primera, “EL
LENGUAJE VISUAL”, introduce al lector en los conceptos elementales de las
representaciones gráficas y como éstas conforman un lenguaje visual. A su vez este
capítulo busca que el lector tenga presente que vive rodeado de lenguajes visuales,
como señales de tránsito, graficas estadísticas, etc. y que estos contribuyen a un mayor
entendimiento de la información. La siguiente sección, “LA PROGRAMACIÓN
VISUAL Y SUS AVANCES EN EL TIEMPO”, hace énfasis en los lenguajes visuales
diseñados para la programación. Se realiza una revisión de los lenguajes de
programación visual más destacados a través de la historia, identificando sus fortalezas
y debilidades. Por otra parte, se hace un análisis de los beneficios que los lenguajes de
programación visual presentan sobre los lenguajes de programación textuales y qué
aspectos impiden que estos sean usados en la ingeniería de software. Se continua con la
sección “PFC COMO PROPUESTA DE SOLUCIÓN”, donde se describe el lenguaje
PFC, el cual pone a prueba el uso de la programación visual de flujos de datos,
buscando solucionar algunos de los problemas identificados en la sección anterior. La
efectividad de este lenguaje será analizado en la siguiente sección “ANÁLISIS DE
PFC”, donde se exponen las debilidades detectadas convirtiéndolas en lecciones de
aprendizaje para el diseño de los lenguajes visuales, así mismo se muestran los
1 Los objetivos de las propuesta pueden ser vistos de forma mas amplia en el capitulo “PFC como
propuesta de solución”
3
beneficios que se encontraron. Al final se dan las conclusiones, resaltando las lecciones
aprendidas y proponiendo trabajos futuros, a ser desarrollados para el mejoramiento de
la programación visual.
4
2. El lenguaje gráfico
Para el hombre las representaciones gráficas han jugado un papel importante a lo largo
de su existencia, desde simples trazos realizados en cuevas en épocas primitivas hasta
representaciones mucho más elaboradas en la era contemporánea, donde el acceso a la
información cobra gran importancia, y estas representaciones hacen parte de esta. Cada
vez más libros, periódicos y otros medios de comunicación recurren a representar la
información a través de diagramas, mapas y todo aquello que de forma gráfica sea capaz
de expresar ideas. Por lo cual, es necesario comprender los conceptos elementales de las
representaciones graficas, y como estos son capaces de conformar un lenguaje.
En este capítulo se muestran las estructuras básicas que permiten a una representación
gráfica cumplir el papel de expresar información.
Una representación gráfica es un instrumento sobre una superficie más o menos plana,
creado con el fin de expresar información. Por ejemplo una huella en la tierra que fue
hecha por un determinado animal, no puede considerarse como una representación
gráfica ya que no fue hecha con este propósito, pero un mapa trazado con un palo sobre
la misma tierra si puede ser considerada como una representación gráfica [1].
Una representación puede verse como una expresión de un lenguaje visual, y puede ser
analizada con respecto a su sintaxis gráfica y a su interpretación.
Los lenguajes visuales existen por todas partes: las señales de tránsito, un mapa del
mundo, un mapa de carreteras principales, gráficas de barras, de torta, etc. Cada uno de
ellos posee su propio conjunto de reglas de composición y su propio conjunto de
categorías de gráficas basadas en funciones sintácticas especificas. Las reglas de
composición y las funciones sintácticas son la base de la sintaxis gráfica.
5
2.1. Sintaxis gráfica
Así como el significado de una oración depende del significado de las palabras que
contiene y a su vez depende del orden en que se encuentren, del mismo modo, el
significado de una representación gráfica depende de los objetos gráficos que esta
contenga y de cómo están organizados. En el caso de los gráficos, no solo se depende de
un ordenamiento espacial para obtener un significado, los gráficos pueden contener
atributos como color, tamaño o brillo, los cuales pueden proporcionar un significado.
Minsky agrupa la relación espacial, así como las relaciones de atributos dentro del
concepto de relaciones gráficas: “Lo que una representación gráfica significa, depende
en parte de los objetos gráficos que este contenga y en parte de las relaciones gráficas
en los cuales estos objetos se encuentren involucrados”[2]
Con el fin de definir una sintaxis gráfica, se usará el principio de composición, también
conocido como el principio de Frege:
La semántica debe especificar la interpretación de un número infinito de
expresiones, de una forma finita. La obvia manera de proceder sería que la
definición de semántica sea paralela a la definición finita y recursiva de la
sintaxis. Este método asegura que a cada regla sintáctica la cual nos permita
construir un determinado tipo de expresión correspondiente a una o más reglas
semánticas sencillas, la cual establece como la interpretación de una nueva
expresión es obtenida de la interpretación de sus componentes. Es decir, la
interpretación de una expresión compleja es una función de la interpretación
de sus partes. [3]
En ciencias de la computación este principio existe de forma similar en la semántica
denotacional Christopher Strachey y Dana Scott.2
2 Dana Scott and Christopher Strachey. Toward a mathematical semantics for computer languages Oxford Programming Research Group Technical Monograph. PRG-6. 1971.
6
La definición de la sintaxis también parece apropiada para las representaciones gráficas,
con el fin de explicar el hecho de que una colección de objetos gráficos dispuestos en
una estructura espacial, a menudo puede ser considerado como un solo objeto gráfico.
Según lo expuesto anteriormente se puede afirmar:
1. Una representación gráfica es un objeto gráfico
2. Un objeto gráfico puede ser:
Un objeto gráfico simple.
Un objeto compuesto, que puede constar de:
o Un espacio gráfico que es ocupado por este.
o Un conjunto de objetos gráficos, los cuales están contenidos en ese
espacio gráfico.
o Un conjunto de relaciones gráficas en los cuales los objetos gráficos
contenidos están involucrados.
7
Ilustración 1: Composición de un objeto gráfico
Un objeto gráfico compuesto
Un espacio gráfico que es ocupado por este.
Un conjunto de objetos gráficos que están contenidos
en su espacio gráfico.
Un conjunto de relaciones gráficas en las que están
involucrados los objetos gráficos contenidos.
Estos pueden ser:
- Relaciones objeto- espacio
- Relaciones objeto - objeto
Relaciones objeto - espacio
Relaciones objeto - objeto
8
Ilustración 2: Composición recursiva de un objeto gráfico
A continuación se describen brevemente cada uno de estos elementos.
2.1.1. El espacio gráfico
El espacio gráfico es una construcción mental de lo que se encuentra dentro de este.
Cuando vemos un papel o incluso la pantalla del computador ilustrando una figura en 3
dimensiones, podemos diferenciar su profundidad. Sin embargo, cada uno de sus trazos
son planos. Por lo tanto el espacio gráfico no es el espacio que contiene un grupo de
pixeles o puntos de tinta, si no una construcción mental.
Un objeto gráfico compuesto
Espacio gráfico Objetos gráficos contenidos
Relaciones en la que los objetos contenidos están
involucrados
Objeto A Objeto B
Espacio gráfico
ocupado por A
Objetos gráficos
de A
Relaciones gráficas de los objetos
de A
Espacio gráfico
ocupado por B
Objetos gráficos
de B
Relaciones gráficas de los objetos
de B
9
2.1.2. Los objetos gráficos
Una representación gráfica se puede considerar un objeto gráfico, y a su vez este puede
ser simple o compuesto; este último presenta una noción en la cual un objeto gráfico
compuesto contiene dentro de su espacio objetos que a su vez pueden contener dentro
de sus correspondientes espacios otros objetos o ser objetos simples.
2.1.3. Los atributos visuales
“La naturaleza de los pigmentos provee las bases para las sensaciones de luz y color; las
cuales son brillo, matiz y saturación. La demarcación geométrica de estos aspectos
provee las bases físicas para la percepción de áreas y sus formas. Todas juntas
constituyen el vocabulario del lenguaje de visión… Las posiciones, direcciones y
diferencias en tamaño, forma, brillo, color y textura son medidos y asimilados por el
ojo.” [4]
De acuerdo con lo anterior, un atributo visual son la serie de características que posee
un objeto gráfico que son perceptibles visualmente, como su orientación, color y forma.
Los atributos visuales se pueden clasificar en:
Atributos visuales innatos (brillo ~> valor) y culturales (rojo ~> peligro).
Atributos visuales posiciónales, temporales, y retinianos (tamaño, textura,
orientación forma, transparencia, color).
10
Ilustración 3: Los atributos visuales. Basado en la imagen original de
http://www.lip.uns.edu.ar/vcuba/percep.htm
2.2. Las estructuras sintácticas
Las relaciones gráficas son las distintas maneras en que el espacio, los objetos gráficos
contenidos en este espacio y los atributos visuales son combinados dentro de estructuras
sintácticas.
Se pueden distinguir dos relaciones básicas: La relación objeto-espacio y la relación
objeto-objeto
La relación objeto-espacio en la cual el objeto se interpreta dependiendo del espacio en
que se encuentre; a modo de ejemplo supongamos que estamos mostrando un punto de
la ciudad a alguien mediante un mapa hecho en una servilleta, usando un bolígrafo.
11
Anteriormente se advirtió que el espacio gráfico no es el espacio físico que en el
ejemplo sería la servilleta, sino una construcción mental que nos hace imaginar esa
servilleta como un lugar. Los trazos que hagamos en la servilleta, cobran significado
con este espacio gráfico simulando las calles del lugar; las relaciones objeto-objeto son
otro tipo de relación que se explicaran a continuación.
Ilustración 4: Relaciones gráficas
2.3. Relaciones Objeto-Objeto
Dentro de estas relaciones se encuentran dos categorías; relaciones objeto-objeto
mediante sus atributos y objeto-objeto mediante relaciones espaciales, en la primera se
hacen distinciones entre los objetos relacionados con sus atributos. Las relaciones
espaciales objeto-objeto se revisaran más a fondo, ya que suelen ser de más utilidad en
la programación visual. Una relación de atributos suele ser más sencilla de elaborar que
una relación espacial ya que con los atributos se puede realizar una cantidad infinita de
combinaciones, en una relación espacial hay mayor riesgo de no ser fácilmente
interpretable.
A continuación se presentan varios tipos de relación espacial objeto-objeto.
Relaciones espaciales entre objetos y posiciones.
Relaciones espaciales entre objetos.
Relaciones de atributos entre objetos.
Relaciones objeto-espacio
Relaciones objeto-objeto
Relaciones espaciales Relaciones basadas en atributos
12
2.3.1. Separación mediante un separador
Un separador es una línea o gráfica en forma de banda, que se encuentra en medio de
los objetos gráficos que separa. Una separación puede estar ordenada o no. Si es el
primer caso esta separación está sujeta a interpretación.
Ilustración 5: Ejemplo del uso de separación de objetos mediante un separador
2.3.2. Alineación
Es una relación de objeto – objeto en el cual los objetos están colocados en cadena, una
alineación puede ser ordenada o no ordenada, en el caso de no estar ordenada, un
cambio de posición entre los objetos no cambiaría el significado de la representación.
13
Ilustración 6: Ejemplo de alineación
2.3.3. Enlace mediante un conector
El enlace es la relación más básica de las relaciones objeto-objeto en el cual intervienen
nodos y conectores. Un conector es un objeto gráfico en forma de flecha, banda o línea
que está unida de extremo a extremo a objetos gráficos (nodos), conectándolos.
Ilustración 7: Ejemplo de enlaces mediante conectores
14
2.3.4. Contención mediante un contenedor
En la relación de contención intervienen nodos y contenedores. Un contenedor es un
objeto gráfico que contiene otros objetos gráficos (nodos). Los objetos contenidos se
encuentran anclados dentro del contenedor.
Un símbolo compuesto, es un objeto gráfico compuesto de un pequeño número de
objetos gráficos simples, creándose una relación de contención de los objetos pequeños
al objeto más grande. La mayoría de los símbolos compuestos son miembros de una
familia, la cual está caracterizada por compartir un vocabulario visual y una gramática
composicional.
Ilustración 8: Ejemplo de contención
15
3. La programación visual y sus avances en el tiempo
En este capítulo se presentan varios lenguajes que han sido de suma importancia en la
historia de la programación visual, identificando sus ventajas y desventajas, finalmente
se muestran estudios realizados sobre estos lenguajes donde se reflejan los beneficios y
los impedimentos que han impedido que sean usados ampliamente.
3.1. Lenguajes más importantes en la programación visual
El campo de la programación visual ha crecido gracias al desarrollo de la computación
gráfica, lenguajes de programación y la interacción hombre–máquina, iniciándose este
proceso desde la primera aplicación gráfica llamada Sketchpad, diseñada en 1963 sobre
un TX-2 en el MIT. Sketchpad permitía a los usuarios trabajar con un lápiz óptico con
el fin de crear gráficos en 2d, pero solo se podían crear figuras sencillas, como líneas y
círculos. El usuario podía unir las figuras mediante enlaces y moverlas en tiempo real. A
partir de ahí surgieron una serie de lenguajes visuales que proponían mejorar la forma
de programar. [5]
A continuación, se exponen los lenguajes más significativos en la historia de la
programación visual.
3.1.1. DDN
En los años 70 Davis elaboró un concepto de programación gráfica llamado Redes de
conducción de datos (DDN). En DDN los programas eran representados como un flujo
de datos cíclico con variables fluyendo a lo largo de arcos. El lenguaje operaba en un
nivel muy bajo, pero la intención de Davis era ilustrar conceptos clave como la
viabilidad de proveer interacción, llamados de procedimientos y ejecución condicional
sin recurrir a un lenguaje textual [6].
16
3.1.2. GPL
Hacia los comienzos de los 80, Davis propuso un lenguaje más práctico de mayor nivel
conocido como Lenguaje de programación gráfico GPL. Davis y Lowder afirmaron que
la programación textual carecía de claridad intuitiva y propusieron ir más allá que crear
grafos como ayuda para el diseño, creando un ambiente en el cual el programa fuese un
grafo.
En GPL cada nodo se mostraba de forma atómica con la posibilidad de ser expandido
revelando un subgrafo dentro de él, obteniendo una programación estructurada. Estos
subgrafos podían ser definidos recursivamente, los arcos en el grafo tenían un tipo
definido y todo el ambiente prestaba facilidades para la depuración (debugging), usando
visualización o programación basada en texto si se deseaba [6]. Todo esto resultaba muy
prometedor, pero el gran problema fue la carencia de adecuados dispositivos gráficos; la
principal razón para el rápido desarrollo de todos estos conceptos.
3.1.3. FGL
En 1981 los investigadores Keller y Yen desarrollaron en lenguaje denominado
Lenguaje de funciones gráficas (FGL), nació también del mismo concepto de desarrollar
grafos de flujos de datos directamente. A diferencia de GPL que era un lenguaje basado
en tokens, FGL está basado en un modelo estructural propuesto por Davis y Keller, el
cual contiene el mismo modelo de estructuras de nodos y arcos del modelo basado en
tokens a diferencia que cada nodo crea una o más estructuras de datos de sus arcos
salientes permitiendo un acceso aleatorio a las estructuras de datos [6] por lo tanto, los
datos son agrupados en estructuras en cada arco en vez de fluir en torno al sistema.
3.1.4. Grunch
En 1982 se desarrollo el sistema Grunch, el cual fue creado por de Jong, quien también
creo el lenguaje textual basado en flujos de datos Cajole, Grunch permitía de forma
gráfica desarrollar estos flujos de datos y mediante una herramienta llamada Crunch se
podía convertir el grafo a Cajole [12].
17
3.1.5. ARK
A mediados de los ochenta ARK sale a la luz. Implementado en Smalltalk-80, provee a
los usuarios un ambiente animado en 2d con el fin de crear simulaciones interactivas. El
sistema estaba diseñado con el fin de que programadores inexpertos crearan
simulaciones e interactuaran con estas. El usuario controlaba un apuntador en forma de
mano, el cual podía interactuar con objetos como bolas y bloques, los cuales poseían
masas y velocidades; con otros objetos externos llamados interactores, representaban
leyes físicas como la gravedad. Su interfaz gráfica era similar a las interfaces usadas
hoy en día.
A pesar de ser un lenguaje de propósito especifico, los usuarios no solo podían crear
simulaciones usando objetos e interactores pre construidos, sino también nuevos
interactores a partir de sus diálogos y botones [5].
Ilustración 9: Entorno gráfico de ARK
18
Ilustración 10: Área de trabajo de ARK
3.1.6. LabView
Es uno de los lenguajes más conocidos desarrollado en la mitad de los años ochenta que
permitía la construcción de instrumentos virtuales para el análisis de datos en
laboratorios. Se pensó con el fin de ser usado por personas que no son programadores
profesionales [6]. Un programa en LabView es construido conectando funciones
predefinidas, representadas en forma de cajas con iconos, usando arcos como flujo de
datos. Cada componente también tiene una interfaz visual para permitir el diseño del
instrumento virtual. Con Labview los programadores inexpertos han podido desarrollar
programas de mediana complejidad e incluso LabView está diseñado para programar
en él aplicaciones equivalentes a millones de líneas de código en lenguajes textuales [5].
Con LabView se pude crear toda clase de programas aunque su mayor enfoque está
dado para ingenieros y científicos en tareas como:
Adquisición de datos
Control de instrumentos
Automatización Industrial
Diseño de control
19
Diseño embebido
Domótica
A continuación se hace una breve descripción de la aplicación y un ejemplo.3
Componentes Básicos de LabView
Panel Frontal
Se trata de la interfaz gráfica del VI con el usuario. Esta interfaz recoge las entradas
procedentes del usuario y representa las salidas proporcionadas por el programa. Un
panel frontal está formado por una serie de botones, pulsadores, potenciómetros,
gráficos, etc [7]. Cada uno de ellos puede estar definido como un control (a) o un
indicador (b). Los primeros sirven para introducir parámetros al VI, mientras que los
indicadores se emplean para mostrar los resultados producidos, ya sean datos adquiridos
o resultados de alguna operación.
Ilustración 11: Panel frontal de LabView
3 Si el lector se encuentra interesado en LabView puede ingresar a su página oficial: http://www.ni.com/labview/
20
Diagrama de bloques
El diagrama de bloques constituye el código fuente del VI. En el diagrama de bloques es
donde se realiza la implementación del programa del VI para controlar o realizar
cualquier procesado de las entradas y salidas que se crearon en el panel frontal. Este
incluye funciones y estructuras integradas en las librerías que incorpora LabView. En el
lenguaje visual las funciones y las estructuras son nodos elementales [8]. Son análogas a
los operadores o librerías de funciones de los lenguajes convencionales.
Los controles e indicadores que se colocaron previamente en el Panel Frontal, se
materializan en el diagrama de bloques mediante los terminales.
Ilustración 12: Diagrama de bloques, a) Función, b) Termianles (control e indicador), c) Estructura
21
Paleta de herramientas
Se emplea tanto en el panel frontal como en el diagrama de bloques. Contiene las
herramientas necesarias para editar y depurar los objetos tanto del panel frontal como
del diagrama de bloques.
Algunas de las opciones que presenta esta paleta son las siguientes:
Operating tool – Cambia el valor de los controles.
Positioning tool – Desplaza, cambia de tamaño y selecciona los objetos.
Labeling tool – Edita texto y crea etiquetas.
Wiring tool – Une los objetos en el diagrama de bloques.
Object Pop-up Menu tool – Abre el menú desplegable de un objeto.
Scroll tool – Desplaza la pantalla sin necesidad de emplear las barras de
desplazamiento.
Breakpoint tool – Fija puntos de interrupción de la ejecución del programa en
VIs, funciones y estructuras
Probe tool – Crea puntos de prueba en los cables, en los que se puede
visualizar el valor del dato que fluya por dicho cable en cada instante.
Paleta de controles
Se utiliza únicamente en el panel frontal. Contiene todos los controles e indicadores que
se emplean para crear la interfaz del VI con el usuario.
22
Ilustración 13: Paleta de controles de LabView
Paleta de funciones
Se emplea en el diseño del diagrama de bloques. La paleta de funciones contiene todos
los objetos que se emplean en la implementación del programa del VI, ya sean
funciones aritméticas, de entrada/salida de señales, entrada/salida de datos a fichero,
adquisición de señales y temporización de la ejecución del programa [7].
Ilustración 14: Paleta de funciones de LabView
A continuación se presenta el ejemplo de la implementación de un instrumento virtual
en LabView, de forma muy general con el fin de dar una idea al lector de como se
programa esta herramienta.
23
En primer lugar, se debe construir el panel frontal deseado:
Ilustración 15: Creación de un panel frontal. Mediante de la paleta de de controles se puede diseñar el panel
frontal.
Ilustración 16: Creación del diagrama de bloques
24
1. Abrir el diagrama de bloques (menú Window, opción Show Diagram).
2. Colocar el While Loop (subpaleta Structures de la paleta de funciones). Dicha
estructura, como todas las demás es de tamaño ajustable.
3. Seleccionar la función Random Number (0-1) de la subpaleta Numeric del menú
de funciones.
4. Seleccionar la función Wait until Next ms Multiple de la subpaleta Time &
Dialog del menú de funciones.
5. Seleccionar la función de multiplicación de la subpaleta Numeric, del menú de
funciones, así como una constante numérica, introduciendo el valor 1000 en
lugar de 0, que es el que aparece por defecto.
6. Colocar los cables tal y como se muestra en la figura anterior, empleando para
ello la Wiring Tool.
7. Volver al panel frontal. Con la Operating Tool poner el interruptor en su
posición ON. Ejecutar el programa pulsando el botón run.
8. La frecuencia de ejecución de las iteraciones del bucle While es la indicada en el
panel frontal con el control Loop Delay (sec). Es decir, se generará y
representará un valor aleatorio cada periodo de tiempo (en segundos)
seleccionado.
9. Para finalizar la ejecución del bucle, colocar el interruptor en la posición de
OFF. De ese modo la condición de ejecución del bucle While será falsa, por lo
que se detendrá a la siguiente iteración.
Varios críticos ponen en duda que LabView se considere un lenguaje ya que carece del
concepto de recursión (Aunque es posible efectuar recursión de una forma no
convencional en otros lenguajes visuales) y no use características de la programación
orientada a objetos [5] además, posee estructuras gráficas enfocadas a solucionar
problemas particulares.
25
Jeff Kodosky cofundador de National Instruments, afirma que las herramientas
adicionales de LabView dan mayor fortaleza al lenguaje, sin que pierda el hecho de ser
un lenguaje de propósito general [9].
A LabView también se le critica que es un lenguaje propietario de National Instruments
y a diferencia de C, C++ y otros lenguajes no es administrado por un comité de
estandarización como ANSI.
Entre otras críticas se encuentra el hecho tener que instalar un programa en cada
computador que quiera ejecutar una aplicación de LabView, ya que la aplicación por sí
sola no se puede ejecutar, reduciendo la portabilidad y acrecentando los costos de las
compañías debido a que su precio puede oscilar entre $1199 y $4299 dólares4.
3.1.7. Prograph
Prograph era un lenguaje visual más general que LabView, el cual combinaba los
principios de flujo de datos con programación orientada a objetos. Considerado como el
más exitoso de los lenguajes visuales [5]. Se originó en 1982 en la Universidad técnica
de Nueva Escocia, luego fue propiedad de Pictorius Inc. Su último lanzamiento fue
Prograph CPX (Cross-Platform Extensions) tras la desaparición de Pictorius Inc en el
2002.
Prograph permitía al programador trabajar con niveles alto y bajo simultáneamente.
Computaciones primitivas como operadores aritméticos, llamadas a métodos, etc. eran
combinados para formar cuerpos de métodos por los diagramas de flujos de datos. Los
métodos eran organizados en clases, los cuales a su vez eran organizadas en jerarquías
de clases. Adicionalmente, Prograph proveía al programador con objetos persistentes
que eran almacenados en una base de datos de Prograph entre diferentes invocaciones
del programa.
4 Precio de 2007
26
Ilustración 17: Ventanas de Prograph, donde se pude apreciar la ventana de métodos y los dos casos del
método CALL
En la figura anterior, se puede ver que en la ventada Methods contiene los nombres de
todas las funciones siendo CALL la rutina principal.
Los métodos consisten en uno o más casos. Cada caso de un método es un diagrama de
flujos de datos que describe como el caso es ejecutado. Cada elemento básico del flujo
de datos asigna una operación que será usada con los datos que entran a este a través de
uno o más terminales. Las salidas de los datos de estos elementos también pueden ser
más de uno y como suele ocurrir, las líneas en el diagrama de flujo indican como los
datos se propagan desde una salida a las terminales [6].
El método CALL consta de dos casos. El número del caso, como también el total
número de casos es indicado en el titulo de la ventana que contiene el diagrama de
flujos del método. Este contiene llamados a dos métodos del sistema “ask” y “show” y
un llamado de un método definido por el usuario “sort”.
La ejecución de “CALL” comienza evaluando el resultado de llamar al método “ask” y
la constante “()” (refiriéndose a una lista vacia). “ask” obtiene el valor del usuario el
cual envía el valor por su salida, una vez realizado esto, los resultados son pasados a
“sort” que será la próxima operación a ser ejecutada. Note que “sort” está acompañado
de un icono a su lado, este se llama next-to-failure, indica que en caso de que “sort”
falle se ejecutará el segundo caso de CALL.
27
En el caso uno de “CALL” “sort” es un múltiple lo que indica que será ejecutado varias
veces. Se reconoce por representarse como un icono con múltiples llamados con flechas
que salen y entran del mismo sitio; este tipo de múltiple es llamado múltiple iterativo
donde las salidas son las entradas de la próxima iteración. La ejecución del ciclo
continuará hasta que no sea ejecutado un control llamado terminate-on-success dentro
del método “sort”.
Ilustración 18: Representación del método "sort" en Prograph
El método “sort” expuesto en la figura anterior, contiene dos controles que terminan la
ejecución del método. El primer control (comparando la entrada de “sort” con “()”),
llamado terminate-on-success, indicando que el ciclo se termina con un estado de
“éxito”. El segundo control (comparando la salida de la partición con “()”), llamado
terminate-fail-on-success, indicando que el ciclo se termina con un estado de “falla”.
Como se discutió anteriormente este efecto de falla obliga a que el caso 2 de CALL se
ejecute [5].
La gran mayoría de lenguajes usan estructuras como condicionales (if y switch) y ciclos
(while y for). Prograph usa estructuras con resultados similares llamados controles.
28
Existen dos tipos de controles, el primero permite continuar por el flujo si el dato a
evaluar es verdadero y el segundo control permite continuar el flujo si la evaluación del
dato es falsa. Se diferencian el primero por estar identificado con “chulo” y el segundo
con una “X”. Cada control tiene variantes indicado con líneas arriba y abajo.
Ilustración 19: Los controles de Prograph
Los controles con líneas encima son llamados controles de terminación, los cuales
terminan el ciclo si el valor que evalúan es cierto para el caso del control con “símbolo
de chequeo” y falso con el control “X”. Los controles con líneas por debajo se llaman
controles de finalización los cuales permiten al programa finalizar la ejecución de la
aplicación en caso de que la evaluación del dato se cumpla.
Si el control tiene tanto la línea superior como la línea inferior es llamado control de
continuación que finaliza la iteración del ciclo sin importar lo que arrojó la evaluación
del dato; es similar a la expresión continue, presente en varios lenguajes textuales [11].
Aunque la descripción anterior es bastante básica, muestra las características esenciales
de este lenguaje. Cabe destacar que el mayor logro de este lenguaje es su habilidad de
liberar al programador de implementar a innecesarios niveles de detalle que poseen la
mayoría de los lenguajes textuales, de ahí su éxito comercial.
A Protograph se le critica sus controles, ya que se pueden confundir por sus distintas
variantes, sobre todo los programadores novatos. Con respecto a los ciclos, se le critica
por poseer una sintaxis gráfica compleja, a su vez, para poder visualizar un ciclo se debe
abrir en una nueva ventana, dándose la posibilidad de que la pantalla del programador
se llene de ventanas dificultando la comprensión del algoritmo. Pero no solo se puede
29
llenar la pantalla de ventanas de ciclo; los controles también generan ventanas para ver
su estructura interna que son indistinguibles entre las ventanas de ciclo.
3.1.8. Drakon
Drakon no es un lenguaje famoso dentro del ámbito de los lenguajes de programación
visual, sin embargo es descrito aquí ya que Drakon es utilizado en la creación del
lenguaje que se propone en este documento.
ДРАКОН- Дружелюбный Русский Алгоритмический язык, Который
Обеспечивает Наглядность (Drakon-Lenguaje amigable ruso que garantiza la
claridad). Se inició en 1986 para el proyecto espacial ruso Buran y se finalizó en 1998.
No se encuentra fácilmente información de cómo se implementó este lenguaje para el
proyecto. La información más relevante se encuentra en el libro de Vladimir
Parondzhanov-Como mejorar el trabajo de su mente. En este libro se explora el
lenguaje desde una perspectiva general, no solo para la programación informática si no
también para una serie de actividades no relacionadas con la informática, buscando que
con este leguaje haya un entendimiento mutuo de los procedimientos (sin importar que
sean o no programadores), la idea es que se programe para el ser humano más no para la
máquina. Otro de los objetivos de Drakon es la generación automática del código, que
gracias a su estructura permite fácilmente convertirlo a un lenguaje textual5.
Se describirán los aspectos básicos del lenguaje que son necesarios para la creación del
lenguaje propuesto.
Drakon está compuesto por los iconos que se encuentran en la siguiente figura:
5 Su lectura es recomendable: http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=ru_en&trurl=http%3a%2f%2fdrakon.pbwiki.com%2f
30
Ilustración 20: Iconos de Drakon
31
Los macroiconos son composiciones de los iconos básicos que describen una operación:
Ilustración 21: Macro iconos de Drakon
32
Para estos iconos y macroiconos Drakon aplica una serie de reglas o estructuras para
ubicarlos a través del espacio.
El icono pregunta permite establecer condiciones en el algoritmo, los siguientes hijos
procedentes de las bifurcaciones deben ubicarse un nivel más abajo dentro de la
representación gráfica. Este icono posee dos bifurcaciones identificados con las
etiquetas «si» y «no», estas etiquetas pueden estar en cualquiera de las dos
bifurcaciones.
Ilustración 22: Distintas bifurcaciones en Drakon
Para darle mayor claridad a la representación, Drakon establece una regla llamada:
«entre más esté a la derecha más tarde se ejecuta» donde cada caso de la bifurcación
debe correrse más hacia la derecha, permitiendo al programador diferenciar casos base
de casos particulares.
33
Ilustración 23: Diferencias entre aplicarse la regla "entre más en la derecha más tarde se ejecuta" y sin ella
La figura anterior muestra, el mismo algoritmo donde el primer diagrama es
representado sin aplicar la regla «entre más esté a la derecha más tarde se ejecuta»,
siendo evidente la menor claridad que se presenta con respecto al diagrama de la
derecha el cual aplica la regla. A veces es necesario intercambiar la ubicación de las
bifurcaciones para hacer cumplir esta regla.
Otra regla dentro de Drakon es la prohibición de las aliteraciones, se aplica porque
según el autor las repeticiones de un mismo procedimiento dentro de una representación
gráfica pueden molestar al lector, quien tiene que estar leyendo el mismo procedimiento
varias veces. Para solucionar esto se hace uso de las asociaciones verticales.
34
Ilustración 24: Aplicación de la asociación vertical
35
Drakon tiene dos formas de distribuir grupos de iconos a través del espacio: Silueta y
Primitivo.
El primitivo es la representación del grafo común.
Silueta es la representación del flujo usando ramas. Las ramas contienen una entrada y
varias salidas, la entrada usa el icono «operador» con el nombre de la entrada como
marcador y las salidas usan el icono «nombre de ramas» que hace referencia a ramas
existentes. Se puede comparar estas salidas con el comando goto de los lenguajes
textuales, así pues el flujo en la representación silueta es fragmentado en ramas.
Ilustración 25: Diferencia entre la representación usando el diagrama primitivo y el diagrama silueta
36
La representación silueta al igual que los iconos de pregunta debe seguir la regla «entre
más esté a la derecha más tarde se ejecuta». Esto permite que el programador no se
pierda buscando la rama que sigue.
37
Como se ve en la anterior figura las dos imágenes se encuentran incorrectas, ya que
dificulta al programador seguir la secuencia del algoritmo.
La estructura compuesta de ramas presenta una ventaja para los programadores que no
conozcan el algoritmo o que lo hayan olvidado, ya que puede leer los marcadores de
cada rama, que le permitiría recordar lo que realizó o tener una idea de que se trata el
algoritmo.
38
Ilustración 26: Representación de un algoritmo usando diagramación primitiva de Drakon
39
Ilustración 27: Representación del mismo algoritmo de la ilustración 29 usando diagramación silueta
40
Las figuras anteriores representan el mismo algoritmo pero con la diferencia que en la
primera figura se encuentra representado por el modo primitivo, y en la segunda con el
modo silueta.
A la hora de elegir si se representa usando primitivo o silueta, Drakon sugiere que si la
altura del flujo es mayor a 15 iconos se debe usar silueta. En caso contrario no es
necesario fragmentar el flujo, por tanto es mejor graficarlo en modo primitivo.
3.2. Análisis realizado a los lenguajes de programación visuales
Varios autores han realizado estudios con Prograph y LabView concluyendo que tienen
las siguientes ventajas y desventajas:
Los lenguajes visuales basados en flujos de datos permiten al desarrollador
realizar el diseño y la implementación en su propio orden, debido a su
naturaleza, haciendo el proceso de diseño libre y fácil.
La efectividad de los editores de programación continua siendo objeto de
investigación.
La necesidad de comentarios secundarios en los algoritmos continua siendo
necesaria.
Existe una línea muy delgada entre el lenguaje y el ambiente de desarrollo en el
caso de los lenguajes visuales.
La visualización y la animación en particular, son absolutamente esenciales para
que el lenguaje funcione. Existe una diferencia significativa entre ver un
programa gráficamente y verlo dinámicamente.
41
Otros aspectos favorables y desfavorables que arrojaron los estudios realizados y que
deben ser tenidos en cuenta dentro del desarrollo e implementación de un lenguaje de
programación visual son los siguientes:
Se encontró que hubo un incremento de comunicación entre el cliente y el desarrollador,
donde ellos seguían el diagrama de flujos, haciendo sugerencias o correcciones en el
flujo del código. Lo cual es difícil de imaginar una situación similar usando código
textual. El tiempo de desarrollo mejoro en este caso en un factor de 4.
Los lenguajes de programación visual permiten que las fases de diseño y codificación
sean mezcladas, esto presenta un inconveniente ya que no existen metodologías de
desarrollo de software que permitan esta unión, reduciendo los beneficios que este
provee [6]. Aún así esta situación permite al cliente apersonarse de la situación,
reduciendo costosos errores por problemas de comunicación entre el cliente y el
desarrollador, reduciendo tiempo y dinero.
La razón más importante para el poco uso de la programación visual es la dirección en
la cual ha sido enfocada; las mayores investigaciones se realizan en torno al desarrollo
en pequeño, es decir en programas reducidos elaborados por una o a lo sumo dos
personas. La carencia de herramientas enfocadas a proyectos de desarrollo grandes ha
impedido la expansión de los lenguajes visuales. A su vez, como se comentó
anteriormente, se deben aplicar metodologías de desarrollo distintas a las que se
enfocan en la programación textual. Las compañías no se arriesgan en trabajar sobre un
lenguaje que no tiene una serie de procedimientos que garantice la finalización exitosa
de un proyecto. [12]
Se Muestran una serie de aspectos esenciales que en los lenguajes de Programación
Visual no aparecen, los cuales son vitales para el desarrollo a gran escala [12]:
Construir sistemas, componiendo un gran número de módulos e interconexiones.
Localizar y reutilizar componentes en múltiples niveles de abstracción.
Proporcionar acceso instantáneo a información auxiliar como requerimientos,
documentación y notas de ingeniería.
Navegar en el sistema en múltiples niveles de abstracción simultáneamente.
42
Refinar especificaciones a implementaciones.
Dar soporte de pruebas, análisis y depuración.
Localizar y reparar errores de interconexión de módulos.
Aunque los objetivos de este proyecto no involucran el estudio del desarrollo a gran
escala en la programación visual, cabe resaltar que esta es una problemática importante
la cual debe ser investigada con mayor profundidad, sin embargo, se espera con la
puesta a prueba del lenguaje aquí propuesto, se pueda llegar a la solución de algunos de
estos problemas.
43
4. PFC como propuesta de solución
En esta sección se propone PFC, un lenguaje basado en flujos de datos; mediante sus
estructuras se espera solucionar algunos de los problemas de la programación visual
mostrados anteriormente, así como conocer las dificultades que se pueden presentar en
el diseño de un lenguaje visual.
La propuesta que se presenta en este documento no pretende ser la solución definitiva al
lenguaje visual. Se pretende explorar posibles soluciones a las problemáticas que más
afectan a los lenguajes visuales y mediante una serie de estructuras bien diseñadas llevar
la programación visual a un nivel de mayor uso.
Al diseñar lenguajes visuales se sugiere pensar primero en el entendimiento del
programador y por último en los paradigmas de la programación textual. Esto con el fin
de no limitar la creación de nuevas estructuras que podrían facilitar el entendimiento y
la construcción de algoritmos, los cuales son los objetivos principales de la
programación visual. Sin embargo, el lenguaje propuesto está pensado para que sus
diagramas sean fácilmente convertibles en líneas de código de un lenguaje textual. Por
lo tanto es necesario partir de los paradigmas actuales de la programación textual.
La manera más adecuada para representar un algoritmo bajo estos requerimientos es
hacer uso de la diagramación por flujos de datos, aplicando estructuras que respondan a
las necesidades de la ingeniería de software actual y que sean equivalentes a estructuras
de lenguajes textuales. El hecho de no crear estructuras radicalmente distintas ayuda a
visualizar de forma más clara que defectos o beneficios se puede encontrar en la
programación visual. Esta unión compuesta de un lenguaje basado en flujos de datos y
nuevas estructuras representan el lenguaje que se propone en este proyecto: PFC -
Programación por flujos basado en componentes.
44
Objetivos de PFC
Buscar un mayor entendimiento de los algoritmos.
Generar estructuras fácilmente traducibles a clases o librerías de otros lenguajes.
Permitir que funciones de lenguajes textuales puedan ser utilizadas.
Programar de forma más rápida en comparación con un lenguaje textual.
Identificar las ventajas y desventajas que tenga el lenguaje, lo cual será tratado
en el capítulo de Análisis de la solución.
4.1. Los componentes
Son los elementos fundamentales de PFC, cumplen con la mayoría de los objetivos del
lenguaje; dependiendo de su tipo, proporcionan al programador diferentes funciones.
4.1.1. Componentes modulares
Se usan con el fin de proporcionar una mayor claridad al flujo, su propósito es contener
flujo dentro de él. Los módulos permiten al programador definir los elementos
principales de la arquitectura del programa o partes de este.
Estos componentes no realizan ninguna transformación del flujo, solo lo contienen,
pueden presentarse en cualquier parte del flujo.
Ilustración 28: Ejemplo del uso de los componentes modulares
Carga de la imagen Decodificación de la imagen
Aplicación de filtros Representación en pantalla
45
4.1.2. Componentes de métodos
Uno de los objetivos es hacer de PFC un lenguaje visual que sea fácilmente traducible a
un lenguaje textual sin importar si se usa el paradigma de la programación orientada a
objetos. El paradigma de la programación orientada a objetos, busca mediante los
objetos representar objetos reales del mundo. Pero en lenguajes como java, con
preocupación se ha visto que constantemente se acude al “casting” en los objetos,
perdiéndose el real sentido del objeto y dificultando la comprensión del programador.
Los componentes de métodos al igual que las clases que definen los objetos contienen
métodos, pero a diferencia de estos, las clases agrupan métodos que modifican una serie
de atributos en común. Los componentes de métodos agrupan métodos en torno a una
serie de operaciones con características en común. Estos componentes no contienen
atributos, únicamente transforman los “atributos” los cuales dentro de PCF es llamado
flujo de transformación. De este modo el flujo de transformación puede ser usado por
componentes que transformen este tipo de flujo. De este modo el “casting” no existe,
siendo más fácil para el programador entender el flujo.
Ilustración 29: Entradas de los componentes de métodos y sus métodos
Como se dijo anteriormente, un componente de métodos modifica el flujo de
transformación que se le asigne. El flujo de transformación es una variable compleja, la
cual contiene una o más variables. Pero para transformar este flujo es necesario elegir el
<m>Método A
<m> Método B
<m> Método C
Flujo de transformación
<i>implementación 1<i>implementación 2<i>implementación 3<i>implementación 4
Parámetros
Componente de métodos Método A
46
método, que además podrá requerir parámetros dependiendo de cómo efectúe la
transformación. El componente también puede retornar un valor dependiendo del
método que se eligió.
Los métodos de los componentes de métodos
Los métodos son similares a los métodos de los lenguajes orientados a objetos; aceptan
parámetros con el fin de transformar el flujo de transformación del componente de
métodos al que pertenece.
Lo métodos pueden tener distintas implementaciones, según si el programador
considera que determinada implementación presenta mayor desempeño en su algoritmo,
podrá elegirla.
4.1.3. Componentes de importación
Los lenguajes textuales han permitido a los programadores acudir a librerías, las cuales
permiten reducir el tiempo de desarrollo. PFC permite mediante los componentes de
importación hacer uso de ellas.
A pesar de la ventaja que ofrece este componente, va en contravía de permitir a los
programadores un mayor entendimiento del código, ya que al usarse una función de otro
lenguaje, se hace un acto de fe que de alguna manera transformará el flujo; más no se
puede conocer como lo hace.
Los componentes de importación, como los componentes de métodos contienen
métodos; pero los métodos de importación igualmente pueden contener distintas
implementaciones, que en vez de contener flujos contienen llamados a funciones que
varían dependiendo del lenguaje al que pertenezcan.
47
Ilustración 30: Jerarquía de los elementos de importación
Tanto los componentes de importación, como los de métodos son reutilizables a
diferencia de los componentes modulares.
4.2. Drakon y los componentes
Drakon presenta una estructura de flujo idóneo para ser vinculado con los componentes,
sus reglas permiten entender el código más fácilmente, el cual hace parte de los
objetivos de PFC. Estas reglas pueden ser implementadas en una aplicación, aunque
reglas como la prohibición de las aliteraciones necesitan de la colaboración del
programador, así como la regla «entre más esté a la derecha más tarde se ejecuta» en el
caso de las bifurcaciones, donde el programador se ve en la obligación de
intercambiarlos de sitio para poder cumplir la regla.
Los componentes junto con los iconos de Drakon conforman los iconos de PFC.
En necesario conocer cómo trabaja esta unión, en el capitulo siguiente se mostrará el
prototipo realizado, y nos dará una idea acerca de cómo trabaja PFC.
<m> Método A
<m> Método B
<m> Método C
<i> Implementación 1
<i> Implementación 2
<i> Implementación 3
LenguajeC++
Funciónordenar
Componente de importación
Método de importación
Interfaz de adición de funciones externas
48
5. Descripción del prototipo de PFC
El prototipo se implementó en Java usando el ambiente de desarrollo Fedora Eclipse,
para la representación gráfica se usó la librería Jgraph.
El prototipo implementara algunos iconos de Drakon, y su representación esta basado
en el modo primitivo. Los principales objetivos de este prototipo son:
Implementar PFC para comprobar su efectividad.
Convertir un diagrama PFC a código Java.
Ilustración 31: Entorno gráfico de PFC
Barra de herramientas Pestañas de navegación
Barra de variables y parámetros
Barra de iconos Área de trabajo
Barra de configuración
49
En el programa los componentes se identifican con los siguientes iconos:
Ilustración 32: Los componentes con sus contenidos
Componente de métodos Componente de importación
Método Método de importación
Implementación Implementación importada
Componente modular
50
Los iconos de los componentes de métodos e importación son iguales debido a que al
ser usados por el programador, a este no le interesa si fue importado o no, solo podrá
saber si es importado o no si lo edita.
El área de trabajo es el espacio donde se grafican los diagramas, pero no siempre se
grafica usando la estructura de Drakon. Por ejemplo cuando se están agregando
métodos, los métodos aparecen ordenados en una columna.
Igualmente ocurren variaciones con la barra de iconos, la barra de variables y
parámetros y las pestañas de configuración dependiendo de que se está programando.
En el área de trabajo se puede programar:
Flujo principal (flujo general).
Flujo de un módulo.
Adición de métodos a los componentes de métodos o de importación.
Adición de implementaciones de métodos comunes o métodos de importación.
Flujo de una implementación (no importada).
5.1. Edición de flujos
En el caso de la implementación de flujos la barra de iconos contiene los iconos de la
siguiente figura:
51
Ilustración 33: Barra de iconos, mostrando iconos cuando se edita un flujo
En el caso de las pestañas de configuración para el flujo principal, el modular y el de
implementación son:
Proyecto: En él se le puede colocar el nombre al proyecto, su descripción y su
autor.
Componentes usados: Se listan los componentes que han sido usados en el
proyecto, se hayan abierto, o se hayan creado.
Variables usadas: Lista las variables complejas que se han creado en el proyecto.
Adicionar/Modificar variables: Crea o modifica variables.
Para el caso de la barra de variables y parámetros, si se edita el flujo principal, este
muestra las variables creadas, si por el contrario se edita el flujo que representa la
52
implementación de un método esta barra muestra las variables, los parámetros del
método al que pertenece y la variable de transformación.
En el caso del flujo modular pueden presentarse dos casos, si el módulo pertenece al
flujo principal esta barra mostrará las variables del flujo principal, pero si el módulo
pertenece a una implementación contendrá las variables, parámetros y flujos de
transformación de la implementación.
Para agregar iconos a un flujo, si se está editando un flujo principal, se debe colocar
titulo al proyecto; para ello se hace doble click al título del proyecto y aparecerá un
icono con unas herramientas, se hace click a este icono que desplegará un diálogo donde
se coloca el titulo.
Ilustración 34: Pasos para editar el icono titulo
53
Los iconos se interconectan con otros por medio de puertos, en caso del titulo, este
contiene un puerto en su parte inferior.
Ilustración 35: Puertos de los iconos
Para agregar un icono se debe primero hacer click a un puerto y luego a uno de los
iconos o componentes disponibles.
Ilustración 36: Conexión entre dos iconos
Como en el caso de la edición del título de icono titulo, los demás iconos cuentan con el
mismo botón que al hacerle click desplegará un dialogo que solicita información
dependiendo del icono.
54
Ilustración 37: Dialogo de configuración del icono de pregunta
Para agregar componentes al flujo de igual forma se hace click en el puerto de un icono,
luego se va a la pestaña «componentes usados», donde se elige el componente haciendo
click.
Para retornar una bifurcación a su origen, se hace click en el puerto del último icono de
la bifurcación y se hace click en la línea donde se desea retornar. Se le preguntará si
desea hacer conexión con la línea seleccionada. Si se responde afirmativamente se
pregunta si el tipo de conexión es de retorno o ciclo, donde se debe elegir retorno.
55
Ilustración 38: Situación previa al uso del retorno de la línea
Ilustración 39: Bifurcación retornando al camino principal
En este prototipo existen dos formas de hacer un ciclo, la primera es usar los iconos de
ciclo provenientes del lenguaje Drakon, o usar el procedimiento anterior colocando una
línea en un paso anterior, para hacer esto último, se tiene que realizar con un icono de
pregunta y se tiene que usar el puerto lateral.
56
Ilustración 40: Situación previa al ciclo
Ilustración 41: Aplicación del ciclo, usando líneas
57
5.2. Creación de componentes de métodos
Para crear un componente de métodos se debe elegir el botón con las siglas CM en la
barra de herramientas.
Ilustración 42: Botón de adición de componentes de métodos dentro de la barra de herramientas
Al hacer click se le pregunta por el nombre que se le quiere colocar al componente. Una
vez colocado se crea una nueva pestaña para adicionar los métodos del componente.
Ilustración 43: Entorno gráfico, donde se edita un componente de métodos
58
Como se puede ver en la imagen anterior la barra de iconos cambia, mostrando un solo
botón, que hace referencia al icono método.
Para agregar un método solo basta hacer click sobre el botón.
Ilustración 44: Ubicación de métodos
Como se comento anteriormente, los métodos son ordenados en una columna. Para
poder editar un método se debe hacer doble click sobre ellos.
Ilustración 45: Botones de edición en el icono de método
Inmediatamente aparecerán 3 botones, el primero (con dibujo de herramientas) permite
el cambio del nombre, el segundo su descripción (aunque no se implementó diálogo de
descripción) y por último el icono con la imagen de rueda permite la edición.
59
Si se hace click en el icono de rueda, se creará otra pestaña donde se podrán agregar
implementaciones, del mismo modo como se agregan estos métodos. También aparecen
dos pestañas dentro de las pestañas de configuración, en la primera se puede colocar la
descripción del método y su variable de transformación y en la segunda se puede
agregar parámetros.
5.3. Creación de componentes de importación
Para los componentes de importación, su edición es similar, la barra de iconos solo tiene
el icono de método de importación, al editar el método de importación se pueden
agregar implementaciones, parámetros, variable de transformación, etc. Del mismo
modo que se hace con la edición del método común, la diferencia radica en la edición de
las implementaciones, mientras que las implementaciones del componente de métodos
son un flujo, las implementaciones de los métodos de importación son un diálogo en
donde se agregan funciones y se indica a que lenguaje pertenecen.
Ilustración 46: Diálogo de adición de funciones de importación
60
También en ese diálogo se puede indicar en qué orden están los parámetros en esa
función.
5.4. Agregar variables complejas
Las variables complejas son variables compuestas de una o más variables.
Ilustración 47: Diálogo de edición de variables complejas
Como se observa en la anterior imagen se coloca el nombre del tipo, y se van agregando
las variables del que está compuesta.
5.5. Conversión a Java2SE
Para convertir un proyecto a Java2, se usa el menú Archivo->exportar->Java2 SE,
obteniéndose un dialogo donde se le pide el lugar donde se almacenará la carpeta con el
proyecto convertido.
Lo anterior es básicamente la forma de operar del prototipo. En el siguiente capítulo se
analizará el lenguaje y el prototipo.
61
6. Análisis de PFC
En esta sección se presenta un análisis de la herramienta construida, también se hace un resumen de sus alcances y de que tan bien se cumplieron los objetivos.
El prototipo cumple con la mayoría de los propósitos propuestos, aunque evidencia
dificultades en la elaboración de proyectos a gran escala.
PFC presenta claridad en el momento de mostrar un algoritmo. La diagramación por
flujos resulta ser intuitiva en la representación de algoritmos. La organización de iconos
usando la diagramación “primitivo” evidencia que al representarse un algoritmo con un
gran número de iconos, se hace más difícil su entendimiento, aunque gracias a los
componentes moduladores este inconveniente disminuye un poco; sin embargo se deja
en claro que las representaciones de flujos que posean una gran cantidad de iconos
deben seguir una estructura distinta, como la que ofrece la diagramación “silueta” de
Drakon.
Las representaciones gráficas permiten orientar al programador en el algoritmo, aún así
es necesario contar con documentación y comentarios. En caso de crear programas
grandes, el programador puede perderse si no existen comentarios que expliquen las
tomas de decisión en el momento de la implementación del algoritmo.
Lo comentado por Marat Boshernitsan y Michael Downes [5], donde concluían que
existía una línea muy delgada que separaba un lenguaje visual de su entorno, fue
confirmado en PFC. Los componentes y los flujos juegan un papel importante en la
comprensión de los algoritmos, sin embargo la forma como se construye y se explora es
igualmente importante. El principal error fue pensar en el lenguaje y dejar de lado el
diseño del ambiente gráfico. Normalmente en los lenguajes textuales, el desarrollador
puede valerse únicamente de un editor de texto para desarrollar una aplicación. En
cambio, en los lenguajes visuales por más ventajas que este provea si no se trabaja bajo
un ambiente de desarrollo idóneo, se perderá la mayor parte de sus ventajas. En la
actualidad los programadores acuden a ambientes de desarrollo como es el caso de
Eclipse porque les facilita el desarrollo gracias a sus herramientas. Para un lenguaje
visual es mucho más importante trabajar en un ambiente de desarrollo adecuado.
Un ejemplo de dificultades en el entorno gráfico de PFC es la cantidad de pestañas que
se pueden desplegar cuando el programador edita al tiempo varios componentes, a pesar
de que cada pestaña contiene un icono que identifica que se está editando y un nombre
62
puede confundirlo. Esta proliferación de pestañas ocurre a la hora de implementar un
componente. Por ejemplo, si se desea implementar un componente de métodos, se crea
una nueva pestaña donde se adicionan los métodos, para implementar el método se abre
una nueva pestaña donde se adicionan las implementaciones, para adicionar el flujo a
una implementación se abre otra nueva pestaña donde se adiciona el flujo. Para crear
una nueva implementación se tuvieron que abrir tres pestañas. Las pestañas
proporcionan un beneficio sobre las ventanas ya que se interponen reduciendo la
confusión del programador, pero la cantidad de pestañas también puede llegarlo a
confundir. Es necesario buscar otros componentes gráficos para poder regular la
cantidad de pestañas. Esta dificultad será mucho más evidente si se considera programar
a gran escala.
Para la inserción de componentes se hace uso de una lista ubicada en “componentes
usados”, la cual fue bastante útil ya que cualquier componente se tenía a la mano. Pero
si se utilizara en proyectos de gran escala, la cantidad de componentes sería muy
grande. Esa lista sería ineficiente para ubicar el componente adecuado. Es necesario
pensar en métodos distintos para la búsqueda de componentes. Los métodos de
búsqueda no están orientados a objetos gráficos, las palabras claves pueden no ser de
gran ayuda, aunque si se busca por flujo de transformación los componentes candidatos
pueden reducirse de manera significativa.
Es posible que los componentes gráficos para la creación de interfaces con el que
normalmente se programan no sean los más adecuados a la hora de crear ambientes para
lenguajes visuales. Si al diseñador se le ocurren nuevas formas de inserción de datos
dentro de una estructura gráfica, debería tomarse la molestia en crearlos sin depender de
componentes estándar.
El lenguaje y el prototipo sirvieron de gran ayuda para comprender mucho más los
inconvenientes que se pueden presentar a la hora de diseñar un lenguaje de
programación visual, a su vez los grandes beneficios que la programación visual puede
proporcionar.
La conversión desde PFC a Java no presento dificultades, PFC fue capaz de realizar
conversiones básicas de Java2 SE, involucrando definiciones de clases; cumpliendo el
objetivo de facilidad en la traducción.
63
7. Conclusiones
Este documento describe los conceptos básicos de la composición de representaciones
gráficas y las distintas relaciones entre objetos. Una vez comprendidos los conceptos
básicos de los lenguajes visuales, se revisan los lenguajes más influyentes en la
programación visual, destacando sus avances a través del tiempo y analizando sus
falencias, dentro de las cuales se encuentra el bajo desarrollo de la programación visual
en torno a la programación a gran escala. Con la propuesta de este proyecto se
confirman los beneficios de la programación visual así como las dificultades en su
diseño.
Los proyectos computacionales se hacen cada vez más grandes y los programadores se
pueden ver fácilmente perdidos en mares de líneas de código; más gente de distintas
disciplinas acuden a los computadores, y la programación visual se muestra como una
solución a la computación cada vez más compleja. Por lo tanto, es necesario que se
hagan esfuerzos por el desarrollo de lenguajes de programación visuales estandarizados,
permitiendo la participación de personas interesadas: no solo de conocedores de
ciencias de la computación sino también personas de distintas áreas que permitan una
convergencia de ideas con el fin de crear un lenguaje que sea fácilmente comprensible.
Los avances que se han logrado a través del tiempo en el campo de la programación
visual sirven como base para afrontar el reto de la creación de un lenguaje de
programación visual fácil de construir y de entender, esto constituye un reto difícil, pero
no imposible.
Con este proyecto se conceptualizan aspectos fundamentales en el diseño de lenguajes
de programación visual con una estructura de entornos gráficos que facilite la
implantación de estos. El futuro de los lenguajes de programación visual puede estar en
enfocarse más en crear herramientas que faciliten la programación a gran escala,
pensando en nuevas metodologías de desarrollo que permitan la implantación adecuada
de un lenguaje visual. Por otro lado, los lenguajes de programación visual están
orientados al ser humano por lo que se recomienda que se parta del ser humano hasta la
máquina y no al revés: como se suelen realizar los lenguajes textuales. En la actualidad
64
se presenta un gran avance en el hardware computacional. Es el tiempo adecuado para
volver a retomar un tema que podría beneficiar las ciencias de la computación y a la
sociedad en general.
65
8. Referencias Bibliográficas
[1] Engelhardt Yuri. (2002). The language of graphics. Amsterdam:Universidad de Amsterdam.
[2] Minsky M. (1985). The society of mind. New York: Simon and Schuster.
[3] Gamut,, L.T.F. (1991). Logic, language and meaning, Volume 2: Intensional logic and logical grammar. University of Chicago Press. [4] Kepes Gyorgy. (1944). language of vision. Chicago: Paul Theobald. [5] Marat Boshernitsan, Michael Downes. (2004). Visual Programming Languages: A survey. Berkeley:Universidad de California [6] Wesley M. Johnston, J. R. Paul Hanna, y Richard J. Millar (2004) Advances in Dataflow Programming Languages. University of Ulster: ACM Computing Surveys, Vol. 36, No. 1, March 2004, pp. 1–34. [7] LabView Tutorial, http://www.mech.uwa.edu.au/jpt/tutorial/ieindex.html [8] Tutorials in G, http://www.cipce.rpi.edu/programs/remote_experiment/labview/ [9] Jeff Kodosky. Is LabVIEW a general purpose programming language. http://zone.ni.com/devzone/cda/tut/p/id/5313 [10] Vladimir Parondzhanov-Como mejorar el trabajo de su mente. [11] R. Mark Meyer, Tim Masterson .(2000) Towards a better visual programming language: critiquing prograph's control structures. Canisius College: JCSC [12] Michael Gorlic, Alex Quilici. (1994). Visual Programming-in-the-Large Versus Visual Programming-in-the-Small. IEEE
