Creaci´on de objetos hiperrealistas basada en L-systems

Texto completo

(1)Creación de objetos hiperrealistas basada en L-systems. César Sánchez Velázquez Asesor : Dr. Roberto Bernal Jaquez Licenciatura en Ingenierı́a en Computación Universidad Autónoma Metropolitana-Cuajimalpa. Versión 1.0 (2013-02-06). Copyright (©) 2013–2014 Ingenierı́a en Computación..

(2) ii.

(3) Índice general 0.1. Prefacio . . . . . . . . . . . . . . 0.1.1. Uso del libro . . . . . . . 0.1.2. Conocimientos Necesarios 0.1.3. Apoyo en la Web . . . . . 0.1.4. Agradecimientos . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. iii iii iii 1 1. 1. Análisis de Requerimientos 1.1. Introducción . . . . . . . . . . . . . . . . . . . . 1.1.1. Propósito . . . . . . . . . . . . . . . . . 1.1.2. Ámbito del Sistema . . . . . . . . . . . 1.1.3. Definiciones, Acrónimos y Abreviaturas 1.1.4. Referencias . . . . . . . . . . . . . . . . 1.1.5. Visión General del Documento . . . . . 1.2. Descripción General . . . . . . . . . . . . . . . 1.2.1. Perspectiva del Producto . . . . . . . . 1.2.2. Funciones del Producto . . . . . . . . . 1.2.3. Caracterı́sticas de los usuarios . . . . . . 1.2.4. Restricciones . . . . . . . . . . . . . . . 1.2.5. Suposiciones y Dependencias . . . . . . 1.2.6. Requisitos Futuros . . . . . . . . . . . . 1.3. Requisitos Especı́ficos . . . . . . . . . . . . . . 1.3.1. Interfaces Externas . . . . . . . . . . . . 1.3.2. Funciones . . . . . . . . . . . . . . . . . 1.3.3. Requisitos de Rendimiento . . . . . . . 1.3.4. Restricciones de Diseño . . . . . . . . . 1.3.5. Atributos de el sistema . . . . . . . . . 1.3.6. Otros Requisitos . . . . . . . . . . . . . 1.4. Apéndices, Anexos . . . . . . . . . . . . . . . . 1.4.1. Ejemplos de sistemas similares . . . . . 1.4.2. Casos de Uso . . . . . . . . . . . . . . . 1.4.3. Diagramas de Estado . . . . . . . . . . 1.4.4. Logotipo del sistema . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. 3 3 3 3 5 7 7 7 7 7 8 8 9 9 9 9 9 10 10 10 10 11 11 11 12 12. 2. Ejercicios de introducción 2.1. Aprendiendo ANTLR : Una Calculadora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Lindenmayer systems : Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13 13 24. 3. Fase de Inicio : 3.1. Visión y análisis . . . . . . . . . . 3.2. Casos de uso . . . . . . . . . . . . 3.3. Especificación Complementaria . . 3.4. Glosario . . . . . . . . . . . . . . . 3.5. Lista y plan de gestión de Riesgos 3.6. Prototipos, Prueba de Conceptos . 3.6.1. El Modelo del Dominio . . 3.6.2. Diagrama de Paquetes . . .. 37 37 37 39 40 41 43 43 45. . . . . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. iii. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . ..

(4) ÍNDICE GENERAL 4. Fase de Elaboración : 4.1. Refinamiento de la fase anterior . 4.1.1. Modelo de casos de uso . 4.2. Diagramas de clase . . . . . . . . 4.3. Diagramas dinámicos . . . . . . . 4.3.1. Diagramas de secuencia . 4.3.2. Diagramas de estados . . 4.3.3. Diagramas de actividades 4.4. Modelo del diseño . . . . . . . . 4.5. Núcleo arquitectónico . . . . . . 4.5.1. La capa del View . . . . . 4.5.2. La capa del Controller . . 4.5.3. La capa del Model . . . . 4.5.4. Model-View-Controller . . 4.6. Glosario . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. 47 47 47 55 59 59 63 65 67 73 73 74 74 75 76. 5. Fase de Construcción : 5.1. Refinamientos de la fase anterior 5.1.1. El nucleo arquitectónico . 5.1.2. Diccionario de datos . . . 5.2. Modelo de implementación . . . . 5.2.1. Prototipo de interfaces . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 77 77 77 77 77 77. 0.1.. Prefacio. La actividad del ingeniero supone la concreción de una idea en la realidad. Esto quiere decir que, a través de técnicas, diseños y modelos, y con el conocimiento proveniente de las ciencias, la ingenierı́a puede resolver problemas y satisfacer necesidades humanas. La ingenierı́a también supone la aplicación de la inventiva y del ingenio para desarrollar una cierta actividad. Esto, por supuesto, no implica que no se utilice el método cientı́fico para llevar a cabo los planes. Mediante la ingenierı́a del Software que es una disciplina, que ofrece método y técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo he realizado el diseño de un sistema funcional que reúne temas de gran interés para las personas embebidas en el área de la computación y mas en particular los sistemas de software. Cuando representamos en la computadora objetos del mundo real con una finalidad técnica es necesario ingresar a un medio digital y las caracterı́sticas de estos para que puedan ser visualizados y manipulados. Es decir, un objeto dispone de ciertos atributos (forma, posición, material, etc.) que nos indican donde se encuentran y como se ven. Una de las formas de ingresar datos a un medio digital es a través de una interfaz gráfica la cual es un componente de una aplicación informática que el usuario visualiza y a través de la cual interactua con el sistema. Esta conformada por distintas metáforas gráficas que el usuario ya ha aprendido a reconocer, por ejemplo ventanas, botones, menúes e iconos, entre otros elementos. L-Systems se ha convertido en el paradigma importante para la construcción de FSPMs(Formal Structural Plant Models). Introducido a finales de 1960 por A. Lindenmayer como un formalismo para describir los procesos de desarrollo en biologı́a que resultaron muy adecuados para describir los modelos de desarrollo de la planta, En L-systems, la planta está representada por una cadena entre corchetes, cuyos elementos, llamados módulos, representan componentes de la planta (metámeros, meristemos, flores, etc.) Los módulos constan de un nombre simbólico y un conjunto opcional de parámetros. Los módulos con el mismo nombre que representan el mismo tipo de componente, un conjunto de reglas (producciones) a continuación es definido cómo cada módulo que se transforma con el tiempo. En particular, un módulo puede producir uno o más módulos nuevos, dando ası́ la posibilidad de añadir nuevos componentes a la estructura. Los soportes se usan para delimitar las ramas. Cuando se utiliza un L-system, el modelador diseña un conjunto de reglas de L-system que, cuando se aplica paso a paso a la cadena inicial (que representa el estado inicial de la planta), se simulan su desarrollo, con geometrı́a, nuevas primitivas se han introducido en el lenguaje para describir componentes de la planta en una forma de alto nivel y en diferentes escalas.. 0.1.1.. Uso del libro. 0.1.2.. Conocimientos Necesarios. Para lograr un buen entendimiento de este libro, es necesario tener conocimientos básicos de Programación orientada a objetos, de el lenguaje de programación Java y de el diseño y construcción de software, es bueno también si se cuenta iv.

(5) 0.1. PREFACIO con algunos de los términos relevantes que encierran estas áreas(herramientas de modelado, ciclo de vida de software, metodologı́as, diagramas, artefactos, métodos, clases, etc.), puesto que no todos los elementos aparecen en el glosario debido a que en muchas ocaciones vienen implı́citos en el uso de alguna herramienta o técnica, no olvide que puede consultar la bibliografia en caso de que algún tema le parezca insuficiente para abordar los capı́tulos. Desde luego aquı́ hay muchas definiciones que pueden ser de gran ayuda para comprender la integración de cada elemento en el texto y es recomendable ver los términos del glosario para darse una buena idea de los temas que se estarán abordando y una vez que se este leyendo el texto puede verificar la definición de los mismos.. 0.1.3.. Apoyo en la Web. 0.1.4.. Agradecimientos. Durante el ciclo de vida de esta tesis, recibi un extraordinario soporte y ayuda por parte de bastantes personas, por lo cual estoy agradecido con ellos(as). Primero doy gracias a los implicados directamente en el desarrollo de software; al Doctor Roberto Bernal mi asesor de proyecto y profesor de algunas UEAS en la UAMC. A Leslie Lamport que desarrollo Látex sobre TeX, desarrollado por Donald Knuth., a Terrence Parr que desarrollo ANTLR, una herramienta extraordinaria bastante funcional y poco compleja de utilizar. A Lindenmayer que creo el paradigma de los L-systems, apoyado desde luego por varios personajes inmiscuidos en el tema de los fractales y de la biologı́a. Aprovecho también para agradecer a quien durante la carrera y definitivamente de forma indirecta contribuyen a este proyecto, siempre se admira la filosofia de desarrollo, desde luego me refiero a Linus Torvalds, creador de el kernel de Linux, a Richard Stallman, que fundo GNU, parte indispensable para la distribucion de todo el codigo libre que hoy podemos compartir todos los programadores del mundo.. 1.

