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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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.
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