docambitos de aplicación de los lenguajes formales con antlr
download 
Demanda Transcripción
ambitos de aplicación de los lenguajes formales con antlr
AMBITOS DE APLICACIÓN DE LOS LENGUAJES FORMALES CON ANTLR APPLICATION SCOPES OF THE FORMAL LANGUAGES WITH ANTLR Jonathan Aranda C.1 Exequiel Fuentes F. 2 Eric Jeltsch F.3 Felipe Lucero X. 4 RESUMEN Se presenta una secuencia de actividades realizadas en el marco de la formación y del ejercicio del Ingeniero en Computación de la ULS. Todas ellas, son implementadas en ANTLR (ANother Tool for Language Recognition), y editadas con ANTLRWorks. La primera corresponde a la construcción de una aplicación básica de un DSL externo, la segunda es la implementación de un editor e intérprete de consulta en modo texto para el lenguaje SNQL 2.0, para finalmente definir una gramática reducida para SQL, en términos de implementar las reglas para SELECT, FROM, WHERE y LIMIT en el ámbito del lenguaje Astronomical Data Query Language (ADQL). En el proceso de desarrollo de las actividades se comprobó el potencial y efectividad de las herramientas en el contexto de los analizadores lexicográficos y sintácticos. Finalmente, se puede concluir que el uso, manejo e incorporación de este tipo de herramientas es recomendable, oportuna y factible de incluir en un curso de gramáticas y lenguajes formales para estudiantes de pregrado en Ingeniería en Computación. Palabras clave: antlr; dsl; lenguajes formales. ABSTRACT We present an activity sequences in the context of training and performance of a Software Engineer of ULS. All of them are implemented in ANTLR (ANother Tool for Language Recognition) and edited with ANTLRWorks. The first one is a construction of a basic application of an external DSL, the second implementation is a query interpreter and editor on text mode for the language SNQL 2.0, and the last one defines a reduced grammar for SQL, which implements a set the rules for SELECT, FROM, WHERE and LIMIT based on the Astronomical Data Query Language (ADQL). In the development process, we have able to see the potential and effectiveness of the tools in the context of lexical and syntactic analyzer. Finally, we can conclude that using, handling and incorporating these tools in grammars and formal languages course for undergraduate students of Software Engineering career is totally recommended, appropriate and feasible. Keywords: antlr, dsl, formal languages. INTRODUCCIÓN La presente propuesta se inserta dentro de las actividades docentes regulares en la formación y en el ejercicio de la profesión como Ingeniero en Computación de la ULS, cuya carrera tiene una duración de 5 años (10 Semestres, 10º Niveles). En particular, la asignatura Electivo (Teórico-Práctico, 4 horas, 5º Año, 9º Nivel), es una de las asignaturas que cumple con el objetivo de que el alumno clarifique y refuerce algunos conceptos “extra curriculares”, los que basados en los insumos teóricos y prácticos permitan proponer algún tema de Memoria de Título (MT). En esta oportunidad, los conceptos extra curriculares están en el estudio de los DSL (DomainSpecific Languages), [9], junto con la aplicación y manejo de las herramientas ANTLR (ANother Tool for Language Recognition) [7], y ANTLRWorks [8]. En términos curriculares, el curso Electivo pretende entregar las 1 herramientas para implementar intérpretes, filtros, analizadores, transformación de formatos, entre otros. Por otro lado, las competencias que se pretenden alcanzar es poner en operación los diferentes conocimientos, habilidades, carácter y valores de manera integral en las diferentes interacciones en donde a los alumnos les toque actuar, ya sea en el ámbito personal, social y laboral. Los conocimientos y habilidades se sustentan en la asignatura de Teoría de Autómatas y Lenguajes Formales (TeóricoPráctico, 4 horas, 4º Año, 7º Nivel), la cual es abordada con una estructura y herramientas clásicas, tales como, Lex/Yacc, Flex/Bison, en el entorno del lenguaje C, y JLex/CUP en el entorno Java, y cuyo objetivo es el dotar al alumno de las competencias y habilidades básicas para la descripción sistemática de lenguajes formales y el desarrollo sistemático de intérpretes, filtros y transformaciones en los lenguajes formales según la jerarquía de Chomsky, y el uso de técnicas estándares que Escuela Ingeniería en Computación. Universidad de La Serena / Cisternas 1200. La Serena, Chile. [email protected] Observatorio Interamericano Cerro Tololo / Colina El Pino s/n. La Serena, Chile. [email protected] 3 Departamento de Matemáticas. Universidad de La Serena / Cisternas 1200. La Serena, Chile. [email protected] 4 Escuela Ingeniería en Computación. Universidad de La Serena / Cisternas 1200. La Serena, Chile. [email protected] 2 se ponen en práctica en los Laboratorios. Al mismo tiempo, los Laboratorios se sustentan en la asignatura de Programación Orientada a Objeto (Teórico-Práctico, 4 horas, 2º Año, 4º Nivel) y Diseño y Análisis de Algoritmos (Teórico-Práctico, 4 horas, 3º Año, 5º Nivel), en donde las actividades prácticas se enfocan al uso intensivo de las librerías, Generic, Collections y Swing de Java. Cabe hacer notar que todas estas asignaturas de la carrera procuran cumplir con las recomendaciones de la ACM/IEEE-CS Curriculum Joint Task-Force, [19] y referentes universales, en el sentido de que las materias y conocimientos entregados se encuadran dentro del área del conocimiento respectivo (Software Engineering). Dicho lo anterior, la asignatura Electivo está dentro del ámbito de los Lenguajes de Programación (PL), tales como, (PL3. Introducción a la traducción de lenguajes) y (PL8. Sistemas de traducción de lenguajes). En términos pedagógicos se puede afirmar que la incorporación de los DSL en el Electivo hizo posible que los alumnos pudieran reforzar y actualizar los saberes y habilidades para enfrentarse a las expectativas y objetivos que sustentan el perfil profesional del Ingeniero en Computación de la ULS. Como una muestra de ello, es que la propuesta considera tres experiencias, pero en diferentes escenarios. En la primera se crea e implementa un DSL externo clásico, que incorpora la programación orientada a objeto y el uso de la arquitectura Modelo-Vista-Controlador, todo ello realizado por un alumno regular de la carrera que cursa la asignatura Electivo. La segunda experiencia implementa un editor e intérprete de consultas en modo texto para el lenguaje de consultas SNQL2.0, el que pertenece al modulo QE del sistema SNDM, siendo este último una herramienta para el análisis de redes sociales y Web Semántica, todo ello, en el contexto del desarrollo de una memoria de título para optar al título de Ingeniero en Computación. Mientras que la tercera y última experiencia describe la creación e implementación de algunas reglas para SSQL (S(hort)SQL), en particular para SELECT, FROM, WHERE y LIMIT, esta vez para Ruby, en el ámbito del quehacer profesional del Ingeniero en Computación, en este caso, como funcionario del Cerro Tololo Inter-American Observatory. El denominador común de todas estas experiencias se centran en que como alumnos, todos ellos han cursado la asignatura Electivo, cuyos contenidos han sido el estudio de los DSL y la aplicación de herramientas de código abierto, tales como, ANTLR y ANTLRWorks. Con la realización de estas actividades y el monitoreo o control de ellas durante el semestre, fue posible constatar lo exitoso que resultó en cada una de las actividades al aplicar los DSL y herramientas afines, tales como ANTLR, quien juega un rol importante en el desarrollo y producción de esta propuesta. FUNDAMENTOS En INFONOR 2012 [14], ya se presentan algunas experiencias básicas, insumos y actividades que fundamentan la actual propuesta, de ahí que no se aborde la temática del uso o aplicaciones de ANTLR. Los contenidos de la asignatura Electivo se fundamentaron en la importancia y dinámica de los procesadores de lenguajes, el ámbito y alcances de los DSL, sumada a la importancia de filtrar, administrar, buscar, categorizar y recuperar datos en el ámbito de la Web Semántica y de la Astronomía, entre otros, lo que ha posibilitado que la temática abordada en el Electivo sea oportuna y factible de realizar para la incorporación al mundo laboral y el ejercicio de la profesión de los alumnos de la carrera de Ingeniería en Computación de la ULS. La importancia de los DSL radica en que son lenguajes de programación que están diseñados para utilizarse en dominios o problemas específicos, a diferencia de los lenguajes de programación de propósito general (Java, C, C++ u otros). Martin Fowler y Debasish Ghosh hacen una introducción y clasificación muy interesante de los mismos en [10, 11]. En general, son numerosos los proyectos en donde ANTLR ha intervenido, entre ellos, Apache Camel, Apache Lucene, Groovy, Hibernate. Por ejemplo, Hibernate usa ANTLR para el parser en el lenguaje de consulta HQL, EJB-QL y Criteria Query. En Drools (Business Logic Integration Platform), uno de los productos más importantes en la plataforma JBoss-SOA es el lenguaje DRL, el cual relaciona reglas de negocio definidas a alto nivel dentro de un motor de procesos. Es decir, una cantidad importante de proyectos han visto lo apropiado de usar los DSL en pequeñas aplicaciones y la importancia que le cabe a ANTLR en este aspecto. Todo ello, sirvió como inspiración para proponer los contenidos de este Electivo que se viene dictando desde hace 3 años. EXPERIENCIAS DOCENTE Experiencia 1: Una de las propiedades más comunes del lenguaje de programación Logo es poder producir “gráficos tortuga”, es decir, entregar instrucciones a una tortuga virtual, la que mediante un cursor gráfico puede describir algunas trayectorias y con ello generar algunas figuras o patrones. Un ejemplo típico de trayectoria para una tortuga virtual es, forward 100 (camina hacia delante 100 pasos) turnright 90 (se gira hacia la derecha 90º) turnleft 30 (se gira hacia la izquierda 30º) En esta versión se propone Tortuga2 que permite controlar el movimiento de una tortuga (cursor) que se mueve en un plano cartesiano, al tiempo que va dibujando con un lápiz. Lo novedoso de Tortuga2 es la forma de reconocer los patrones (lexer y parser), los que han sido implementados con la herramienta ANTLR (versión antlr-3.4-complete) y antlrworks-1.4.3), mientras ANTLRWorks, (versión que la interfaz gráfica de usuario o GUI, (Graphical User Interface) ha sido implementada con los componentes Swing de Java, y la plataforma org.eclipse.ltk.core.refactoring. Por lo tanto, Tortuga2 es una aplicación multiplataforma. Tortuga2 ha sido implementada y puesta a prueba con la versión 1.6 (update 22) de la máquina virtual de Java (JRE), y debería funcionar de forma correcta con cualquier versión posterior. A continuación se muestran las formas de iniciar la aplicación, ya sea, (con o sin) archivo de instrucción, o línea de comando. Además, se muestra el formato de los archivos utilizado, el diseño de la aplicación y la gramática según la especificación ANTLR, para finalmente mostrar una descripción de la aplicación. Inicio: Se inicia la aplicación, ya sea: 1. Sin archivo de instrucción: Para iniciar Tortuga2, hacer doble click sobre el icono llamado Tortuga2.jar. La máquina virtual de Java cargará la aplicación y mostrará la pantalla principal. 2. Con archivo de instrucción: Para iniciar Tortuga2 con un archivo de instrucción, arrastre el archivo en cuestión sobre el icono llamado Tortuga2.jar y suéltelo. La máquina virtual de Java cargará la aplicación y mostrará la pantalla principal. La aplicación entonces comenzará a leer y ejecutar las instrucciones que contiene el archivo inmediatamente. 3. Desde la línea de comandos: Si por alguna razón no puede iniciar la aplicación desde la interfaz gráfica de su sistema, puede hacerlo mediante la línea de comandos. Para el caso: a) Sin archivo de instrucciones, Ejemplo: A continuación se muestra en archivo y el contenido de las instrucciones: cuadrado.txt ad 100 de 90 ad 100 de 90 ad 100 de 90 ad 100 de 90 En cuadrado.txt, podemos observar que la instrucción dada en la primera línea (ad 100) indica a la tortuga virtual realizar un movimiento hacia adelante de 100 pasos. En el contexto clásico sería (forward 100), seguido de un giro a la derecha de 90º grados (turnright 90). Tras lo cual, se repiten tres veces más, logrando dibujar así un cuadrado sobre el lienzo. Diseño: Tortuga2 está compuesto por tres módulos: a) Procesador, b) Intérprete, c) Interfaz Gráfica de Usuario (TortugaGUI). La relación entre los módulos y componentes mencionados puede observarse en el siguiente diagrama de la Figura 2: > java -jar Tortuga2.jar b) Con archivo de instrucciones, > java -jar Tortuga2.jar “instrucciones.txt”. Formato de archivos: Cabe hacer notar que cada archivo de instrucciones es de texto plano y está formado por una o varias instrucciones. Figura 2. Relación entre los módulos y componentes que interactúan en Tortuga2. Figura 1. Instrucción, Parámetros, Acción y Ejemplo para los archivos “instrucciones.txt”. a) El Procesador carga el archivo de instrucciones, el cual es entregado al Intérprete para ser ejecutado. Si no se ha especificado un archivo de instrucciones, el Procesador entrega al intérprete el equivalente a un archivo de instrucciones vacío. El Procesador además mantiene una instancia de la clase Tortuga, la cual es la encargada de mantener el estado de la tortuga y traducir las instrucciones provenientes del Intérprete y del panel de control para ser dibujadas sobre el lienzo de la interfaz gráfica. b) El Intérprete recibe el archivo de instrucciones cargado por el procesador y, mediante el Runtime de ANTLR, interpreta las instrucciones y se las entrega a la clase Tortuga en el procesador. c) La Interfaz de Gráfica de Usuario consta de un lienzo (PaintPanel), sobre el cual dibuja la Tortuga, y un panel de control (PadPanel) que envía instrucciones de dibujo a la Tortuga. Notar que el panel de control nunca interactúa directamente con el lienzo, si no que envía instrucciones a la Tortuga para que esta realice el dibujo. Gramática: Respecto a la gramática de Tortuga2, esta se ha desarrollada según las especificaciones ANTLR. Siguiendo el estilo de trabajo de ANTLR, la gramática se encuentra separada en un archivo de tokens y un archivo de producciones, ambos archivos son usados por ANTLR para generar los componentes Lexer y Parser del módulo Intérprete. El archivo de tokens de ANTLR TorLexer.g es el siguiente: lexer grammar TorLexer; @lexer::header { package flu0.Tortuga; } FW : 'ad'; BW : 'at'; RT : 'de'; LT : 'iz'; PEN : 'conlapiz'; NOPEN : 'sinlapiz'; GOTO : 'ir'; NUM : '0'..'9'+; NEWLINE : '\r'? '\n'; WS : (' '|'\t')+ { skip(); }; Mientras que el archivo de producciones TorParser.g es el siguiente (la producción de inicio es draw): parser grammar TorParser; options { tokenVocab = TorLexer; } @header { package flu0.Tortuga; } @members { private Tortuga tortuga = new Tortuga(); } draw : (instruc+ EOF | EOF);//regla de inicio instruc : line (NEWLINE | EOF); line : (move | turn | pen); move : (fw | bw | gotoxy); turn : (rt | lt); fw : FW NUM { tortuga.forward(Integer.parseInt($NUM.text)); };//acciones asociada a la regla fw. bw : BW NUM { tortuga.backward(Integer.parseInt($NUM.text)); }; rt : RT NUM { tortuga.rightTurn(Integer.parseInt($NUM.text)); }; lt : LT NUM { tortuga.leftTurn(Integer.parseInt($NUM.text)); }; pen : ( PEN { tortuga.pen(true); } | NOPEN { tortuga.pen(false); } ); gotoxy : GOTO x=NUM y=NUM { tortuga.gotoxy( Integer.parseInt($x.text), Integer.parseInt($y.text) );//acciones asociada al lápiz. }; Descripción de la aplicación: La descripción se basa en Figura 3 en donde se ejecuta la aplicación Tortuga2, y se ha incluido el archivo de instrucciones cuadrado.txt. Figura 3. Inicio de la Aplicación Tortuga2. La sección izquierda de la pantalla (a) es el lienzo sobre el cual la tortuga dibuja. La sección derecha (b) es el panel de control, el que está dividido en 3 áreas: 1. Estado de la tortuga: Esta área indica el estado de la tortuga. Se muestra la posición de la tortuga en el lienzo, considerando la posición de origen (0,0) como la esquina superior izquierda del lienzo, así como el ángulo en que la tortuga se orienta, siendo medido desde la horizontal en sentido anti-horario. En este caso, la Posición es: x: 249, y:249, y con ángulo 90º. 2. Control de movimiento: Esta área permite controlar la tortuga cuando se ha iniciado Tortuga2 sin un archivo de instrucciones, o bien cuando ya se han procesado todas las instrucciones del archivo: i. Los botones Adelante y Atrás permiten mover la tortuga en la dirección (ángulo, 90º) indicado por el estado de la tortuga, y en la cantidad de pasos ii. iii. iv. (píxeles, 10) indicada en el campo que se encuentra entre ambos botones. Los botones Izquierda y Derecha cambian el sentido de la tortuga, girándola en la dirección correspondiente en la cantidad de grados indicada en el campo que se encuentra entre ambos botones. En nuestro ejemplo, 10. El botón Lápiz controla e indica si la tortuga dibujará su trayecto al moverse, o si se moverá sin dejar rastro sobre el lienzo. El botón Reset limpia completamente el lienzo y ubica a la tortuga por defecto en el centro del lienzo en dirección de 90 grados (“mirando hacia arriba”). 3. Consola: Permite visualizar las instrucciones y los movimientos que va realizando la tortuga, ya sean los definidos en el archivo de instrucciones o los realizados por el usuario sobre el panel de control. La consola puede limpiarse utilizando el botón Limpiar. Experiencia 2: Las redes sociales son muy importantes dentro de las actividades cotidianas de la sociedad, tales como, publicar algún acontecimiento o intereses, sean estos, hobbies, ocio, diversión, noticias, etc. Algunos ejemplos de redes sociales son: MySpace, Facebook, Twitter, Hi5, LiveJournal, Friendster, entre otros. En este ámbito Internet ha jugado un rol importante en el aumento considerable de la cantidad de datos viajando desde un punto a otro. En esta segunda experiencia, el ámbito se relaciona con la implementación de un editor e intérprete de consulta en modo texto para el lenguaje SNQL 2.0 (Social Networks Query Language), el cual es un subconjunto del Sistema SNDM (Social Networks Data Model), [12]. Para fijar conceptos, SNQL corresponde al conjunto de consultas y transformaciones para el lenguaje SNDM. En general, SNDM es un modelo de base de dato para el manejo y administración de los datos correspondientes a redes sociales, mientras que SNQL, proporciona una estructura de dato para representar y almacenar redes sociales, y un lenguaje para consulta y transformaciones en el ámbito de las redes sociales, cuyo análisis y administración es un interesante problema por el volumen de datos y por el factor de cambio que tienen los datos. En este contexto, es que se implementó el sistema SNDMS, (proyecto realizado hace un tiempo atrás por alumnos de la Carrera de Ingeniería en Computación de la Universidad de La Serena, [13]), que permite analizar y administrar redes sociales. La problemática actual es entonces actualizar la gramática SNQL a la versión SNQL 2.0. Para ello, se debió actualizar el intérprete para SNQL 2.0. La metodología usada es “dividir para conquistar”, cuyos subproblemas son: a) parser Patrón Simple, b) parser Consulta SNQL 2.0, c) editor y parser de consultas en modo texto para SNQL 2.0, d) Integración del módulo QE al sistema SNDMS. El primer subproyecto fue implementar un parser para poder compilar un patrón simple, que representa un elemento de la red social. Se implementa el parser del patrón simple utilizando ANTLR en el IDE Eclipse. Una consulta SNQL sigue el estándar: CONSTRUCT– WHERE– FROM. - FROM: identifica la o las redes de origen. - WHERE: Incluye los patrones de extracción que identifican las partes de la red de origen que son relevantes para la consulta. - CONSTRUCT: define los patrones que serán construidos como parte del resultado utilizando la información recogida por los patrones de extracción. Ejemplo: La consulta CONSTRUCT PC1 WHERE PE1 AND PE2 FROM RedFotos, RedColegios, está realizada en SNQL 2.0 y está constituida por los patrones de Extracción PE1, PE2 y por el patrón de Construcción PC1. AND Figura 4. PE1 y PE2, corresponden al patrón de extracción, mientras que PC1 corresponde al patrón de construcción, y el conectivo AND que los asocia. La gramática ANTLR propuesta es sólo un extracto de la original, pues se pretende resaltar los elementos que intervienen en el ejemplo. lexerConsultaSNQL20.g Análisis Léxico class Alex extends Lexer; CONSTRUCT : "CONSTRUCT"; CONSTRUCT SELECT : "SELECT"; WHERE : "WHERE"; WHERE FROM : "FROM"; FROM PATRON: "P"('A'..'Z')+('0'..'9'); PC1 PE1 PE2 FILTER: "FILTER"; SOCIALNETWORK : ('A'..'Z')('a'..'z')+; RedFotos RedColegios AND: "AND"; AND Análisis Sintáctico CONSTRUCT <T> WHERE <PATT> FROM <S> <T>::= <construct-patt>[ AS <sn-id>[,<constructpatt> AS <sn-id>]*] <construct-patt> ::= <list-of-pattern-triples> [IF <list-of-equalities>] <list-of-equalities> ::= <expr> = <expr> [AND <expr> = <expr>]* <expr> ::= <variable> | <constant> | <function>(<expr>[, <expr> ]*) <list-of-pattern-triples> ::= {<pattern-triple> [, (<pattern-triple>)]*} <pattern-triple> ::= (term, term, term) <term> ::= <variable> | <constant> | <expr> AS .. . <start-condition> | AGG(<group-vars>,<aggr-func>,<extract-patt>) <list-of-pattern-triples> ::= {<pattern-triple> [, (<pattern-triple>)]*} <pattern-triple> ::= (term, term, term) <condition> ::= <logic-expression> <term> ::= <variable> | <constant> | <expr> AS <alias> <expr> ::= <variable> | <constant> | <function>(<expr>[, <expr> ]*) <alias> ::= <variable> | <null> <list-of-social-networks> ::= <social-network>[ AS <sn-id> [, <social-network> AS <sn-id>]*] <social-network> ::= <sn-id> ($R1,”isr”, “friendship”). Mientras que en c) se aprecian los mensajes de error tras la compilación. Este proceso de visualización del error se logra interviniendo directamente el código que genera ANTLR para la gramática, permitiendo tener un acceso a la administración de éste. Para poder administrar y/o gestionar el error se debe intervenir el archivo asint.java (una vez que ANTLR lo haya generado) para ingresarle las estructuras de datos y procedimientos para la administración del error. Esto se debe realizar cada vez que se compile la gramática desde Eclipse, por lo que se recomienda intervenir el archivo una vez terminada la compilación de la gramática y que ésta no posea ningún error. a) b) A continuación, se muestra la aplicación de la gramática al ejemplo antes dado. El análisis léxico para los tokens CONSTRUCT, WHERE, FROM, PE1, PE2, PC, RedFotos, RedColegios que posee la consulta SNQL 2.0 se muestra como sigue: c) <construct-patt> Æ <list-of-pattern-triples> Æ {<pattern-triple> [, (<pattern-triple>)]*} Æ <pattern-triple> Æ PC1 Æ (term, term, term) <patt> Æ <extract-patt> AND <extract-patt> Æ <PE1> AND <PE2> Æ (term, term, term) AND (term, term, term) <list-of-social-networks> Æ <social-network>[ AS <sn-id> [, <social-network> AS <sn-id>]*] Æ <socialnetwork> Æ RedFotos, RedColegios. Una vez terminada la compilación de la consulta SNQL2.0 y si esta compilación no posee errores se procede a crear una representación interna la cual será utilizada por el Sistema SNDMS para mostrar el resultado. Cabe mencionar que otro aporte en esta propuesta es la integración de la visualización del error por pantalla, dándole al usuario la opción de corregir los errores que pueda tener al crear, insertar, editar una consulta SNQL 2.0. En la Figura 5 se aprecian las fases en el proceso de gestión de los errores. Estos son: a) fase de compilación, en donde se le da el patrón de la consulta, en este caso, CONSTRUCT PC1 WHERE PE2 FROM Friendship. En b) se ven los integrantes del patrón básico, esto es, ($A1,”isa”, “person”), ($A2,”isa”, “city”), Figura 5. a) módulo de compilar, b) Visualización del patrón, c) Resultado de la compilación. Experiencia 3: La Astronomía en Chile posee el 40% de la observación astronómica del mundo, con la expectativa de llegar a casi el 60%, la que se ha estado desarrollando en la zona del Norte Grande, en particular la IV Región de Coquimbo que posee una serie de condiciones climáticas privilegiadas para el estudio, [16]. Ahora, la relación entre la Astronomía y los DSL, surge con el proyecto ADQL (Astronomical Dataset Query Language) [1], que es como SQL (Structured Query Language), el cual otorga las facilidades para consultar a una base de datos astronómicos. Este lenguaje ha sido definido por IVOA (International Virtual Observatory Alliance) [2]. Por otra parte, con la librería pgSphere [5] es posible de incluir acciones en las reglas de la gramática ADQL, entre ellas, tipos de datos esféricos, funciones y operadores para PostgreSQL. En esta tercera y última actividad el ámbito de aplicación se relaciona con la intervención del lenguaje ADQL, cuyo desarrollo está basado sobre SQL92. Para fijar el contexto de la actividad, la astronomía ha visto un crecimiento exponencial en la cantidad de datos capturados por los más modernos instrumentos. Actualmente, las cantidades que se manejan son terabytes e incluso petabytes de datos por noche de observación en los centros más modernos del mundo, tales como Kitt Peak National Observatory (KPNO) [3, 18], Cerro Tololo Inter-American Observatory (CTIO) y algunos consorcios como WIYN, SOAR y SMARTS, con el fin de procesarlos de manera inteligente para generar información de calidad, útil para astrónomos y comunidad en general. Y es en este contexto que se plantean interrogantes como por ejemplo, ¿Cómo asignar algoritmos para clasificar fenómenos que se descubren en las observaciones?, ¿Cómo asignar algoritmos de seguimiento a asteroides o cometas, o para seguir el propio movimiento de las estrellas?. o la clasificación de taxonomías y ontologías astronómicos, minería de datos, aprendizaje automático y visualización, entre otros. Estos son algunos ejemplos y temáticas que considera la Astroinformática para enfrentar una gran diversidad de problemas en los proyectos astronómicos, [15]. En particular, uno de los objetivos de esta actividad es proporcionar acceso a los datos almacenados, así como, realizar una consulta ADQL y obtener una respuesta a esa consulta. Una consulta ADQL puede ser como por ejemplo, seleccionar las primeras 100 filas dentro de las coordenadas ecuatoriales ra(10.352, 11.017) y dec (41.019, 41.519), coordenadas del sistema FK5 [17]. Figura 6. Un ejemplo del listado usado por los telescopios de Kitt Peak. El FK es una serie de seis catálogos astronómicos (FK5 es una de ellas) de datos de alta precisión posicional de una pequeña selección de estrellas que definen el marco de referencia celestial de éstas, el cual es básicamente un sistema estándar de coordenadas celestes, según se aprecia en Figura 6. /* se usan 2 columnas de la tabla "voi.sap": "ra" y "dec".*/ SELECT * FROM voi.siap WHERE ((ra >= 10.352 AND ra <= 11.017) AND (dec >= 41.019 AND dec <= 41.519)) LIMIT 100 Dado que el servicio de ADQL está abierto al mundo, se debe procurar que la consulta ingresada sea válida para señalar algún error de sintaxis y también disminuir o eliminar posibles ataques a través de inyección SQL, [4]. Por lo tanto, debemos verificar la sintaxis de la consulta y en caso de error indicar donde este ocurre. Finalmente, si la consulta es válida, entonces debe ser traducida a SQL entendible por nuestra base de datos Postgres aplicando funciones geométricas definidas en la librería PgSphere. PgSphere proporciona tipos de datos esféricoa, funciones, y operadores para PostgreSQL. Se ha usado ANTLR, pues proporciona un marco para construir un apropiado reconocedor para ADQL y así definir una gramática que llamamos SSQL S(hort)SQL para verificar la consulta ingresada por el usuario. Esta gramática incluye reglas comunes para SQL y algunas específicas para nuestra implementación. No se implementa la especificación completa de ADQL ya que sólo requerimos unas cuantas funciones. A continuación se muestra una parte de la gramática, y las reglas comunes para SSQL: // S(hort)SQL Grammar grammar SSQL; options { ASTLabelType = CommonTree ; language = Ruby ; memoize = true ; output = AST ; backtrack = true ; } // Palabras reservadas tokens { ALL ; AND ; .. DISTINCT ; .. //math CEILING ; DEGREES ; ..; //trig SIN ; COS ; ..; //aggregate MAX ; MIN ; SUM ; AVG ; COUNT ; // pgsphere SBOX ; } // algunas reglas statement : select_statement (SEMICOLON)? EOF ; select_statement : query_expression ; query_expression : sub_query_expression sub_query_expression : query_specification | LPAREN query_expression RPAREN ; query_specification : select_clause (from_clause)? (where_clause)? (group_by_clause)? (having_clause)? (order_by_clause)? (limit_clause)? (offset_clause)? ; select_clause scope { all_or_distinct; selection_list; } Con estas reglas básicas, la gramática es capaz de verificar consultas tales como, seleccionar las primeras 100 filas ordenadas por fecha de lanzamiento para coordenadas ecuatoriales específicas, para un determinado telescopio e instrumento y para el astrónomo “fuentes”: SELECT * FROM voi.siap WHERE (((ra >= 10.353 AND ra <= 11.017) AND (dec >= 41.019 AND dec <= 41.519)) AND dtpi ILIKE '%fuentes%' AND (proctype = 'Raw')) AND ((telescope = 'ct4m' AND instrument = 'decam')) ORDER BY release_date LIMIT 100 Una función de interés es la que expresa una caja (“box”). Un “box” es un caso especial de Polygon, que corresponde semánticamente a STC Box, [6]. Un ejemplo clásico de la selección de un punto con coordenadas en la caja de rango entre -10° y +10° de latitud 350° y 10° en longitud, respectivamente. SELECT sbox '( (350d,-10d), (10d,+10d) )'; A continuación se muestra la regla para la función SBOX: sbox_condition : SBOX SQUOTELPAREN spherical_coor SQUOTERPAREN spherical_index ; spherical_coor : spherical_point COMMA spherical_point ; spherical_point : LPAREN number COMMA number RPAREN | LPAREN number 'd' COMMA number 'd' RPAREN ; spherical_index : TILDE identifier ; Con estas reglas, la gramática puede reconocer una consulta tal como, seleccionar las primeras 100 filas para el espacio determinado por la caja con coordenadas específicas: SELECT * FROM voi.siap WHERE sbox '((17.0d,89.9d),(59.9d,0.0d))' ~ fk5coords Sin embargo, es posible considerar algunos otros sistemas, entre ellos, el estándar ICRS (International Celestial Reference System) adoptado por la IAU (International Astronomical Union). La siguiente consulta expresa un box de 10º centrada en la posición en grados (25.4, definida de acuerdo al sistema de ICRS con la posición referenciada -20.0) coordenadas GEOCENTER: SBOX(‘ICRS GEOCENTER’, 25.4, -20.0, 10, 10). Durante el proceso de reconocimiento, la gramática genera adicionalmente una serie de objetos por cada cláusula, por lo tanto se puede inyectar una serie de verificaciones o reglas programáticamente, como por ejemplo, verificar si una columna existe o si una condición en particular fue agregada o restringir la cantidad de filas en la respuesta, esto es agregando un rango al límite. Todas estas posibilidades pueden ser configurables, de esta manera se otorga una mayor flexibilidad a la gramática. Adicionalmente, si ocurre algún error durante el reconocimiento, éste debe ser alertado dando una descripción clara del error y la posición de este. Por ejemplo, la siguiente regla que reconoce una columna desde la cláusula SELECT, y crea un nuevo objeto que representa a esa columna. La clase verificará la consistencia con la base de datos. Si la columna existe entonces la gramática continuará con el reconocimiento, de lo contrario parará en esta línea. (column) => column { $select_item::selection_item = VORuby::SQL::AliasSelectionItem.new($select_item ::column_str, @alias_global); } También, se puede verificar la existencia de una columna requerida, ya sea porque es utilizada en las condiciones de la consulta o esta puede ser utilizada para calcular ciertos valores después de obtener la respuesta. Por ejemplo, si un astrónomo quiere obtener todas sus observaciones realizadas la noche anterior, entonces, las columnas que identifica al astrónomo y la fecha de observación deben estar presentes en la consulta: SELECT reference, release_date, start_date, date_obs, dtpi, ra, dec, telescope, instrument FROM voi.siap WHERE date_obs = '2013-05-14' AND dtpi ILIKE '%fuentes%' LIMIT 10000 Finalmente, si el reconocimiento es terminado satisfactoriamente, entonces la consulta es ejecutada en la base de datos. Traducir ADQL a SQL depende totalmente de la base de datos que se esté utilizando y también como se manejan las funciones geométricas. Este es el motivo por lo que se debe implementar el traductor dependiendo de los requerimientos propios de cada sistema. Para terminar, cada base de datos maneja la información geométrica de diferente forma. Por otro lado PgSphere [5] proporciona una excelente implementación para las funciones geométricas definidas en ADQL. CONCLUSIONES Este trabajo ha permitido constatar que en estos tres ámbitos, los que en primer momento pudiesen parecer tan disímiles, pero en rigor desde el punto de vista del estudio y creación de lenguajes específicos como los DSL y el uso de la herramienta ANTLR en la implementación de gramáticas, analizadores léxicos y sintácticos son muy cercanos y coincidentes. La propuesta muestra que siempre existe la posibilidad de “reencantar” a los alumnos de pregrado en temas tan teóricos y/o clásicos como son los lenguajes formales, con la incorporación de conocer y resolver problemas reales, como fue en estos 3 casos. La ventaja de esta propuesta, vista en estos tres aspectos, es decir, desde alumno regular, memorista y profesional, nos muestra que nuestros egresados pueden incorporarse al ámbito laboral con las capacidades para proponer soluciones. Desde el punto de vista de los aprendizajes, se puede afirmar que los estudiantes, egresados y titulados pudieron revisar y recrear los conceptos y especificaciones de las gramáticas según la jerarquía Chomsky en un contexto más aplicado, como es el que se propone. Respecto a los DSL, bien podemos afirmar que un usuario familiarizado con el dominio del lenguaje en algún contexto puede obtener mejores y más rápidos resultados utilizando una semántica de dominio conocida. Por todo lo anterior se hace necesario, oportuno y factible el promover y recomendar el estudio de los DSL, manejo de herramientas, tales como ANTLR y otros similares, en una carrera de pregrado. AGRADECIMENTOS Se agradece a Dr. Mauro San Martin, por la participación como profesor guía en la memoria de título que dio origen a un segmento de este trabajo, (experiencia 2). REFERENCIAS [1] Inaki Ortiz, Jeff Lusted, Pat Dowler, Alex ander Szalay, Yuji Shirasaki, Maria A. Nieto-Santisteban, Masatoshi Ohishi, William O’Mullane, Pedro Osuna, the VOQL-TEG and the VOQL Working Group. IVOA Astronomical Data Query Language, Version 2.0, IVOA Recommendation 30 Oct 2008. http://www.ivoa.net/documents/REC/ADQL/ADQL20081030.pdf. Fecha de Consulta, 30 Junio 2013. [2] IVOA Astronomical Data Query Language: http://www.ivoa.net/documents/latest/ADQL.html. Fecha Consulta: 30 Junio 2013. [3] NOAO Data Archives: http://ast.noao.edu/data/archives. Fecha Consulta: 30 Junio 2013. [4] Inyección SQL: http://en.wikipedia.org/wiki/SQL_injection. Fecha Consulta: 30 Junio 2013. [5] PgSphere 1.1, http://pgsphere.projects.pgfoundry.org/ Fecha de Consulta, 30 Junio 2013. [6] STC-X: Space-Time Coordinate Metadata for the Virtual Observatory Version 1.33. http://www.ivoa.net/Documents/cover/STC20071030.html Fecha Consulta: 30 Junio 2013. [7] ANTLRv4. http://www.antlr.org/. Fecha de consulta: 30 Junio 2013. [8] J. Bovet, T. Parr. ANTLRWorks: an ANTLR grammar development environment. Software: Practice and Experience, 38(12): 1305-1332, 2008. [9] T. Parr: The Definitive ANTLR Reference: Building Domain-Specific Languages. Raleigh: The Pragmatic Bookshelf, 2007. [10] M. Fowler, Domain-Specific Languages, October 3, 2010, ISBN-13: 978-0321-71294-3. [11] D. Ghosh, DSLs in Action, Manning Publication, 2011, ISBN-13:978-1-935182-45-0. [12] Barquin, R.A.,Gálvez O.A., Zumarán F.E. “Social Network Data Management System (SNDMS)”. Memoria de Título optar al título profesional de Ingeniero em Computación, Universidad de La Serena, La Serena, Chile. 2009. [13] San Martin Mauro, Gutierrez C.,Wood Peter T. Informe Técnico SNQL: Social Networks Query Language. TR/DCC-2011-05. Departamento de Ciencias de la Computación,Universidad de Chile.2011.http://swp.dcc.uchile.cl/TR/2011/TR_DC C-20110503-005.pdf [14] Infonor-Chile, 2012, http://www.infonorchile2012.uta.cl/ Fecha Consulta: 30 Junio 2013. [15] The Revolution in Astronomy Education Fecha http://arxiv.org/pdf/0909.3892v1.pdf. Consulta: 30 Junio 2013. [16] Atacama Large Millimeter/submillimeter Array (ALMA), http://www.almaobservatory.org/ Fecha Consulta: 30 Junio 2013. [17] Fifth Fundamental Catalogue (FK5). http://wwwkpno.kpno.noao.edu/Info/Caches/Catalogs/FK5/fk5.h tml. Fecha Consulta: 30 Junio 2013. [18] Kitt Peak National Observatory (KPNO), http://www.noao.edu/kpno/ Fecha Consulta: 30 Junio 2013. [19] ACM. Computing Curricula 2005. http://www.acm.org/education/education/curric_vols/ CC2005-March06Final.pdf. Fecha de consulta: 30 Junio 2013. [20] Observatorio Interamericano Cerro Tololo. http://www.ctio.noao.edu/noao/ Fecha Consulta: 30 Junio 2013.