(6) ÍNDICE GENERAL. 2.

(7) Capı́tulo 1. Análisis de Requerimientos. 1.1.. Introducción. Se requiere de un sistema interactivo e intuitivo que permita la creación y manipulación de objetos hiperrealistas en un espacio tridimensional. Dicho sistema debe contemplar como entrada la gramática usada por los L-system, con el objetivo de visualizar la interpretación geométrica de los parámetros dados como entrada y entonces el software brinde una gamma de utilidades que permitan al usuario manipular y modificar el objeto generado. Se espera un entorno gráfico atractivo.. 1.1.1.. Propósito. El propósito del sistema, en una versión que representara el núcleo de un software para paisajes hiperrealistas al igual que permita a los usuarios mas noveles en el tema que puedan observar e interactuar la interpretación geométrica de los argumentos requeridos por los L-system; Luego los objetos generados en una interfaz intuitiva permitirán ser manipulados e incluso modificados al cambiar los argumentos que ellos mismos introducen o de los ya generados. Este documento pretende guiar y contextualizar al desarrollador del software a un claro entendimiento de las funcionalidades del sistema con los riesgos, restricciones y demás artefactos que conlleva el diseño e implementación de las mismas.. 1.1.2.. Ámbito del Sistema. El sistema a desarrollar lleva por nombre ”Hyper-L.acrónimo de Hiperrealismo Lindenmayer ya que cuenta con interfaz gráfica que permite la manipulación de diversos objetos generados por los argumentos de una gramática de L-systems, también sus parámetros pueden ser modificados y entonces se refresca la vista. Que hará el Sistema El sistema debe contemplar un espacio para la entrada de los argumentos que el usuario introducirá. Debe ser realmente intuitivo para la creación de un L-system. Debe contar con un espacio gráfico donde se muestre la interpretación geométrica de los elementos de entrada. Debe permitir la rotación de el objeto generado por la gramática mediante el mouse(dispositivo del ordenador). Incluir la actualización de el entorno gráfico ya sea por medio de un botón, un comando, o automáticamente. Contemplar un manual de uso y especificación de lo necesario para hacer un uso correcto del software. Se esperan algunos ejemplares de objetos que pueden generarse. Los argumentos a contemplar como mı́nimo en la entrada son (distancia, axioma, reglas de producción, colores, angulo de giro). Capacidad de almacenamiento, es decir, guardar y abrir archivos que tengan una estructura valida que sera definida por el mismos sistema. Contemplar el exportar imágenes del el entorno gráficos a algún tipo de extensión ya conocida(jpg, jpeg, png, bmp, etc.) 3.

(8) CAPÍTULO 1. ANÁLISIS DE REQUERIMIENTOS El núcleo básico que consta en la interpretación geométrica de los argumentos utilizando el ”paradigma”Lsystem, podrı́a verse como un compilador para L-systems complementado con salida de ejecución en entorno tridimensional. Se espera también la redimensión automática en el entorno gráfico. Gestión de errores en todas las funcionalidades del sistema. Que no hará el Sistema No permitirá al usuario mover algún elemento generado usando el mouse dentro del entorno gráfico. No abrirá archivos corruptos (que no tengan la estructura que el sistema espera). No permite texturizar el entorno gráfico, o cualquier detalle como luminosidad entre otras funcionalidades que brindan herramientas como OpenGL. No es un sistema que ejecute acciones gráficas en paralelo. No realiza análisis de Nivel biológico en el contenido de las frases que lo generan. No interpreta los L-system sensibles al contexto (se habla de ello en el capitulo 2). No considera parámetros de tiempo restringido para alguna de sus funcionalidades. No hace un proceso de descubrir la gramática L-system de un objeto. Los beneficios que se obtienen de este sistema están dados en un contexto meramente didácticos con elementos para pensar en paisajes artificiales y observar el comportamiento de los elementos cuando se hacen variar los argumentos dentro de la gramática. De entrada se aprenderá con un método atractivo que es un L-system y como funciona, luego podrán realizarse diseños mediante una gramática con todos los parámetros que se contemplan en el contexto L-system, incluso puede observarse que ocurre al mezclar ”n”gramáticas distintas de objetos que tienen o no sentido, esto nos lleva a un ambiente biológico yo estadı́stico, donde podrı́amos también realizar un análisis para predecir comportamientos con cambio en los parámetros, incluso algunos, intuición del usuario . Puede también tener utilidad para generar tapices de un juego, aplicación en dispositivos móviles y para fondos de pantalla tomando los módulos necesarios. Objetivos 1. Se pretende que un usuario que no este embebido en el tema de los L-system aprenda que son y como funcionan por medio de su interacción con la interfaz gráfica. 2. Modelar objetos hiperrealistas basados en las gramáticas L-system mostrando el mayor detalle posible de lo que ocurrió en su interpretación geométrica para fomentar creatividad en el usuario. 3. Crear un entorno verdaderamente amigable con la intención de observar comportamientos de una simple gramática a la que se le imponen parámetros variables o no. 4. Obtener una aplicación que muestre detalladamente la secuencia que sigue un L-system. 5. El usuario pueda realizar un análisis de lo que obtiene y deducir que aspectos del elemento tienen sentido para mezclarse con otras gramáticas, ası́ como que modificar para que de como resultado las hipótesis que se plantee. En general se pretende alcanzar un sistema capaz de crear elementos que llamamos hiperrealistas debido a su poco parecido con lo que tenemos en nuestro entorno real, donde estos elementos estén basados en las estructuran que implementan los L-system. El usuario posea control sobre estas gramáticas familiarizándose mediante el mismo sistema y archivando lo que el desee para futuros usos.. 4.

(9) 1.1. INTRODUCCIÓN. 1.1.3.. Definiciones, Acrónimos y Abreviaturas. Debe considerarse que algunos términos relevantes no precisamente aparecen en la siguiente tabla, puesto que se han detallado en las secciones que se consideran pertinentes, un ejemplo de ello los L-system y antlr que se encuentran en el capitulo 2 (seria redundante mencionarlos aquı́).. Análisis de requerimientos. Compiladores. Análisis léxico. Conceptos Relevantes Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. Es una tarea de ingenierı́a del software que permite especificar las caracterı́sticas operacionales del software, indicar la interfaz del software con otros elementos del sistema y establecer las restricciones que debe cumplir el software[3]. Los compiladores son programas de computadora que traducen un lenguaje a otro. Un compilador toma como su entrada un programa escrito en su lenguaje fuente y produce un programa equivalente escrito en su lenguaje objetivo. Por lo regular, el lenguaje fuente es un lenguaje de alto nivel, tal como C o C++, mientras que el lenguaje objetivo es código objeto (también llamado en ocasiones código de máquina) para la máquina objetivo, es decir, código escrito en las instrucciones de máquina correspondientes a la computadora en la cual se ejecutará[5]. Esta fase tiene que ver con el “vocabulario” que define un conjunto de palabras validas. El proceso de análisis léxico agrupa los diferentes caracteres de su flujo de entrada en tokens. Los tokens son los sı́mbolos léxicos del lenguaje; se asemejan mucho a las palabras del lenguaje natural. Los tokens están identificados con sı́mbolos (tienen “nombres”) y suelen contener información adicional (como la cadena de caracteres que los originó, el fichero en el que están y la lı́nea donde comienzan, etc). En inglés al programa que hace esto se le suele llamar scanner o lexer como ejemplo existe lex y flex. Para ejemplificar cómo funciona un lexer vamos a usar un ejemplo: Dado el fragmento de código imaginario siguiente : Apretar (tuercas); Pintar(chasis+ruedas); Un analizador léxico particular producirı́a la siguiente serie de tokens: RES_APRETAR PARENT_AB NOMBRE PARENT_CE PUNTO_COMA RES_PINTAR PARENT_AB NOMBRE SIM_MAS NOMBRE PARENT_CE PUNTO_COMA. Análisis sintáctico. Análisis semántico. Es la segunda fase de un compilador también llamada parsing en inglés. Usa los primeros componentes de los tokens producidos por el analizador léxico para crear una representación inmediata con estructura de un árbol que describe la estructura gramatical del flujo de tokens. Una representación tı́pica es una sintaxis de árbol donde cada nodo interior representa una operación y nodo hijo representa los argumentos de la operación[1].tural. El análisis sintáctico determina los elementos estructurales del programa y sus relaciones. Los resultados del análisis sintáctico por lo regular se representan como un árbol de análisis gramatical o un árbol sintáctico(AST)[5]. El analizador semántico utiliza el árbol de sintaxis y de la información en el sı́mbolo para el registro del programa de origen para mantener la coherencia semántica del lenguaje. También recoge información sobre el tipo y la guarda en el árbol de sintaxis o la tabla de sı́mbolos, para su uso posterior durante la generación de código intermedio. Una parte importante del análisis semántico es la verificación de tipos, donde el compilador comprueba que cada operador tiene operandos encontrados.. 5.

