ARTÍCULO CIENTÍFICO / RESEARCH ARTICLE

Alternativa de mecanismo de traducción de lenguajes mediante análisis de símbolos de sincronización: T_Gsig

Alternative language translation mechanism by means of synchronization-symbol analysis: T_Gsig

Carlos A. Tavera* Juan F. Diaz**

* PhD. Ciencias de la Computación. Profesor Titular de la Universidad de San Buenaventura, Cali (Colombia). catavera@usbcali.edu.co

Correspondencia: Av. 10 de mayo, La Umbría, vía a Pance. A.A. 7154 y 25162. Cali (Colombia).

** PhD. Informática. Profesor Titular de la Universidad del Valle, Cali (Colombia). jdiaz@univalle.edu.co

Fecha de recepción: 2 de septiembre de 2008
Fecha de aceptación: 24 de marzo de 2009

Resumen

En este artículo se propone un mecanismo de traducción que transforma un programa visual especificado sintácticamente en forma textual, hacia un código de un lenguaje textual. Fundamentalmente, el mecanismo consiste en tomar la especificación de un constructor simple o compuesto, eliminar la información visual mediante análisis de símbolos de sincronización, y transformarlo en un programa equivalente en lenguaje textual. Inicialmente, en el artículo se presenta de manera formal el mecanismo de traducción, luego, se muestran las plantillas para su implementación, y al final, se presentan los resultados de la traducción a través de reglas.

Palabras clave: Lenguajes visuales, Traducción de lenguajes.

Abstract

In this paper is proposed a mechanism of translation that transforms a visual language syntactically specified by textual form, into code of a textual language. Fundamentally, the mechanism consist in taking the simple or composite constructor specification, eliminate the visual information through analysis of synchronization symbols, and transform it into a equivalent program in textual language. Initially, the translation mechanism is present formally, later, the templates for its implementation are shown, and at the end, translation results are presented by rules.

Keywords: Visual languages, language translation.

1. INTRODUCCIÓN

Hacia el año de 1998 el grupo de investigación AVISPA (Ambientes VISuales de Programación Aplicativa) crea el lenguaje CORDIAL, un lenguaje visual para un subconjunto del cálculo PiCO [1]. Luego de las pruebas de eficiencia que el grupo AVISPA le practicó a CORDIAL, se pudo comprobar que aunque el producto de la compilación calculaba los resultados con éxito, la velocidad de ejecución en la mayoría de los casos no fue aceptable.

Más tarde, se logró establecer que el problema estaba, particularmente, en el código generado que, en ciertos casos, contenía código duplicado, inactivo o innecesario. Consecuente con lo anterior, el grupo AVISPA inicia el proyecto del nuevo Cálculo GraPiCO [2], un cálculo visual para la totalidad del cálculo PiCO, con la utilización de un mecanismo de especificación textual, llamado Gsig (introducido más adelante), y un nuevo mecanismo de traducción denominado T_Gsig, el tema central de éste artículo.

1.1 Estado del arte y al aporte de la investigación

El tratamiento formal de código textual es un tema que ha persistido desde los inicios de la Ciencia de la Computación. Junto con internet y la necesidad de almacenar y manipular la información contenida en ella, se origina lo que ahora llamamos los lenguajes de marcación¹[3]; dentro de los más famosos se encuentran el HTML (Hyper Text Markup Language)[4] para la descripción de páginas web, el OWL (Web Ontology Language)[5] para presentación de ontologías y los esquemas XML para marcado descriptivo (Extensible Markup laguage)[6]. Hasta el momento se han empleado los lenguajes de marcación para tratamiento (ver [7]) y transformación de código textual, como el trabajo en [8]; desde el punto de vista gráfico, también se han usado para representar y traducir hojas de cálculo, como el que se presentó en [9], pero los programas visuales requieren un poder expresivo más grande y una forma eficiente de traducción, pues los costos computacionales de los lenguajes icónicos pueden ser grandes (un ejemplo se muestra en [10]) debido a la complejidad y la extensión del código textual requerido para modelar un programa visual.

El aporte de este documento es proponer una manera de efectuar la traducción de representaciones textuales de código visual de forma general, simple, formal e implementable.

1.2 Introducción a las Gsig (Gramáticas de Sistemas de Íconos Generalizados)

