Magíster en Ciencias, Mención Computación / Los sistemas de tipos-y-efectos (type-and-effect systems) permiten a los programadores hacer valer invariantes y restricciones sobre los efectos secundarios que se generan durante la evaluación de un programa. Los sistemas de tipos-y-efectos consideran efectos secundarios tales como estado, excepciones y E/S, entre otros. Desafortunadamente, los sistemas de tipos-y-efectos también obligan al programador a introducir anotaciones de efectos, lo que implica un esfuerzo adicional. En la práctica, los sistemas de tipos-y-efectos no son comúnmente usados. Conjeturamos que una de las razones importantes para la limitada adopción de los sistemas de efectos son las dificultades para realizar la transición desde un sistema donde los efectos secundarios son implícitos hacia una disciplina de efectos totalmente estática. Los tipos graduales (Gradual typing) permiten a los programadores combinar la flexibilidad de los lenguajes dinámicamente tipados con las garantías provistas por los sistemas de tipos estáticos. En lenguajes con tipos graduales, las anotaciones de tipos son parte del lenguaje, pero no son obligatorias. Un sistema de tipos gradual utiliza la información disponible para proveer garantías estáticas, rechazando los programas claramente incoherentes, e introduce verificaciones en tiempo de ejecución cuando la información estática no es suficiente para aceptar o rechazar definitivamente un programa. Esta tesis demuestra que las ideas de diseño detrás de los tipos graduales pueden aplicarse a los sistemas de tipos-y-efectos, tanto para aumentar la expresividad de estos sistemas así como para proveer flexibilidad para migrar programas con efectos secundarios impl ́ıcitos e irrestrictos hacia programas con una disciplina de efectos completamente estática. Se adaptaron ideas de tipos graduales para introducir verificación gradual de efectos para sistemas de tipos-y-efectos. La verificación gradual de efectos habilita al programador para decidir dónde y cuándo introducir anotaciones de efectos, agregando verificaciones en tiempo de ejecución cuando las anotaciones estáticas son insuficientes. Para evitar redefinir la verificación gradual de efectos para cada disciplina de tipos-y-efectos, introducimos verificación gradual de efectos para una plataforma genérica de tipos-y-efectos, en la que se puede instanciar cualquier disciplina de efectos monotónica, produciendo un sistema coherente. Presentamos la verificación gradual de efectos basándonos en conceptos de interpretación abstracta para construir la verificación gradual de efectos genérica. Utilizando verificación gradual de efectos genérica, introducimos tipos graduales para sistemas de tipos-y-efectos: un sistema donde las anotaciones de efectos y de tipos no son obligatorias, y donde se introducen verificaciones en tiempo de ejecución y casts cuando la información estática no es suficiente para asegurar la coherencia de un programa. De la manera definida, los tipos graduales para sistemas de tipos-y-efectos permiten migrar desde sistemas carentes de anotaciones de efectos o de tipos hacia una disciplina estática de tipos-y-efectos de manera segura.

El presente proyecto de fin de carrera corresponde a la construcción de un entorno de desarrollo que permita la ejecución y ejecución de pseudocódigo como herramienta de apoyo a las etapas de diseño, ejecución y validación de un algoritmo. Se permitirá la traducción a VBA, Java, Ruby, Python y c++. El documento presenta siete capítulos, en el primer capítulo se describen generalidades del proyecto como la problemática, objetivo general, objetivos específicos, resultados esperados, alcance, justificación, viabilidad y plan de actividades del proyecto. En el segundo capítulo se presenta el marco conceptual donde se describen los conceptos necesarios para entender el problema que se desea solucionar con el presente proyecto. En el tercer capítulo se presenta el estado del arte. En lo referente al estado del arte se realizó una búsqueda entre productos comerciales y no comerciales que intentan solucionar algunos aspectos del problema a resolver. En el cuarto capítulo, se describe cómo se realizó la definición y la validación de la gramática del pseudocódigo mediante el uso de la notación BNF. En el quinto capítulo se presenta el desarrollo del intérprete que permite la ejecución del pseudocódigo y del traductor que permitirá transformar el pseudocódigo a código en VBA, Java, Ruby, Python y C++. En el sexto capítulo se realiza la descripción del entorno de desarrollo que permitirá la integración del intérprete y traductor para que puedan ser utilizados por el usuario final. En el séptimo capítulo se exponen las conclusiones. / Tesis