(10) CAPÍTULO 1. ANÁLISIS DE REQUERIMIENTOS. Gramática. ciencia que estudia la lengua, teniendo en cuenta según la filosofı́a que la sustente en algunos casos solamente las formas (como en la Gramática estructural), o las formas y los significados (como en la gramática tradicional). La Gramática, pues, es una descripción sincrónica del sistema de una lengua. Constituye el estudio cientı́fico de su funcionamiento y sus caracterı́sticas, en el momento actual; explica cómo es el sistema. Para su estudio, se distinguen tres criterios gramaticales: Criterio sintáctico: función, régimen, conexión, concordancia, coherencia y cohesión. Criterio morfológico: variaciones o accidentes de los vocablos: género, número, persona, caso, grado, tiempo, modo, etc. Criterio semántico: significaciones, connotación y detonación. Otros campos del estudio del lenguaje, lo constituyen: 1. Fonologı́a o fonética: aspectos sonoros: vocales, consonantes, acento y entonación, etc. 2. Sistema gráfico: representación de los elementos sonoros: letras, signos de puntuación, etc.. Expresiones Regulares. Software. Hiperrealismo. Las expresiones regulares representan patrones de cadenas de caracteres. Una expresión regular se encuentra completamente definida mediante el conjunto de cadenas con las que concuerda. Una expresión regular también contendrá caracteres del alfabeto, pero esos caracteres tendrán un significado diferente: en una expresión regular todos los sı́mbolos indican patrones. Por último, una expresión regular puede contener caracteres que tengan significados especiales. Este tipo de caracteres se llaman meta caracteres o meta sı́mbolos, y por lo general no pueden ser caracteres legales en el alfabeto, porque no podrı́amos distinguir su uso como meta caracteres de su uso como miembros del alfabeto. Observe la tabla que se encuentra justo después de esta. Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados que forman parte de las operaciones de un sistema de computación [Std. 729, IEEE]. El software no son solo programas, sino todos los documentos asociados y la configuración de datos que se necesitan para hacer que estos programas operen de manera correcta. Un sistema de software consiste en diversos programas independientes, archivos de configuración que se utilizan para ejecutar estos programas, un sistema de documentación que describe la estructura del sistema, la documentación para el usuario que explica como utilizar el sistema y sitios web que permitan a los usuarios descargar la información de productos recientes [Sommerville, 2004]. El hiperrealismo es una tendencia radical de la pintura realista surgida en Estados Unidos a finales de los años 60 del siglo XX que propone reproducir la realidad con más fidelidad y objetividad que la fotografı́a. Es una corriente o estilo artı́stico que también se aplicó en la escultura con el uso de materiales sintéticos que imitan hasta la piel, trata de dar una exhaustiva descripción visual de lo pintado, se ven mas detalles que en la propia fotografı́a donde lo que esta fuera del punto de foco puede tener menos nitidez, la factura extremadamente naturalista pero con composiciones algo ilógicas puede sugerir surrealismo No confundir con el fotorrealismo el cual usa proyecciones de fotos dando como resultado algo bien cercano a la fotografı́a.. 6.

(11) 1.2. DESCRIPCIÓN GENERAL. Sı́mbolo (...) (...) * (...) + (...) ? {...} [...] {...}? (...) => | .. ˜ . = : ; <...>. 1.1.4.. Expresiones regulares en ANTLR Descripción. La subregla Cierre subregla cero o más. Subregla cierre positivo de uno o más. opcional cero o uno. Acción semántica. Los argumentos de la regla. Predicado semántico. Predicado sintáctico. Operador alternativo. Rango de operador. No operario. Comodı́n Operador de asignación. Etiqueta operador, puesta en regla. Regla final. Elemento de opción.. Referencias. Ver Referencias en la parte bibliográfica del documento. Ver IEEE Std. 830.. 1.1.5.. Visión General del Documento. Con esto entramos a una breve descripción de lo que se encarga de analizar este documento basado en IEEE 830, con una visión general y los requisitos especı́ficos, con la siguiente idea general : El sistema “Hyper-L ”es una herramienta gráfica usable que interpreta y diseña gramática L-system dándoles una interpretación geométrica, mediante el uso de las herramientas que se consideran optimas pensando en los usuarios finales de dicho sistema, brindando ası́ una interfaz intuitiva para la interacción y pruebas del área de dominio, ademas ofrece una gamma de utilidades para la manipulación de objetos generados en su respectiva área de trabajo; Un análisis detallado de este sistema que se quiere obtener como producto final es clasificado en este documento mediante las funcionalidades, modularizando e identificando aspectos relevantes con todo lo que el entorno de desarrollo debe considerar. Sigue entonces dejar el sistema extensible y seguro, considerando restricciones y requisitos futuros, Luego ya empieza el núcleo de la ingenierı́a de software con un inicio de diseño con diagramas. Esto es lo que encontraremos en las siguientes secciones y subsecciónes del Capitulo 1, necesario para tener bien claro hacia donde vamos.. 1.2.. Descripción General. Consideremos ahora los factores que afectan al producto centrándonos en el contexto.. 1.2.1.. Perspectiva del Producto. La relación que este sistema tendrá con otros productos por el momento es nula ya que se pretende levantar la base para posteriormente incluir algunas otras funcionalidades que lo potencialicen mas, Lo cierto es que si debemos contar con la estructura básica de un L-system que es quizá una dependencia para nuestro sistema debido a la gran relación que existe pero al no ser un producto de software como tal, no implica consideración en interfaces para Hyper-L. Al ser este producto totalmente independiente, solo se considera que los formatos que serán tomados en cuenta para exportar las imágenes son los comúnmente usados por un usuario cualquiera (.png, .jpeg, .png, etc.). y en cuanto a los archivos estarán definidos por este sistema para que se estructuren con formato único.. 1.2.2.. Funciones del Producto. Permitir la entrada de los datos y parámetros necesarios para generar un L-system. Mostrar algunos ejemplos para que guı́en al usuario a entender los argumentos necesarios. Realizar la interpretación geométrica en un espacio tridimensional de los argumentos dados, siguiendo el ”paradigma”Lsystem cuando el usuario ası́ lo indique. 7.

(12) CAPÍTULO 1. ANÁLISIS DE REQUERIMIENTOS Considerar el almacenamiento de un archivo que describe un objeto hiperrealista valido con sus respectivos parámetros, ası́ como la apertura de el mismo. Exportar a una imagen de formato usual el área gráfica donde se encuentra la geometrı́a de los argumentos dados. Permitir la manipulación de el objeto en el área gráfica (rotación en especifico). Administrar las entradas no validas e informar al usuario, cual es el error. Almacenar la información del objeto generado en un archivo de extensión .hyprl cuando el usuario lo desee Abrir también los archivos con dicha extensión. Incluir un manual de ayuda que guié al usuario al entendimiento del software.. 1.2.3.. Caracterı́sticas de los usuarios. Indudablemente los usuarios de este software son personas que tienen interés en la funcionalidad de los L-system, curiosos que desean ver cuestiones de gráficos interesantes como los fractales, investigadores que desean probar la interpretación geométrica de algunas gramáticas, e incluso biólogos que experimenten observando el comportamiento de algunos parámetros cuando estos son cambiados y que información encierra un objeto hiperrealista (árboles y plantas en especifico), el resultado de combinar argumentos de distintos objetos, y repito, personas embebidas en el tema de los L-system.. 1.2.4.. Restricciones. 1. El sistema debe ser capaz de manejar la persistencia de los datos generando un archivo .hyprl. 2. El sistema debe contemplar la estructura gramatical L-system. 3. La interpretación geométrica debe mostrarse en un espacio tridimensional. 4. El sistema debe ser fácil e intuitivo para el usuario. 5. El sistema Hyper-L debe ser interactivo, usando algún patrón de diseño para un entendimiento coherente. 6. El sistema debe fungir como aplicación de escritorio. 7. Como ya se menciono el sistema va dirigido a personas interesadas por el tema y para curiosos, por lo cual debe incluir una guı́a que facilite un rápido aprendizaje de las funcionalidades del software. 8. El sistema debe ser susceptible a equivocaciones, con manejo de excepciones, ası́ que por ningún motivo debe plasmarse. 9. El sistema debe ser portable siempre y cuando se cuente con las dependencias necesarias. 10. El sistema debe contar con objetos y/o gramáticas ejemplares. 11. El sistema debe ser capaz de exportar en imagen los gráficos generados por la gramática correspondiente en el área de trabajo. En una primera versión, solo se consideraran dos formatos de imagen, que son: .png y .jpg. 12. Se espera una interfaz amigable y formal. 13. El lenguaje de programación que se usara es el que los desarrolladores consideren pertinente. 14. Debe ser un sistema confiable, en esta primera versión puede no preocuparse por la seguridad de los datos ó ficheros. 15. se espera que la calidad de los gráficos sea buena, como en OpenGL, Blender, etc. 16. se requiere la documentación completa de como se construyo el sistema. 8.