Dentro de los principales problemas que se deben enfrentar al trabajar con lenguajes visuales se encuentra el establecimiento de una especificación gramatical, para así, determinar un mecanismo de traducción a lenguaje objeto y un mecanismo de almacenamiento de código intermedio. En otras palabras, requerimos guardar en algún lugar los programas visuales siguiendo unas reglas sintácticas, para posteriormente, mediante un mecanismo de traducción, obtener un código objeto. En [11] se presenta la forma de especificación gramatical denominada Gsig, la cual consiste en la representación textual de la información visual de un determinado Constructor Simple² o Compuesto³. Ampliando la idea, una Gsig almacena en una expresión textual, la información visual de cada constructor simple X empleando los conceptos de iconos generalizados⁴ presentados en [12] y su respectiva etiqueta, organizados como se presenta en la ecuación 1. Donde T representa la función semántica que nos entrega la especificación del constructor visual X; internamente, esta especificación está delimitada por los símbolos Sd₁ y Sd₂ y está identificada de manera única por el símbolo de encabezamiento S'.

De forma similar, para el caso de la especificación de un constructor compuesto, una Gsig almacena en una expresión textual, la especificación de cada uno de los constructores simples que lo componen y los correspondientes símbolos de sincronización Sc_i, como se muestra en la ecuación 2.

1.3 Introducción al T_Gsig

Con lo anterior, se puede observar que, dado que para la fase de traducción se requiere fundamentalmente la información contenida en la parte lógica -como está construida la gráfica al interior-, la traducción de un programa total o un constructor simple en particular dentro de un programa, especificados a través de Gsig, consiste de la separación de la parte lógica y su posterior traducción interna; de otro lado, la traducción de un constructor compuesto consiste de la traducción de cada uno de los constructores que hacen parte del conjunto. En éste artículo se presenta T_Gsig, un mecanismo de traducción de la especificación de un lenguaje visual utilizando Gsig en un lenguaje textual mediante la técnica de "scanning" (análisis léxico) y no a través de "parsing" (análisis sintáctico) como es presentado en [13], lo cual permite una implementación generalizable mediante el diseno orientado al objeto y más eficiente.

2. DEFINICIÓN DEL MECANISMO DE TRADUCCIÓN

Acorde con la definición de las Gsig, la traducción (expresada mediante T⁵) de un programa generado con una Gsig, hacia uno de constructores netamente textuales, se contempla en los casos siguientes:

Caso 1: Traducción de un constructor simple que se ha expresado mediante una Gsig:

Caso 2: Traducción de un constructor compuesto especificado a través de una Gsig:

Del Caso 1 se obtiene, que la traducción de un programa generado por una Gsig (código fuente), hacia su respectivo código de lenguaje textual (código objeto), consiste de: a) La supresión de la parte física del código fuente, b) La traducción de la parte lógica del código fuente, y c) La transformación de los símbolos de sincronización del código fuente, en los correspondientes símbolos de sincronización del código objeto.

Lo anterior, es consecuente con la estructura de las gramáticas de sistemas de íconos generalizados - Gsig, dado que en la parte física, es donde quedan almacenados los datos visuales sobre la interconexión del respectivo constructor con el resto, y la parte lógica, contiene la definición de la configuración al interior del constructor.

Gracias a las anteriores observaciones sobre el mecanismo de traducción, se define prácticamente la traducción de cada constructor simple generado por una Gsig con la estructura presentada en la ecuación 3 y mediante un objeto con el diseno presentado en la figura 1 a) (Donde Type se refiere al tipo de datos elegido al momento de desarrollar, para almacenar la especificación mediante una Gsig).

Donde Z es la Parte lógica de X ó z_Gsig, y la representación Gsig de X es x_Gsig.

Posterior al diseno del objeto del constructor simple X, se presenta en las figuras 2 y 3 una plantilla para la implementación de la traducción de los constructores simples especificados por una Gsig.

Ya que el mecanismo de traducción presentado supone un código fuente sin errores sintácticos, esto permite una traducción mucho más eficiente, puesto que la búsqueda de los sintagmas⁶ se efectúa mediante la extracción de segmentos de código delimitado por símbolos de sincronización.

De la plantilla presentada en las figuras 2 y 3, se puede observar que la traducción de un constructor simple X, inicia con la creación del objeto x (instancia de la clase X ), la cual activa el método constructor, y éste a su vez, emplea la función separador (particular al componente Z ) para la extracción de la parte lógica de la especificación de X (guardada en x_Gsig ) la cual está delimitada por los símbolos de sincronización : y Sd₂, y su posterior almacenamiento en z_Gsig.