Este proyecto de fin de carrera parte de la ausencia de herramientas que sirvan de ayuda para aquellos alumnos que quieran aprender a programar. Si bien existen programas que permiten generar diagramas de flujo y luego exportarlos a un lenguaje de programación, estos no poseen un compilador que permita detectar errores de sintaxis, que pueda poseer la solución. Por ello se plantea implementar un proceso de traducción y verificación de programas diseñados en diagrama de flujo utilizando como paso intermedio pseudocódigo, para que el alumno pueda preocuparse más en la lógica de su solución, que en la sintaxis o estructura del lenguaje de programación, a codificar. Para realizar este proyecto se definió una serie de objetivos específicos. En primer lugar se desarrolló un entorno para dibujar diagramas de flujo, para ello se adaptaron las librerías de Microsoft office que ofrecen las herramientas necesarias para la creación del entorno de trabajo. Luego, se definió la gramática que almacena la sintaxis del pseudocódigo utilizando la notación Backus-Naur Form (BNF). Después se implementó el método de conversión del formato XML de Microsoft office, representación del diagrama de flujo, a pseudocódigo utilizando la sintaxis definida anteriormente y un editor de texto en el cual se muestre el resultado de la conversión al usuario. Finalmente se implementó el intérprete que utiliza la gramática para verificar que el código se encuentre léxicamente, sintácticamente y semánticamente correcto. De esta manera los alumnos podrán obtener a partir de un diagrama, el cual al ser gráfico es de fácil entendimiento, el código de su programa sin necesidad de conocer la sintaxis del mismo y validado. / Tesis

En la actualidad los sistemas de distribución de agua potable implementados son monitoreados, controlados y supervisados desde un Centro de Control, para lo cual se emplean los sistemas SCADA. El objetivo del presente trabajo es desarrollar la aplicación en el software del sistema SCADA, para el proyecto de distribución de agua potable en la quebrada de Manchay. La distribución de agua se realiza a través de 23 estaciones de bombeo distribuidas a lo largo de todo el pueblo. El sistema de distribución de agua potable en Manchay consiste de 4 partes fundamentales: telecomunicaciones, instrumentación, sistema eléctrico y el sistema de control y automatización, esta última parte se relaciona directamente con el presente trabajo, el cual incluye el desarrollo de la programación para realizar el monitorio, control y supervisión de las estaciones de bombeo. Como parte de la implementación del sistema, se hizo configuración de instrumentos para que puedan transmitir la información a los controladores para tener lecturas del proceso como presión, flujo y nivel. Se procedió con el desarrollo de aplicaciones para los Paneles de Operador o Interfaces Hombre Maquina (HMI) con el propósito de realizar un control y monitoreo local de los equipos instalados en cada estación. Se realizaron pruebas en el Centro de Control para verificar el enlace de las señales de campo, así como pruebas con los equipos en las estaciones de bombeo que realizan el control automático y remoto (comandos desde el Centro de Control) del proceso de distribución de agua. / Tesis

Doctor en Ciencias, Mención Computación / Los cambios continuos en el código fuente de un programa pueden inadvertidamente introducir una regresión de rendimiento en tiempo de ejecución. Dichas regresiones se refieren a situaciones donde el rendimiento de un programa se degrada en comparación de versiones anteriores del mismo, aunque la nueva versión funcione correctamente. Ejecutar puntos de referencia en cada versión de un programa es una técnica tradicional utilizada para identificar regresiones en etapas tempranas. A pesar de ser efectiva, esta técnica exhaustiva es difícil de llevar a cabo en la práctica, principalmente por la alta sobrecarga que esta actividad demanda. En esta tesis, realizamos un estudio empírico sobre una variedad de programas, con el fin de evaluar cómo el rendimiento de un programa evoluciona en el tiempo, a medida que es modificado. Guiados por este estudio, proponemos Horizontal Profiling, una técnica de muestreo para inferir si una nueva versión de un programa introduce una variación de rendimiento, usando información de la ejecución de versiones anteriores. El objetivo de Horizontal Profiling es reducir la sobrecarga que requiere monitorear el rendimiento de cada versión, ejecutando los puntos de referencia solo en las versiones que contengan cambios costosos de código fuente. Presentamos una evaluación en la cual aplicamos Horizontal Profiling para identificar regresiones de rendimiento en un número de programas escritos en en el lenguaje de programación Pharo. En base a las aplicaciones que analizamos, encontramos que Horizontal Profiling es capaz de detectar más del 80% de las regresiones de rendimiento, ejecutando los puntos de referencia en menos del 20% de las versiones. Adicionalmente, describimos los patrones identificados durante nuestro estudio empírico, y detallamos cómo abordamos los numerosos desafíos que enfrentamos para completar nuestros experimentos. / Este trabajo ha sido parcialmente financiado por CONICYT a través de la beca CONICYT-PCHA/Doctorado Nacional para extranjeros/2013-63130199, OBJECT PROFILE y LAM RESEARCH