(13) 1.3. REQUISITOS ESPECÍFICOS. 1.2.5.. Suposiciones y Dependencias. Los factores que en este caso pueden afectar los requisitos son detalles como considerar el implementarlo en la nube, puesto que de momento no se prevé el diseño para esta etapa, el echo de implementarlo en dispositivos móviles como tabletas o celulares también seria de gran consideración puesto que nos trae restricciones de alto nivel y algunas modificaciones si se quiere dejar una animación que nos cree fondos de pantalla. En el caso de querer en algún momento considerar otros tipos de L-system, como los sensibles al contexto pensaremos mas en la extensibilidad del producto que en grandes modificaciones, sin embargo también afecta los requerimientos por pequeños que sean los cambios. Es posible que por un motivo tenga el sistema que migrarse a un lenguaje de programación o incluso Sistema Operativo, lo cual nos restringe a aspectos como definir el uso de técnicas o herramientas que de alguna forma modifica nuestros requerimientos y en su caso las dependencias, puesto que el uso de librerı́as y plugin usados cambian.. 1.2.6.. Requisitos Futuros. Una versión futura del sistema consistirá en en implementar los módulos necesarios para los L-system sensibles al contexto, animar los objetos hiperrealistas, y dotar de mayor calidad y recursos al sistema para que soporte los paisajes hiperrealistas basados en la misma estructura pero los recursos de procesos gráficos que esto implica sera un punto central, se esperara también un mayor nivel de investigación que nos lleve a descubrir, la información que nos brinda el utilizar estas gramáticas, hasta ahora ya hay bastante en esta área, pero se pretende llegar a la información genética y mas aplicaciones que la potencialidad de los L-system pueden darnos.. 1.3. 1.3.1.. Requisitos Especı́ficos Interfaces Externas. En cuánto a la interfaz de usuario se refiere, un requisito ya muy mencionado anteriormente es la usabilidad de la misma, se espera una interfaz lo suficientemente intuitiva para aprender en tanto sea posible la función de los L-system, el área gráfica tridimensional y con buen aspecto, la barra de ayuda y el manejo de las excepciones con ventanas de aviso, errores, advertencias, etc. La comunicación con otros sistemas es nula y por lo tanto no se requieren crear interfaces de conexión a otro software, al igual que no se desea implementar para alguna tarjeta gráfica en especial evita que se realice alguna interface para hardware especifico; las comunicaciones que se establecen son directas entre las herramientas que decidan usarse, mediante flujos de datos que los lenguajes de programación traen por default ası́ que no se crearan flujos de comunicación desde raı́z.. 1.3.2.. Funciones. 1. Definir estructura de entrada : Se debe definir una estructura de entrada en los datos que el sistema necesita. Esto puede pensarse como un script, como un lenguaje, o quizá solo poner los campos de texto para que sean llenados por el usuario. 2. Flujo de entrada de datos : Considerar un área en la interfaz o bien un menú selectivo que permita tomar como entrada la ”gramática L-system y sus parámetros necesarios”que el usuario desea para que el sistema trabaje con esta. 3. Manejo de errores : Verificar que los datos de entrada están correctos y en lugares pertinentes de la estructura, es decir, dentro de la gramática, en casos particulares algunos valores podrı́an darse por default si el usuario no los introduce, esto con la idea de facilitar la tarea del usuario. Informar de sus errores. 4. Ejemplos de guı́a : Mostrar algunos ejemplos que sirvan de prueba para el usuario, donde reúna los parámetros que se consideren necesarios para que funjan como guı́a de aprendizaje. 5. Comportamiento de los objetos : Funcionalidad en el área tridimensional capaz de simular la rotación de un objeto existente con respecto al movimiento del mouse cuando el botón derecho de este se mantenga presionado. 6. Interpretación geométrica : El principal objetivo a cumplir es que el sistema cuente con la funcionalidad necesaria para poder interpretar la entrada mediante la funcionalidad que siguen los L-system a la geometrı́a correspondiente y representarla sobre el área destinada a ello en la interfaz de usuario. 7. Almacenamiento de objetos : Establecer el método necesario para salvaguardar la información (en un archivo o en su caso base de datos) que hace referencia a una gramática valida para el sistema, por consiguiente también debe incluirse la apertura de este tipo de archivo o elemento según se le considere. 9.

(14) CAPÍTULO 1. ANÁLISIS DE REQUERIMIENTOS 8. Exportar a Imagenes : El sistema debe ser capaz de exportar a imagen de extensión conocida el área gráfica donde se encuentra la interpretación geométrica de la gramática de entrada. 9. Ayuda al usuario : Incluir en la barra de ayuda un tutorial rápido de el uso del software para que el usuario se familiarize rápido con el mismo, lo mas breve y entendible que se pueda. 10. Detalles gráficos : Se prevé que cuando el sistema haga la interpretación geométrica, considere la relación entre las partes de la gramática que representen partes de el objeto valga la redundancia, y con ello asociar los colores que se dese; esto no es algo que se especifique en los L-system, pero consideramos que dotara de gran potencia al software debido a la perspectiva que le da al usuario. 11. Interfaz de Usuario : El sistema debe considerar una interfaz amigable, usable, fiable y consistente la cual tiene como prioridad un área gráfica donde se muestran los objetos hiperrealistas generados cuando la gramática de entrada es correcta, se pueden incluir detalles de mostrar coordenadas, el punto de partida de los ejes o incluso los ejes, etc. no se restringe la creatividad en esta interfaz siempre y cuando este dentro del tema.. 1.3.3.. Requisitos de Rendimiento. Se espera que el sistema tenga un alto rendimiento pero no ilimitado, esto es, el numero de programas en ejecución esta contemplado uno a la vez, con la finalidad de optimizar memoria, donde además solo un usuario puede estar a la vez, ya que el sistema no tiene la necesidad de estar paralelamente distribuido o sincronizado en algún momento. Es necesario también considerar que los eventos que se generan dentro del área gráfica esta previsto para uno a la vez puesto que esta pensado para PC y no para GPU, aunque no se descarta como requisito futuro; no tienen una restricción de tiempo, sin embargo el diseño de dicha funcionalidad no debe ser exponencial, ya que si consideramos la extensibilidad de el software esto se vuelve bastante ineficiente y problemático. Con respecto a los datos que se van a almacenar se puede usar lo que se considere mas optimo para el sistema, archivos, bases de datos, u otros, la importancia de esto es que se puedan abrir los proyectos que hayan sido editados en “Hyper-L”, por lo tanto no se exige un formato de los datos de persistencia sin embargo se espera que esto sea optimizado por los desarrolladores, al igual que la frecuencia de uso y las capacidades de acceso; podemos observar que no son muy grandes.. 1.3.4.. Restricciones de Diseño. Gráficamente debe ser un software usable, intuitivo, extensible, funcional y estable, consistencia lógica en sus partes básicas (movimientos, selecciones, reacciones a parámetros de entrada, etc.). Aunque no sigue ningún estándar en especial para su diseño de interfaz, se espera un software entendible, tomando en cuenta a lo que la mayorı́a de los usuarios están acostumbrados, esto es, notaciones e iconos comunes, colores no extravagantes fuera del área gráfica, barras de ayuda, letra legible, etc., adaptable y consistente a cualquier plataforma de sistema operativo. Las limitaciones del hardware son totalmente de el ordenador y el responsable es el usuario, puesto que “Hyper-L” no necesita de mucho espacio en memoria a excepción de abrir muchos al mismo tiempo que tampoco es necesario. La restricción de diseño a considerar es el espacio tridimensional en un área de la interfaz donde no se especifica un tamaño fijo pero si lo suficiente para que se visualicen los objetos.. 1.3.5.. Atributos de el sistema. El sistema debe ser fiable, mantenible en caso de fallas, portable y extensible. La seguridad que se manejara en este software va a depender de lo que se use para la persistencia de los datos, donde se recomienda usar archivos para evitar que sea el sistema quien se encargue de detalles como contraseñas para base de datos entre otros (se deja al gusto del desarrollador), por el momento no se requiere autenticación o similares, es un sistema compartido.. 1.3.6.. Otros Requisitos. El sistema debe tener un splash de presentación que le de mayor formalidad de programa existente en la computadora. Los desarrolladores gestionarán el logotipo de el sistema para que se identifique fácilmente. El sistema puede tener en un menú de ayuda, en el un manual de uso para dudas de el usuario, links donde se empape de los conocimientos necesarios de los L-systems, libros.pdf que le aclaren sobre el tema, glosario, simbologia si es que la hay, etc.. 10.

