Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
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 presenteque 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 espaciosotros 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 adiferencia 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 laprogramació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 estructurapermite 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.pbw iki.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 investigadacon 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 Lenguaje C++ Función ordenar 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 algunosiconos 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 Comose 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:Universidadde 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
Compartir