Doctor en Ciencias, Mención Computación / Gradual Typing permite a un programador aplicar tipos estáticos a ciertas partes de un programa, dejando el resto dinámicamente tipeado. Sin embargo, esto viene con un costo en el rendimiento. Una razón es que el runtime tiene que realizar siempre un casteo en el borde entre tipos estáticos y dinámicos. Otra razón es que el borde puede ser creado accidentalmente. Esto también trae un efecto lateral de reducir la fiabilidad del código estático, porque ahora el programador no puede garantizar que su código no arrojará errores de tipo en tiempo de ejecución. En este trabajo de tesis, mejoramos el rendimiento y la fiabilidad de los programas gradualmente tipeados. Para esto, desarrollamos un lenguaje gradualmente tipeado, Gradualtalk, y luego presentamos dos novedosas ideas: hybrid strategy y Confined Gradual Typing. La hybrid strategy es una nueva forma de insertar los casts al invocar métodos que combina dos estrategias existentes, permitiendo obtener el mejor rendimiento de ambas. Validamos esta afirmación con benchmarks. Confined Gradual Typing refina gradual typing con anotaciones para prohibir explícitamente ciertos cruces de frontera entre el código estáticamente y dinámicamente tipeado. Nosotros desarrollamos formalmente dos variantes de CGT que capturan diferentes compromisos entre flexibilidad/garantías. Probamos que CGT es type sound y que las anotaciones ofrecen las garantías esperadas.

Doctor en Ciencias, Mención Computación / Los lenguajes de tipado dinámico permiten un desarrollo ágil, el cual es util para construir prototipos rápidamente. Sin embargo, cuando estos pequeños programas se convierten en aplicaciones grandes, depurar se vuelve una tarea tediosa. Esto se debe principalmente a que los errores son solo detectables en tiempo de ejecución. Smalltalk, al ser un lenguaje de tipado dinámico, sufre de estos problemas. Los sistemas de tipos pueden disminuir ciertos errores de los lenguajes de tipado dinámico. Además, la inserción de tipos mejora la documentación de APIs, provee mejor soporte a los editores y ayuda a optimizar la compilación. Los sistema de tipos, especialmente diseñados para lenguajes existentes, son llamados sistema de tipos retro-alimentados (retrofitted type systems en inglés). Diseñar un sistema de tipos retro-alimentado es una tarea complicada. Esto se debe a que tales sistemas de tipos deben soportar patrones de programación muy particulares (llamados idioms), minimizar la refactorización de código por la inserción de tipos, y proveer una integración entre las partes (ej. módulos) con y sin tipos. Estos problemas son exacerbados cuando el lenguaje destino es altamente dinámico, como Smalltalk. Si bien se ha intentado insertar tipos en Smalltalk, el ejemplo mas notable es Strongtalk, ellos no han sido diseñados de un modo de ser sistemas de tipos retro-alimentados. Ademas Strongtalk es un sistema de tipos opcional, es decir que las garantías estáticas no necesariamente se cumple en tiempo de ejecución. En este trabajo de tesis, nosotros presentamos Gradualtalk, un sistema de tipos retro-alimentado para Smalltalk, que soporta la mayoría de las características particulares e idioms de Smalltalk. En la parte del diseño, nosotros analizamos detalladamente cual es el mejor sistema de tipos gradual y aquellas extensiones que mejor encajan en Gradualtalk. Cada una de estas extensiones son claramente justificadas usando evidencia (empírica) disponible en la literatura o propuesta por nosotros. En detalle, nosotros presentamos como evidencia empirical dos estudios a larga escala sobre las características dinámicas de Smalltalk y sobre los predicados de tipos. Ademas presentamos tres estudios preliminares sobre el uso de self, el uso de variables que pueden representar varios valores de diferente tipos, y el uso de colecciones. Con toda esta información implementamos una primera version de Gradualtalk. Finalmente, validamos Gradualtalk mediante la inserción de tipos de varios proyectos Smalltalk reales.