(15) 1.4. APÉNDICES, ANEXOS. 1.4. 1.4.1.. Apéndices, Anexos Ejemplos de sistemas similares. Existen hoy dia gran variedad de aplicaciones que realizan una interpretacion geométrica de los Lsystems, cada uno con sus extensiones particulares pero siguiendo la forma de derivacion y los parametros que considera la teoria como tal. Listando algunas de estas aplicaciones : Fractint, Un sistema online http://www.kevs3d.co.uk/dev/lsystems/ que se observa de la siguiente forma:. Figura 0: Ejemplo de sitio web interactivo sobre Lsystems básicos, con ejemplos. http://madflame991.blogspot.mx/p/lindenmayer-power.html, http://nolandc.com/sandbox/fractals/, http: //www.alpix.com/vrml/lsys.htm, http://malsys.cz/Discussion/Category/1, http://hardlikesoftware.com/ projects/lsystem/lsystem.html, http://zdeeck.borg.cz/wlse/l-system.php.. 1.4.2.. Casos de Uso. Figura 1: Casos de uso (I): General 11.

(16) CAPÍTULO 1. ANÁLISIS DE REQUERIMIENTOS. 1.4.3.. Diagramas de Estado. Figura 2: Diagrama de estados (I): General. 1.4.4.. Logotipo del sistema. Figura 3: Representación de un helecho con Lsystems. 12.

(17) Capı́tulo 2. Ejercicios de introducción. 2.1.. Aprendiendo ANTLR : Una Calculadora. Es necesario definir el uso de cada una de las herramientas que se utilizan este proyecto y desde luego argumentar su uso, es ası́ que introducimos las siguientes cuestiones. ¿Que es antlr? : ANTLR (ANother Tool for Language Recognition) es un potente generador de analizadores sintácticos para leer, procesar, ejecutar o traducir texto estructurado o archivos binarios. Es ampliamente utilizado para construir lenguajes, herramientas y marcos. A partir de una gramática, ANTLR genera un analizador que puede construir y caminar árboles de análisis sintáctico. En la terminologı́a común, ANTLR es un generador de compilador o compilador compilador (en la tradición de herramientas como Lex-Flex y Yacc-Bison) y se utiliza para generar el código fuente de los reconocedores de idiomas, analizadores y traductores de las especificaciones del lenguaje. Antlr toma como entrada una gramática y genera archivos de código fuente y otros archivos auxiliares. La lengua de destino del código fuente generado (por ejemplo, Java, C, C++, C sharp, Python, Ruby) se especifica en la gramática. ¿Porque ANTLR? : El uso de una sola herramienta para todos los niveles tiene varias ventajas. La más importante es la estandarización: con ANTLR basta con comprender el paradigma de análisis una vez para poder implementar todas las fases de análisis. Debido a que puede ahorrar tiempo y recursos mediante la automatización de una parte significativa del esfuerzo involucrado en la construcción de herramientas de procesamiento de lenguaje. Es bien sabido que las herramientas generativas como compiladores de compilador tienen un impacto importante y positivo en la productividad del desarrollador. AntlrWorks http://www.antlr3.org/works/index.html simplemente fantástico IDE ofrece beneficios de productividad a través de otro comparable generativo kits de herramientas de procesamiento de lenguaje.. Figura 0: comparación de antlr con bison y flex. 13.

(18) CAPÍTULO 2. EJERCICIOS DE INTRODUCCIÓN Comencemos entonces : La mejor manera de aprender sobre antlr es caminar a través de un simple ejemplo pero útil[2].En este apartado, vamos a construir un evaluador de expresiones aritméticas que soporta unos pocos operadores y asignaciones de variables en lenguaje java pero incluso lo vamos a llevar a convertirse en una aplicación móvil para sistemas Android. Cabe mencionar que no entraremos en detalles de el manejo de cada una de las herramientas que se usaran aquı́, esto es, instalación, soporte, etc.puesto que nos desviarı́a de los objetivos principales. Iniciamos entonces con un análisis del problema, donde percibimos que necesitaremos construir una gramática, un analizador para reconocer el lenguaje de expresiones y agregar acciones a evaluar e imprimir el resultado. Cuando hayamos terminado con esta subsección, se tendrá una buena visión global de cómo construir traductores con antlr y una noción de su funcionalidad que es un gran paso hacia las bases gramaticales del proyecto como tal. Como bien es sabido las expresiones matemáticas tienen jerarquı́as para su evaluación y los paréntesis las alteran por lo cual es necesario tener esto en consideración tanto en la gramática a desarrollar como en las entradas que deseemos probar; Las asignaciones de variables y referencias, permitirán expresiones tales como los siguientes: a=3 b=5 2(a + b) Empezamos por construir una gramática que describe la estructura general sintáctica de expresiones y asignaciones. El resultado es un programa que nos dice si la entrada es válida. Luego debemos insertar código entre los elementos de la gramática en su caso posiciones para evaluar piezas de la expresión. Por ejemplo, dada de entrada 3, el traductor debe ejecutar una acción que convierte el carácter a su valor entero.acciones como agregación en caso de ser suma(+), decremento en caso de resta(-), entre otras. Entonces entremos en detalle de lo que se va realizando para este ejercicio que asociando la idea de las fases de un compilador. Reconocimiento de la sintaxis del lenguaje : Tenemos que construir una gramática que describe completamente la sintaxis de nuestra expresión del lenguaje, ANTLR va a generar un programa que reconoce expresiones válidas, que automáticamente emita errores de expresiones no válidas. Pensemos en la estructura general de la entrada, y luego dividir en las subestructuras necesarias, partiendo de que la entrada global consiste en una serie de expresiones y asignaciones. La gramática más común en antlr es aquella que especifica el analizador sintáctico y léxico; Para el caso del sintáctico tenemos que una asignación es un identificador, seguido por un signo igual, seguido por una expresión, y termina con un carácter de nueva lı́nea; un identificador es una secuencia de letras. Implementamos esto en un archivo Expr.g(el archivo se llama como la gramatica que definimos con .g al final) : grammar Expr; prog: stat+ ; stat: expr NEWLINE | Identificación ’=’ expr NEWLINE | NEWLINE ; Leer progresivo de la siguiente manera: un prog es una lista de reglas estadı́sticas(stat), un stat es una de las tres alternativas: [Un expr seguido por un salto de lı́nea (token NEWLINE), La secuencia ID (identificador) ’=’ expr NEWLINE, Un token NEWLINE] ; Asi para cada definición, Ahora tenemos que definir lo que es una expresión, regla expr, que deducimos después de un análisis. expr: multExpr ((’+’ |’-’ ) multExpr)* ; multExpr: atom (’*’ atom)* ; atom: INT | ID | ’(’ expr ’)’ ; En cuanto al nivel léxico, definimos los sı́mbolos del vocabulario (tokens): identificadores, números enteros, y el carácter de nueva lı́nea. Cualquier otro espacio en blanco es ignorado. Aquı́ están las reglas léxicas que vamos a necesitar; Notese que usamos las expresiones regulares de la tabla que se encuentra en acrónimos del capitulo 1:: 14.