Luego, con la activación del método traductor del objeto x, con la información contenida en z_Gsig se crea otro objeto z (instancia de la clase correspondiente a la parte lógica de X ), y por ende, se activa el constructor de z y su respectivo método traductor. De esta manera, sucesivamente se navega el árbol sintáctico de forma virtual, por medio de la jerarquía de clases. Al final, cuando las diferentes partes lógicas ya están traducidas, se procede a su disposición con la función ordenación, con el fin de obtener un código que se ajuste a las reglas sintácticas del lenguaje textual objeto. La implementación de las funciones separador y ordenación, y el método traductor depende del lenguaje que se está utilizando para realizar la implementación.

De otro lado, por el Caso 2, se tiene que la traducción de un constructor compuesto especificado textualmente utilizando una Gsig, consiste de: a) Traducción de cada constructor X_i que compone el conjunto, b) Transformación de los símbolos de delimitación Sd₁ y Sd₂, c) Transformación de cada símbolo de sincronización Sc_i , y d) Organización de todas las anteriores traducciones.

Dadas las anteriores observaciones sobre el mecanismo de traducción, se define -para su implementación- la traducción de cada constructor compuesto generado por una Gsig con la estructura presentada en la ecuación 4 y mediante un objeto con el diseño presentado en la figura 1 b).

Después del diseño del objeto del constructor compuesto LX, se muestra en las figuras 4 y 5 una plantilla para la implementación de la traducción de los constructores compuestos especificados por una Gsig.

De igual forma que con la plantilla de las figuras 2 y 3, con la plantilla presentada en las figuras 4 y 5 podemos notar que la traducción de un constructor compuesto LX inicia con la creación del objeto lx (instancia de la clase LX ), la cual activa el método constructor, y éste a su vez, emplea la función separador, para la extracción del segmento de código de cada componente X., los cuales están delimitados por sendos símbolos de sincronización Sc_i_₁ y Sc. (cuando i ≠ 1, n) , Sd₁ y Sc₁ (cuando i = 1) , o Sc_n_₁ y Sd₂ (cuando i = n), y su posterior almacenamiento en x_i_Gsig respectivamente. Luego, con la activación de cada método traductor, con la información contenida en cada Xi_Gsig se crea el objeto xi (instancia de la clase correspondiente al componente X_i), y por ende, se activa el constructor de cada Xi. Finalmente, cuando los diferentes componentes ya están traducidos, se procede a su arreglo con la función ordenación, con el fin de obtener un código que se ajuste a las normas sintácticas del lenguaje objeto.

En la próxima sección, se demostrará la validez de la función de traducción T la definición de traducción mediante reglas. Esta lista de reglas, es empleada para transformar un programa GraPiCO especificado utilizando las Gsig, hacia el Cálculo PiCO.

3. DEMOSTRACIÓN DE LA VALIDEZ DE LA FUNCIÓN DE TRADUCCIÓN T EN CONJUNCIÓN CON GraPiCO.

En esta sección se muestra una lista representativa de las reglas de traducción empleadas para transformar programas GraPiCO_Textual en PiCO en conjunción con la función de traducción T [[ ]] para construir una demostración matemática de la validez del proceso de traducción. La especificación gramatical y una explicación del Cálculo GraPiCO, así como la nueva gramática LL(1) del Cálculo PiCO, se encuentran discutidos como un ejemplo de la utilización de las Gsig en [11]).

3.1 Planteamiento recursivo de la función T.

La función T para Epf] (ver figura 6 donde se presenta gráficamente el término Expansión⁷) mostrada en la fórmula 5, se calcula sobre la 4-upla en 6.

La Parte Lógica del constructor X consiste en ε[[Z]], que de ahora en adelante llamaremos Y.

Donde la parte lógica de X corresponde a 7.

De igual forma, la función T para ε[[X]] presentada en la fórmula 8 se calcula sobre la 4-upla presentada en 9.

Luego el planteamiento recursivo de la función T se expresa mediante el diagrama conmutativo de la figura 7:

Dado lo anterior, verificar la validez de T equivale a demostrar el predicado en 10.

Entonces requerimos algún tipo de inducción sobre el conjunto definido en 11.