No description available.

En el 2014, el grupo de investigación AVATAR lanzó su juego de estrategia en tiempo real “1814: La rebelión del Cuzco”, y ahora desean expandir el contenido del juego con nuevos mapas y niveles. Sin embargo, crear contenido de este tipo requiere iniciar un ciclo de desarrollo extenso y costoso, el cual produce una cantidad limitada de mapas. Frente a esta necesidad, se propone un editor de mapas para el juego. Una herramienta que permite crear una cantidad ilimitada de mapas y, a diferencia de un algoritmo de generación de niveles, aprovecha la creatividad de los jugadores para generar nuevo contenido e interés en el juego. El editor se construyó siguiendo la estructura de un compilador que recibe como entrada un lenguaje visual. Se elaboró primero una interfaz gráfica donde se edita el mapa de forma intuitiva, el cual luego es procesado por el compilador y traducido a una estructura de datos interpretable por el motor de juego. Por último, se realizó una prueba con usuarios para validar la usabilidad del editor y el correcto funcionamiento de los mapas editados. Al finalizar el proyecto de fin de carrera se logró construir satisfactoriamente un editor de mapas para “1814: La rebelión del Cuzco”, capaz de ser utilizado, tanto por jugadores expertos como casuales, para crear fácilmente nuevos mapas y luego integrarlos al juego. / Tesis

La programación orientada a aspectos (POA) es un paradigma de programación. Permite encapsular funcionalidad que se encuentra dispersa en un sistema. Para ello utiliza pointcuts, predicados que definen eventos del programa, y advices, el código que es ejecutado en los eventos definidos por un pointcut. Un aspecto es una entidad que agrupa pointcuts y advices. AspectJ es un lenguaje de programación para POA. Está diseñado como una extensión de Java, de forma que cualquier programa Java es también un programa AspectJ válido. Además del compilador oficial del proyecto AspectJ existen otros, de los cuales AspectBench Compiler (abc) es el más avanzado. La reentrancia de aspectos ocurre cuando la ejecución de un aspecto desencadena nuevamente su propia ejecución; produciéndose bucles infinitos. Actualmente la reentrancia se soluciona utilizando chequeos y patrones adhoc. La introducción de niveles de ejecución evita la reentrancia de aspectos. La ejecución del programa se separa en distintos niveles. Por defecto, la computación base ocurre en el nivel 0, mientras que los aspectos que observan esta ejecución se ubican en el nivel 1. La ejecución en el nivel 1 sólo puede ser observada desde el nivel 2, y así sucesivamente. Esta estructura para la ejecución de los programas soluciona casi todos los casos de reentrancia. Para el caso faltante, se utiliza un mecanismo adicional de control de reentrancia. Para esta memoria se extendió el compilador abc para incorporar una adaptación de niveles de ejecución. El lenguaje soportado por el compilador extendido incorpora nueva sintaxis para ello. Y los programas compilados contienen rutinas adicionales que agregan la estructura de niveles de ejecución y el control de reentrancia. Además, es posible controlar el nivel de ejecución en que se ejecutará una expresión, si fuese necesario. Se hicieron distintas pruebas para validar el trabajo realizado. Se confeccionaron tests para las distintas funcionalidades que, en conjunto, implementan niveles de ejecución. También se verificó la correcta compilación y ejecución de AJHotDraw, un framework para interfaces gráficas de programas de dibujo. Adicionalmente se probó el compilador con RacerAJ, una herramienta para la detección de data races implementada en AspectJ. RacerAJ es de interés porque incorpora pointcuts para evitar la ocurrencia de reentrancia de aspectos; removidos estos pointcuts, el programa funciona correctamente al ser compilado con esta versión extendida de abc. Además se realizó un ligero análisis de performance para medir el impacto en los programas compilados. Para ello se utilizó una suite de benchmarks para AspectJ. Se compararon los tiempos de ejecución logrados al utilizar el compilador desarrollado y la versión original.