(19) 2.1. APRENDIENDO ANTLR : UNA CALCULADORA ID : (’a’..’z’ |’A’..’Z’ )+ ; INT : ’0’..’9’ + ; NEWLINE:’\r’ ? ’\n’ ; WS : (’ ’ |’\t’ |’\n’ |’\r’ )+ {skip();} ; En este momento, no tenemos ningún código Java se ejecute. Todo lo que tenemos es una gramática antlr. Para convertir la gramática antlr a Java, invocar antlr de la linea de comandos(con java org.antlr.Tool Expr.g) ó de “Generar codigo ”en la barra de herramientas de antlrworks. Con ello se genera en el directorio actual del documento antlr una carpeta llamada output que contiene los archivos de codigo(en este caso java) generados por antlr: Un lexer y un parser que se pueden compilar como cualquier otro archivo con estension .java ; tambien genera una lista de tokens en un archivo para el tipo de asignamiento del token. Ahora bien, si miramos el codigo del parser vemos que hay un metodo para cada regla definida en la gramatica, tenga en cuenta que las referencias de reglas se traducen en llamadas a métodos, y el sı́mbolo de referencias se traducen en llamadas a match(TOKEN). Ademas se en caso de una falta o adicional token, el reconocedor volverá a sincronizar y pasar por las fichas hasta que vea un token en el propio conjunto ”siguiente”. Para ver en detalle esto consulte el Capı́tulo 10 del libro[2] de la bibliografia. En cuanto al archivo de tokens se refiere los tipos de tokens son números enteros que representan el ”tipo”de token, al igual que los valores ASCII representan caracteres. Hasta aqui podemos ya realizar la primera prueba de nuestro evaluador, que solo aceptara entradas validas pero hasta ahi porque aun no implementamos la salida y es nuestro siguiente paso ; Para ejecutarlo ahora necesitamos un método main() como este: 1 2 3 4 5 6 7 8 9 10 11 12. public s t a t i c void main ( S t r i n g [ ] a r g s ) throws E x c e p t i o n { // C r e a t e an i n p u t c h a r a c t e r stream from s t a n d a r d i n ANTLRInputStream i n p u t = new ANTLRInputStream ( System . i n ) ; // C r e a t e an ExprLexer t h a t f e e d s from t h a t stream ExprLexer l e x e r = new ExprLexer ( i n p u t ) ; // C r e a t e a stream o f t o k e n s f e d by t h e l e x e r CommonTokenStream t o k e n s = new CommonTokenStream ( l e x e r ) ; // C r e a t e a p a r s e r t h a t f e e d s o f f t h e t o k e n stream E x p r P a r s e r p a r s e r = new E x p r P a r s e r ( t o k e n s ) ; // Begin p a r s i n g a t r u l e p r o g p a r s e r . prog ( ) ; }. Las clases ANTLRInputStream y CommonTokenStream son clases estándar antlr del paquete org.antlr.runtime. Una vez que compilamos el código generado y el archivo que contiene el metodo anterior( llamemosle Test.java), hacemos la ejecución de prueba, y escribimos una expresión simple seguido de nueva lı́nea y luego el caracter de final de archivo apropiado para la plataforma(Ctrl+D en Unix ó Ctrl+Z en Windows). Notese que envia señales de error en caso de una entrada no valida. Hemos hecho un analizador léxico y, todo sin necesidad de escribir código Java! Como se puede ver, escribiendo una gramática es mucho más fácil que escribir código de análisis. es por ello que podemos pensar en notación antlr como un lenguaje de dominio especı́fico diseñado para hacer que los reconocedores y traductores sean fáciles de construir. Ahora debemos agregar las acciones que faltan para nuestro propósito. 1. Definir una tabla hash llamada memoria para almacenar un mapa variable a valor. 2. Tras la expresión, imprimir el resultado de su evaluación. 3. Al ser asignado, evaluar la expresión del lado derecho, y asignar la variable en el lado izquierdo para el resultado. Almacenar los resultados en memoria. 4. Al INT, devolver su valor entero como resultado. 5. Tras la identificación, devolver el valor almacenado en la memoria para la variable. Si la variable no se ha definido, emite un mensaje de error. 6. Después de la expresión entre paréntesis, devolver el resultado de la expresión. 7. Tras la multiplicación de dos átomos, devolver la multiplicación de los resultados de dos átomos. 8. La adición de dos subexpresiones multiplicativos, devolver la adición de los resultados de las dos subexpresiones. 9. Tras la sustracción de dos subexpresiones multiplicativos, devuelva la sustracción de los resultados de las dos subexpresiones. 10. Agregar la operacion dividir dos atomos. 15.

(20) CAPÍTULO 2. EJERCICIOS DE INTRODUCCIÓN Ahora entonces realizando el punto 1 lo definimos de la siguiente forma : @header { import java.util.HashMap; } @members { /** Map variable name to Integer object holding value */ HashMap memory = new HashMap(); } Modificamos el mismo archivo de la siguiente forma : prog: stat+ ; stat: // evaluate expr and emit result // $expr.value is return attribute ’value’ from expr call expr NEWLINE {System.out.println($expr.value);} // match assignment and stored value // $ID.text is text property of token matched for ID reference | ID ’=’ expr NEWLINE {memory.put($ID.text, new Integer($expr.value));} // do nothing: empty statement | NEWLINE ; Para las reglas que intervienen en la evaluación de expresiones, es muy conveniente tenerlas, devolver el valor de la subexpresión en que coinciden. Por lo tanto, cada regla coincidirá y evaluara una pieza de la expresión, devolviendo el resultado como un valor de retorno del método como en este caso : atom returns [int value] : // value of an INT is the int computed from char sequence INT {$value = Integer.parseInt($INT.text);} | ID // variable reference { // look up value of variable Integer v = (Integer)memory.get($ID.text); // if found, set return value else error if ( v!=null ) $value = v.intValue(); else System.err.println("undefined variable "+$ID.text); } | // value of parenthesized expression is just the expr value ’(’ expr ’)’ {$value = $expr.value;} ; Por la acción de la cuarta lista detallada anteriormente, el resultado de un Átomo INT es sólo el valor entero del texto del token INT. Una token INT con texto 91 da como resultado el valor 91. La acción 5 nos dice que debemos buscar el texto del token ID en el mapa de memoria para ver si tiene un valor. Si es ası́, sólo devuelven el valor entero almacenado en el mapa, o bien imprimir un error. Mientras la tercera regla alternativa de atom invoca recursivamente la regla expr. Hay nada para calcular, por lo que el resultado de esta evaluación átomo es justo el resultado de la llamada a expr(), lo que satisface la acción 6. Pasando a multiplicativo de subexpresiones, aquı́ está la regla multExpr donde ademas se agrega la funcionalidad de la división que cumple el punto 11 de la lista : /** return the value of an atom or, if ’*’ present, return * multiplication of results from both atom references. * $value is the return value of this method, $e.value * is the return value of the rule labeled with e. */ multExpr returns [int value] : e=atom {$value = $e.value;} ((’*’ e=atom {$value *= $e.value;}) 16.

(21) 2.1. APRENDIENDO ANTLR : UNA CALCULADORA | (’/’ e=atom {$value /= $e.value;} ) )* ; Para cualesquier multiplicaciones que siguen el primer átomo, todo lo que tienes que hacer es mantener la actualización el resultado multExpr, $valor, por acción 7. Cada vez que vemos a * y un átomo, se multiplica el resultado multExpr por el resultado del átomo. Las acciones en regla expr, la regla de expresión más externa, es reflejo de la acciones en multExpr excepto que se suma y resta en lugar de multiplicando : /** return value of multExpr or, if ’+’|’-’ present, return * multiplication of results from both multExpr references. */ expr returns [int value] : e=multExpr {$value = $e.value;} ( ’+’ e=multExpr {$value += $e.value;} | ’-’ e=multExpr {$value -= $e.value;} )* ; Estas acciones se corresponden con 8 y 9, de la lista. Una de las grandes lecciones a aprender aquı́ es que la sintaxis impulsa la evaluación de las acciones en el analizador. La estructura de una secuencia de entrada indica qué tipo de cosa es. Por lo tanto, para ejecutar acciones sólo para una construcción particular, todo lo que tenemos que hacer es colocar acciones en la gramática alternativa que coincide con esa construcción. Pero ¿Qué hace antlr con las acciones gramáticas? Antlr simplemente inserta acciones justo después de que genera código para los elementos anteriores(parsers) que deben ejecutar acciones integradas después de que coincida con el elemento anterior de la gramática. Bien, estamos listos para poner a prueba la gramática. Hemos agregado acciones sólo a la gramática, ası́ que el main() en el programa de prueba puede permanecer igual. Tenga en cuenta que si cambiamos la gramática, tenemos que volver a compilar los archivos generados, tales como ExprParser.java y ExprLexer.java para nuestra causa. La ejecución de expresiones en el programa devuelve ahora los cálculos previstos : $ java Test 3+4*5 EOF 23 $ java Test (3+4)*5 EOF 35 $ java Test a=3 b=4 2+a*b 14 Donde $es un carácter ya existente en la linea de comandos, EOF señala el carácter de final de archivo y Test es el nombre de la Clase y archivo de java que contiene el main(); Notese que puede tener como entrada un archivo y entonces podrı́a teclear algo como java Test <input ˝donde input es el nombre del archivo. Incluso puede observar que ocurre con entradas no validas Con esto concluye el primer ejemplo antlr completo. El programa utiliza una gramática para que coincida con las expresiones y utiliza acciones integradas para evaluar expresiones. Ahora veremos una solución más sofisticada para el mismo problema. La solución es más complicada, pero vale la pena porque demuestra cómo construir una estructura de datos de árbol y caminar con otra gramática. Esta estrategia es útil para muchas complicadas traducciones ya que son mucho más fáciles de manejar. Evaluación de expresiones mediante un formulario AST Intermedio Vamos ahora a guiarnos a través de la construcción de la misma funcionalidad, pero utilizando un paso adicional que implica árboles. Utilizaremos la misma gramática del parser para construir una estructura de datos intermedio, mediante sustitución de las acciones integradas con las reglas de construcción de los árboles. Una vez que tengamos ese árbol, vamos a utilizar un programa 17.