3.2 Relación binaria > en L(GraPiCO_textuat)

Sea la relación binaria > en L{GraPiCO), >L{GraPicd) X L(GraPiCO), definida en 13 (primero se presenta la definición del conjunto cerradura de la función de expansión en 12).

Posteriormente, verificamos la transitividad de la relación > en 14.

3.3 Lista de reglas de traducción de GraPiCO_Textual en cálculo PiCO.

Para mostrar la traducción de un programa GraPiCO_Textual⁸ hacia PiCO, se emplea una lista de equivalencias, donde cada campo izquierdo está compuesto de un constructor de GraPiCO_Textual, y, el campo derecho se refiere a la correspondiente expresión gramatical equivalente al constructor GraPiCO Textual en términos del cálculo PiCO. A continuación un subconjunto representativo de estas reglas (mostrado en perspectiva en la figura 9 y contextualizado más adelante en la sección 3.4):

1. Traducción de un programa:

■ Traducción de los símbolos de sincronización:

2. Traducción de casos de la parte lógica de un programa (lista de procesos concurrentes): a) Parte lógica de un programa compuesta de varios procesos, b) Parte lógica de un programa compuesta por un único proceso.

3. Traducción de un proceso:

■ Traducción de la condición replicación:

4. Traducción de la parte lógica de un proceso:

Caso particular cuando la parte lógica de un proceso corresponde a un ámbito:

■ Definición de ámbito:

• raducción de los símbolos de sincronización:

Siendo G_v el Grupo de variables y G_n el grupo de nombres.

• Traducción de lista de identificadores (variables, parámetros o nombres):

- Traducción de un identificador (variable, parámetro, nombre o literal de recepción o delegación):

3.4 El preorden (L(GraPiCO), >)

Dibujando la relación > obtenemos el grafo de la figura 9. El cual, en efecto, constituye el Grafo Acíclico Dirigido (desde ahora GDA) para la gramática del cálculo GraPiCO. Con relación a la sección anterior, el conjunto de reglas de traducción presentadas corresponden a la cadena de constructores resaltada en el GDA y sobre la cual se efectúa la demostración. Se tomó este grupo bien ordenado porque conserva las propiedades matemáticas pertinentes y permite la extensión de la demostración al resto de los constructores con generalización.

Consideraciones al preorden

1. Podemos observar, por las reglas de traducción presentadas en la sección 3.3 y por el GDA mostrado en la figura 9, las siguientes deducciones:

■ Para todos los constructores simples tenemos:

• La especificación gramatical del constructor simple X es de la forma:

• X está compuesto por el constructor Y, Y menor que X según la relación >

Para todos los constructores compuestos tenemos:

•La especificación gramatical del constructor compuesto LX es de la forma:

• El constructor compuesto LX está conformado por los constructores ; todo X_i menor que LX según la relación >

2. A través del GDA podemos encontrar un árbol sintáctico (AS en adelante) para cada programa GraPiCO P.. Lo anterior, es expresado simbólicamente en 23.

3. Puesto que todo programa GraPiCO Pi es finito, su respectivo ASi será finito también.

4. Por 1,2 y 3 podemos observar que en un programa GraPiCO no existen sucesiones de constructores infinitas de la formatales que

5. Y, ya que por la ecuación 14 la relación > sobre es L(GraPiCO) es transitiva y por 4 no existen sucesiones infinitas estrictamente decrecientes, tenemos el preorden bien fundado (desde ahora pbf) (L(GraPiCO), >), y podemos emplear el principio de inducción noetheriana en 10 a través de la fórmula 24.

Empleando la ecuación 11 en 24 obtenemos en 25 una expresión más concreta para aplicar la inducción noetheriana.

En la figura 9 podemos observar que Identificador es el único elemento minimal (de hecho es el mínimo) en el GDA de GraPiCO.

Con todo lo anterior, podemos aplicar el principio de inducción noetheriana de la siguiente forma:

■ Base: De mostramos para todos los elementos minimales (en este caso solo identificador) que su traducción es un constructor PiCO.

■ Hipótesis: Dado un X no minimal (para el caso debe ser diferente de identificador, el único minimal) suponemos que la traducción de todos los constructores de los que esté compuesto X son constructores PiCO.

■ Inducción: Bajo la Hipótesis, demostramos que la traducción de la especificación de todo constructor GraPiCO es un código PiCO.