(22) CAPÍTULO 2. EJERCICIOS DE INTRODUCCIÓN de análisis de árbol para recorrer el árbol y ejecutar acciones integradas. Antlr va a generar un analizador de árbol de un árbol de la gramática automáticamente para nosotros. El analizador de gramática convierte un flujo de señal en un árbol que la gramática de árbol analiza y evalúa. Abstract Sintax Tree (AST) se llama a la técnica de uso para este caso. En muchos casos, podrás ver los árboles representados en forma de texto. Por ejemplo, la representación de texto de 3 +4 es (+ 3 4). El primer sı́mbolo después de (es el raı́z y los sı́mbolos posteriores o sus hijos. La AST para la expresión 3 + 4 * 5 tiene la forma de texto (+ 3 (* 4 5)) y se ve ası́ :. Figura 1: ejemplo AST de 3 + 4 * 5. construyendo ASTs con una gramática Para la construcción de AST con antlr tenemos que añadir las reglas de construcción AST a la gramática parser que indican la forma del árbol que queremos construir. Cuando se utiliza la opción de salida = AST, cada una de las reglas de la gramática implı́citamente devolverá un nodo o subárbol. El árbol que se obtiene invocando la regla de partida es el AST completo. Tomemos el analizador gramatical bruto sin acciones de el principio de esta sección, aumentaremos hasta construir un adecuado AST. A medida que se adelante, hablaremos de la estructura adecuada AST. Comenzamos diciendo a antlr que construya un nodo de árbol para cada token encontrado en el flujo de entrada : grammar Expr; options { output=AST; // ANTLR can handle literally any tree node type. // For convenience, specify the Java type ASTLabelType=CommonTree; // type of $stat.tree ref etc... } Para cada token que encuentre el reconocedor, se creará un único nodo AST. No dadas instrucciones en contrario, el reconocedor generado construirá un árbol plano (una lista enlazada) de los nodos. Para especificar una estructura de árbol, simplemente hay que indicar qué tokens deben ser considerados operadores (raı́ces de subárbol), y cuales tokens deben excluirse del árbol.Esto se hace con ∧ y! sufijos de token de referencia, respectivamente; A partir de la gramática del analizador sin acciones, modificamos las reglas de expresiones como sigue : expr: multExpr ((’+’ ^|’-’ ^) multExpr)* ; multExpr : atom (’*’ ^ atom |’/’ ^ atom)* ; atom: INT | ID | ’(’ ! expr ’)’ ! ; Para la regla prog y stat, vamos a utilizar la sintaxis de reescritura de árbol ya que es más clara. Para cada alternativa, añadimos regla de construcción a →AST de la siguiente manera : /** Match a series of stat rules and, for each one, print out * the tree stat returns, $stat.tree. toStringTree() prints 18.

(23) 2.1. APRENDIENDO ANTLR : UNA CALCULADORA * the tree out in form: (root child1 ... childN) * ANTLR’s default tree construction mechanism will build a list * (flat tree) of the stat result trees. This tree will be the input * to the tree parser. */ prog: ( stat {System.out.println($stat.tree.toStringTree());} )+ ; stat: expr NEWLINE -> expr | ID ’=’ expr NEWLINE -> ^(’=’ ID expr) | NEWLINE -> ; Los elementos de la gramática a la derecha del operador - >son fragmentos de gramática de árbol que indican la estructura del árbol que queremos construir. El primer elemento dentro de una ˆ(...) especificación de árbol es la raı́z del árbol, los elementos restantes son hijos de esa raı́z. Podrı́amos pensar en el reescribir las reglas gramaticales como transformaciones a la gramática. Nos veremos en un momento en que dichas normas exactas de construcción de árboles se conviertan en alternativas de la gramática de árbol. La regla prog sólo imprime los árboles y, más aún, no necesita ninguna construcción del árbol explı́cito. El comportamiento de construcción del árbol por defecto de prog construye lo que queremos: una lista de sentencias árboles a analizar con la gramática árbol. La regla de reescritura para la primera alternativa que afirma que el valor de retorno de stat es el árbol retornado de la llamada a expr. La segunda alternativa de reescritura dice que para construir un árbol con '='en la raı́z y la ID como el primer hijo. el árbol devuelto desde la llamada a expr es el segundo hijo. La reescritura de vacı́o para la tercera alternativa, simplemente significa que no crea un árbol en absoluto. Las reglas léxicas y el programa principal en la prueba no necesita ningún cambio. Veamos lo que el traductor hace un archivo entrada llamado input que contiene: a=3 b=4 C=12 2+a*b 2+c/b entonces ejecutamos el programa después de generar el código y compilar de la siguiente forma por ejemplo : $ java org.antlr.Tool Expr.g ANTLR Parser Generator Version 3.0 1989-2007 $ javac Test.java ExprParser.java ExprLexer.java $ $ java Test < input (= a 3) (= b 4) (+ 2 (* a b)) (+ 2 (/ c a)) $ Ahora tenemos un programa de análisis que construye AST, y necesitamos una manera de caminar esos árboles para evaluar las expresiones que representan, ası́ que vamos a añadir acciones para calcular los resultados de subexpresión. Al igual que la previa solución, cada regla de expresión devolverá los resultados parciales. ANTLR construirá un analizador de árbol que ejecuta sus acciones integradas. Construyamos la gramática de árbol en un archivo separado, que llamaremos Eval.g. Gramáticas de árbol comienzan muy parecido a las gramáticas parser con una gramática cabecera y algunas opciones : tree grammar Eval; // yields Eval.java options { tokenVocab=Expr; // read token types from Expr.tokens file ASTLabelType=CommonTree; // what is Java type of nodes? } ... La opción tokenVocab indica que la gramática árbol debe precargar los nombres simbólicos y las correspondientes tipos de tokens definidos en Expr.tokens (Antlr genera ese archivo después del procesamiento Expr.g).Antes de escribir las reglas, definimos una tabla hash de memoria para almacenar valores de variables, al igual que hicimos para la solución gramática del parser en la versión anterior de nuestra calculadora : 19.

(24) CAPÍTULO 2. EJERCICIOS DE INTRODUCCIÓN @header { import java.util.HashMap; } @members { /** Map variable name to Integer object holding value */ HashMap memory = new HashMap(); } Pero la versiones de los ASTs deben ser simplificadas y normalizadas del flujo de tokens que implı́citamente codifica estructura gramatical. Por consiguiente, las gramáticas de árboles suelen ser mucho más simple que las gramáticas de parser asociadas que construyen sus árboles. Este analizador gramatical normaliza los árboles de expresión para tener un operador en la raı́z y sus dos operandos como los hijos. Necesitamos una regla expr que refleje esta estructura : expr returns [int value] : ^(’+’ a=expr b=expr) {$value = a+b;} | ^(’-’ a=expr b=expr) {$value = a-b;} | ^(’*’ a=expr b=expr) {$value = a*b;} | ^(’/’ a=expr b=expr) {$value = a/b;} | ID { Integer v = (Integer)memory.get($ID.text); if ( v!=null ) $value = v.intValue(); else System.err.println("undefined variable "+$ID.text); } | INT {$value = Integer.parseInt($INT.text);} ; La regla expr indica que un árbol de expresión es un nodo sencillo creado de un ID o una token INT o que un árbol de expresión es un operador subárbol. La regla expr normaliza todos los cálculos para ser de la forma resultado = a ¡operador¿ b.”Las acciones para nodos ID e INT son idénticas a las acciones que se utilizan en regla átomo de la gramática parser. Las acciones de reglas prog y stat son idénticas a la solución anterior. La regla prog no tiene una acción, simplemente se ajusta con una secuencia de expresión o árboles de asignamiento. La regla stat hace una de dos cosas: 1. encuentra una expresión e imprime el resultado. 2. encuentra una asignación y mapea el resultado a la indicada variable. Ası́ es como decirle a antlr: prog: stat+ ; stat: expr {System.out.println($expr.value);} | ^(’=’ ID expr) {memory.put($ID.text, new Integer($expr.value));} ; La regla stat no tiene una tercera alternativa para que coincida con la nueva lı́nea (vacı́o) expresión como la solución anterior. Las tiras del analizador sacan expresiones vacı́as por no construir árboles para ellas. ¿Qué acerca de las reglas léxicas? Resulta que no es necesaria ninguna porque las gramáticas de árbol se alimentan de un flujo de nodos del árbol, no tokens. En este punto, tenemos un analizador gramático que construye un AST y una gramática de árbol que reconoce la estructura del árbol, la ejecución de acciones para evaluar expresiones. Traduciendo ahora la gramática Eval.g a código Java nos genera 2 archivos (Eval.java que es el analizador generado de la gramática y Eval.tokens que define el tipo de token y aunque este no se use, antlr siempre genera este archivo.).Ahora tenemos que modificar el archivo de prueba para que recorra el árbol construido por el analizador. Hasta este punto, lo único que hace es poner en marcha el programa de análisis, por lo que debemos agregar código para extraer el árbol de resultados del analizador, crear un andador de árbol de tipo Eval, y empezar a recorrer el árbol con la regla prog. como esto : 1 2 3. import o r g . a n t l r . r u n t i m e . ∗ ; import o r g . a n t l r . r u n t i m e . t r e e . ∗ ;. 20.

(25) 2.1. APRENDIENDO ANTLR : UNA CALCULADORA 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24. public c l a s s Test { public s t a t i c void main ( S t r i n g [ ] a r g s ) throws E x c e p t i o n { // C r e a t e an i n p u t c h a r a c t e r stream from s t a n d a r d i n ANTLRInputStream i n p u t = new ANTLRInputStream ( System . i n ) ; // C r e a t e an ExprLexer t h a t f e e d s from t h a t stream ExprLexer l e x e r = new ExprLexer ( i n p u t ) ; // C r e a t e a stream o f t o k e n s f e d by t h e l e x e r CommonTokenStream t o k e n s = new CommonTokenStream ( l e x e r ) ; // C r e a t e a p a r s e r t h a t f e e d s o f f t h e t o k e n stream E x p r P a r s e r p a r s e r = new E x p r P a r s e r ( t o k e n s ) ; // Begin p a r s i n g a t r u l e prog , g e t r e t u r n v a l u e s t r u c t u r e E x p r P a r s e r . p r o g r e t u r n r = p a r s e r . prog ( ) ; // WALK RESULTING TREE CommonTree t = ( CommonTree ) r . g e t T r e e ( ) ; // g e t t r e e from p a r s e r // C r e a t e a t r e e node stream from r e s u l t i n g t r e e CommonTreeNodeStream nodes = new CommonTreeNodeStream ( t ) ; Eval w a l k e r = new Eval ( nodes ) ; // c r e a t e a t r e e p a r s e r w a l k e r . prog ( ) ; // l a u n c h a t s t a r t r u l e p r o g } }. El dispositivo de prueba extrae el AST del analizador de obtenerlo del valor de retorno de prog. Este objeto es de tipo prog return, que Antlr genera dentro ExprParser : 1 2 3 4 5. // from t h e p a r s e r t h a t b u i l d s AST f o r t h e t r e e grammar public s t a t i c c l a s s p r o g r e t u r n extends P a r s e r R u l e R e t u r n S c o p e { CommonTree t r e e ; public O b j e c t g e t T r e e ( ) { return t r e e ; } };. Tenemos una completa evaluador de expresiones ahora, para que podamos probarlo. introducimos algunas expresiones a través de la entrada estándar : $ java Test 3+4 EOF (+ 3 4) 7 $ java Test 3*(4+5)*10 EOF (* (* 3 (+ 4 5)) 10) 270 $ java Test a=4 b=12 2+a/b EOF (= a 4) (= b 12) (+ 2 (/ a b)) 5 $ Inclusive puedes nuevamente redireccionar la entrada de un archivo como el ejercicio anterior. Ejecución en Android : solo necesitamos :. Ahora que tenemos un evaluador básico llevemoslo a ejecutarse en android, para el cual. Crear un nuevo proyecto en eclipse; desde luego que este cuente con el plugin de android. Añadir en la carpeta src dentro del proyecto las clases generadas por antlr de la calculadora. Dentro de la clase principal de el proyecto(usualmente MainActivity que extiende de Activity) esta el método onCreate que inicializara las actividades y los elementos de la interfaz, ahı́ se colocara el código que extraiga la expresión que el usuario introduce y se menda llamar la función que haga el proceso e imprimimos el resultado. implementamos la función que realiza la evaluación de la expresión en esa misma clase, esta función contendrá el método que contiene nuestra antes mencionada clase test pero con el valor de retorno que es simplemente el resultado. 21.

(26) CAPÍTULO 2. EJERCICIOS DE INTRODUCCIÓN No olvidemos importar el antlrxx.jar (donde xx es la versión que recomiendo sea la 3 o superior) ejecutamos el proyecto y listo. El ejemplo de la clase Principal : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71. package o r g . example . m i c a l c u l a d o r a ;. import import import import import. org . org . org . org . org .. antlr antlr antlr antlr antlr. . r u n t i m e . ANTLRStringStream ; . r u n t i m e . CommonTokenStream ; . runtime . RecognitionException ; . r u n t i m e . t r e e . CommonTree ; . r u n t i m e . t r e e . CommonTreeNodeStream ;. import import import import import import import import. a n d r o i d . o s . Bundle ; a n d r o i d . app . A c t i v i t y ; a n d r o i d . view . Menu ; a n d r o i d . view . View ; a n d r o i d . view . View . O n C l i c k L i s t e n e r ; a n d r o i d . w i d g e t . Button ; a n d r o i d . w i d g e t . EditText ; a n d r o i d . w i d g e t . Toast ;. public c l a s s M a i n A c t i v i t y extends A c t i v i t y { private private private private. Button b t n E v a l u a r ; EditText t x t E x p r e s i o n ; EditText t x t R e s u l t a d o ; ANTLRStringStream i n ;. @Override public void o n C r e a t e ( Bundle s a v e d I n s t a n c e S t a t e ) { super . o n C r e a t e ( s a v e d I n s t a n c e S t a t e ) ; s e t C o n t e n t V i e w (R. l a y o u t . l a y o u t m a i n ) ; b t n E v a l u a r = ( Button ) findViewById (R. i d . b u t t o n 1 ) ; b t n E v a l u a r . s e t O n C l i c k L i s t e n e r (new O n C l i c k L i s t e n e r ( ) { public void o n C l i c k ( View view ) { t x t E x p r e s i o n = ( EditText ) findViewById (R. i d . e d i t T e x t 1 ) ; t x t R e s u l t a d o = ( EditText ) findViewById (R. i d . e d i t T e x t 2 ) ; S t r i n g e x p r e s i o n = txtExpresion . getText ( ) . t o S t r i n g ( ) ; i f ( e x p r e s i o n . l e n g t h ( ) == 0 ) { m u e s t r a E r r o r ( ” f a v o r de i n g r e s a r un v a l o r numerico ” ) ; } else { String resultado = evaluarExpresion ( expresion ) ; txtResultado . setText ( resultado ) ; } } }) ; } @Override public boolean onCreateOptionsMenu (Menu menu ) { g e t M e n u I n f l a t e r ( ) . i n f l a t e (R. menu . l a y o u t m a i n , menu ) ; return true ; } public void m u e s t r a E r r o r ( S t r i n g mensaje ) { Toast . makeText ( this , mensaje , Toast .LENGTH LONG) . show ( ) ; } public S t r i n g e v a l u a r E x p r e s i o n ( S t r i n g e x p r e s i o n ) { System . out . p r i n t l n ( ” l a e x p r e s i o n e s : ” + e x p r e s i o n ) ; // C r e a t e an i n p u t c h a r a c t e r stream from s t a n d a r d i n //ANTLRInputStream i n p u t = new ANTLRInputStream ( ) ; i n = new ANTLRStringStream ( e x p r e s i o n + ” \n” ) ; // C r e a t e an ExprLexer t h a t f e e d s from t h a t stream ExprLexer l e x e r = new ExprLexer ( i n ) ; // C r e a t e a stream o f t o k e n s f e d by t h e l e x e r CommonTokenStream t o k e n s = new CommonTokenStream ( l e x e r ) ; // C r e a t e a p a r s e r t h a t f e e d s o f f t h e t o k e n stream E x p r P a r s e r p a r s e r = new E x p r P a r s e r ( t o k e n s ) ; // Begin p a r s i n g a t r u l e prog , g e t r e t u r n v a l u e s t r u c t u r e. 22.