Tenemos que los constructores GraPiCO_Textual son de la siguiente forma:

De la Hipótesis, la respectiva traducción de la especificación de X es de la próxima manera:

Resumiendo las reglas de traducción (presentando únicamente los resultados de la función ordenación, mediante la utilización de las funciones presentadas y la Hipótesis) obtenemos la siguiente lista de constructores.

1. Programa: ProgramaPiCO.

2. Lista de procesos:

3. Proceso: CondiciónReplicaciónPiCO ParteLógicaProcesoPiCO

4. Tipos de procesos:

■ Definición de ámbito: local ListaIdentificadoresPiCO in ProgramaPiCO

• Lista de identificadores:

Podemos observar que todos los resultados, en efecto, son constructores PiCO y cumplen su estructura sintáctica, terminando con esto la demostración.

4. TRADUCTOR DE GraPiCO_Textual HACIA CÁLCULO PiCO

Aplicando el mecanismo introducido se realizó un proyecto[14] en lenguaje Java que tiene como objetivo diseñar e implementar un mecanismo de traducción que tome la especificación textual de un programa, construido a través del cálculo visual GraPiCO, para obtener una representación en cálculo textual PiCO e implementar una etapa de análisis semántico.

4.1 Arquitectura del programa traductor

Teniendo en cuenta que además de la traducción realizada sobre el código GraPiCO_Textual, se está realizando un análisis semántico al código PiCO resultante, se modela el traductor como un proceso de dos etapas principales que constituyen el núcleo del desarrollo, el traductor y el analizador semántico.

4.1.1. Etapa de traducción: Dado un programa en GraPiCO_Textual, se identifica su composición, y cada una de sus partes (constructores) será tratada de manera independiente por medio de un objeto, en otras palabras, se diseñó un objeto por cada constructor de GraPiCO_Textual. Cada objeto fue implementado como una clase, las cuales tienen dos métodos principales:

■ Constructor: Tiene el mismo nombre del constructor GraPiCO. Recibe la expresión en GraPiCO Textual y separa sus componentes, omitiendo las características visuales.

■ Traductor: Lleva a cabo la traducción al Cálculo PiCO de una regla de traducción determinada, utilizando los componentes identificados en el constructor. (ver diagrama de la figura 10).

4.1.2. Etapa de análisis semántico: El código PiCO generado es analizado con el fin de determinar en que momento éste carece de sentido en su estructura, generando mensajes de error o advertencias semánticas. Las acciones semánticas a analizar, se obtienen cuando se traducen elementos de la estructura PiCO. La clase SemanticAnalizer provee métodos que son usados a lo largo del proceso de traducción del código GraPiCO Textual. Los mensajes que se van generando en el proceso, se almacenan en una tabla en memoria. El analizador semántico se basa en el llenado y análisis de tablas Hash.

5. CONCLUSIONES

La T_Gsig es eficiente y es una nueva forma de traducción más ágil porque utiliza el mecanismo de "scarrning" y no de "parsing" para la traducción, como es usual. De otro lado, dado que la presentación práctica de T_Gsig se realizó a través de plantillas de clases, se pudo observar que es aplicable y general.

Desde el punto de vista aplicativo, con el empleo de la T_Gsig se consigue que la navegación virtual del árbol sintáctico mediante la jerarquía de clases, permite la implementación de las fases posteriores del proceso de compilación por medio de la adición de métodos; además, la utilidad de las T_Gsig fue presentada mediante un caso de estudio real, el Cálculo Visual GraPiCO. Y desde el punto de vista teórico, gracias a la presentación y demostración de las propiedades de la T_Gsig con métodos formales, podemos concluir que es una forma de traducción sólida y válida. De la misma forma, ya que las T_Gsig extraen la información visual conservando la textual y también la estructura inicial del programa, encontramos que si existe una Correspondencia Uno a Uno entre las características de los constructores visuales y textuales del lenguaje tratado, el mecanismo de traducción preserva la semántica.

¹ Lenguajes de marcación: es una forma de codificar un documento que, junto con el texto, incorpora etiquetas o marcas que contienen información adicional de la estructura del texto o su presentación. World Wide Web Consortion.

² Conjunto de Constructores Simples.

³ Ícono en particular sin tomar en la cuenta su entorno.

⁴ "representaciones duales de objetos consistentes de una parte lógica (el significado, o lo que es lo mismo, la definición de su estructura interna) y una parte física (información que relaciona los constructores desde el punto de vista netamente visual: localización y los dibujos)". Convergencia de definiciones en [12] y [10].

⁵ En adelante, emplearemos T[[Y]] como la función semántica que recibe una expresión Y (generada por una G_sig) y entrega su traducción en código de un lenguaje textual

⁶ Combinación ordenada de significantes que interactúan formando un todo con sentido, dentro de un conjunto de reglas y convenciones sintácticas.

⁷ Se llamará Expansión a la acción resultante de activar un icono para visualizar su contenido

⁸ Especificación textual de un programa visual GraPiCO siguiendo las Gsig.

Referencias

[1] G. Álvarez, J.F Díaz, L. Quesada, F. Valencia, G. Tamura, C. Rueda and G. Assayag, "Integrating Constraints and concurrent objects in Musical applications: A calculus and its visual languaje", Constraints Journal^ vol. 6, no. 1, pp.21-52, 2001.        [ Links ]

[2] C.A. Tavera y J.F. Díaz, "Nuevo Cálculo Visual GraPiCO: Presentación de sus características fundamentales", Presentado en el 2° Congreso Colombiano de Computación - II CCC, Bogotá, Abril 2007.        [ Links ]

[3] A. Fernández, A. Navarro, B. Fernández y J.L. Sierra, "Lenguajes de Programación, lenguajes de marcado y modelos hipermedia: Una visión interesada de la evolución de los lenguajes informáticos", en Nuevos Géneros Discursivos: Los Textos Electrónicos, C. López-Alonso y A. Séré, Eds. Madrid: Biblioteca Nueva, 2003, pp. 95-113.        [ Links ]

[4] D. Raggett, "Getting started with HTML", World Wide Web Consortion, May 24 2005. Available: http://w3.org/MarkUp/Guide.        [ Links ]

[5] Word Wide Web Consortium,"OWL Web Ontology Language Guide 10 Febrary 2004" in W3C Recommendation, M.K. Smith, C. Welty and D. McGuinness Eds. Available: http://www.w3.org/TR/owl-guide.        [ Links ]

[6] Word Wide Web Consortium, "extensible Markup Language (XML) 1.0", 4th ed. 29 September 2006 in W3C Recommendation, T. Bray, J. Paoli, C.M. Sper-berg-McQueen E. Maler y F. Yergeau Eds., Available: http://www.w3.org/TR/2006/REC-xml-20060816.        [ Links ]

[7] H. Boley, "The Rule Markup Languaje: RDF-XML Data Model, XML schema Hierarchy, and XSL Transformations", presented at International Conference on Applications of Prolog - INAP, Tokyo, October 2001.        [ Links ]

[8] D.Z. Hirtle, "TRANSLATOR: a TRANSlator from LAnguage TO Rules", presented at Canadian Symposium on Text Analysis -CaSTA, Fredericton, October 2006.        [ Links ]

[9] M. Erwig and S. Kollmansberger, "Visual Specifications of Correct Spreadsheets", presented at IEEE Symp. on Visual Languages and Human-Centric Computing, Dallas, TX, USA, September 2005.         [ Links ]

[10] G. Costagliola and G. Polese "Extended positional grammars", Technical Report, Dipatimento di Matematica ed Informatica. University of Salerno, Salerno, Italy, 2001.        [ Links ]

[11] C.A. Tavera y J.F. Díaz, "Alternativa de especificación sintáctica de lenguajes visuales: Gramática de sistemas de iconos generalizados-Gsig", Presentado en el XII Congreso Argentino en Ciencias de la Computación - CACiC, San Luis, Octubre 2006.        [ Links ]

[12] S.K. Chang, Principles of Visual Programming Systems. Upper Saddle River, NJ (USA): Prentice Hall, 1990.        [ Links ]

[13] A. W. Appel, Modern Compiler Implementation in Java, 2^nd ed. New York: Cambridge University Press, 2007.        [ Links ]

[14] J. Noguera y A. Bermúdez, "Diseño e implementación de la traducción desde la especificación textual del Cálculo Visual GraPiCO hacia una representación semánticamente válida en Cálculo PiCO", Proyecto de grado, Escuela de Ingeniería de Sistemas y Computación, Universidad del Valle, Septiembre 2005.        [ Links ]