|
En esta pagina se encuentran los tópicos de memorias y tesis del laboratorio PLEIAD. Notar que la mayoría de los tópicos pueden ser adaptados en memorias de Ingeniera o tesis de Magíster. Las propuestas de estudiantes son bienvenidas en el laboratorio PLEIAD. Por favor, comunicase directamente con los profesores Éric, Johan or Alexandre. Temas de tésis por áreaTópicos relacionado a AspectScript Área Visualización, Interacción, calidad de Software Proyecto ECOCAM: Estrategias COgnitvas para el CÁlculo Mental Tópicos relacionado a AspectScriptAspectScript es una extensión de JavaScript para soportar Programación Orientada a Aspecto (POA). Actualmente, AspectScript bajo el navegador Mozilla Firefox sin necesidad de plug-ins o add-ons. Esta extensión es un lenguaje de aspecto que se integra con características de JavaScript como first-class y higher-order, dynamic typing, y prototype-based programming. Para mayor información, visita el AspectScript website. Extender Firebug para depurar de aplicaciones de AspectScript Obtener una version de AspectScript compatible con actuales browsers Optimizar la eficiencia del runtime de applicaciones de AspectScript Área Lenguajes y AspectosVisualización de comportamiento de aspectos at runtime An aspect language for language definition toolkits Achieving Robust Software using Aspect-Oriented Programming Expressive Scoping of Dynamic Aspects in Java Scoping of Distributed Aspects An Aspect Language for Ambient Actors Extensión del compilador AspectJ Reduce redundancy in execution traces through static analysis Debugging facilities for an interpreted language Área Depuración OmniscienteLa depuración omnisciente (omniscient debugging) es un paradigma de depuración que permite volver hacia atrás en el tiempo durante la depuración de un programa asi como inmediatamente atravesar “vínculos causales”, lo que permite contestar instantáneamente preguntas como “por qué la variable x tiene el valor null?”. Estamos desarrollando TOD, un depurador omnisciente para Java, AspectJ y Python, integrado al entorno de desarrollo Eclipse. Los temas siguientes están relacionados a depuración omnisciente y/o a TOD: Visualización de comportamiento de aspectos at runtime Área Visualización, Interacción, calidad de SoftwareAspectMapsAspectMaps tiene su propria pagina, con algunos videos: aspectmaps. AspectMaps es una herramienta que visualiza la estructura de software que usa Aspectos, mas específicamente codigo Java + AspectJ. Esta construido usando varios elementos de Moose (vean mas abajo). Queremos extender AspectMaps, con un enfoque de integración con Eclipse. Eclipse plugin exporting Java to MSE Trabajos con MooseMoose es una herramienta para el análisis de software. Se usa para visualizar e identificar defectos en el diseño y arquitectura de aplicaciones. Mas información al respecto de moose se puede encontrar en http://www.moosetechnology.org. Los siguientes temas están directamente relacionados con Moose y permiten colaboración internacional en investigación. Adding 3D Renderer to Mondrian Importer for your favorite language Eclipse plugin exporting Java to MSE Architectural components in Moose Enlaces relevantes:
Proyecto ECOCAM: Estrategias COgnitvas para el CÁlculo MentalPleiad está interesado en ayudar a mejorar la educación. Por esta razón, nuestro laboratorio junto al laboratorio Centro De Investigación Avanzada en Educación (CIAE) estamos trabajando el proyecto “Estrategias Cognitivas para el Cálculo Mental”. La meta del proyecto es encontrar técnicas, estrategias y metodologías que fomenten el uso de estrategias cognitivas en el proceso de aprendizaje de los alumnos. Área SunSPOTThe Sun SPOT Device is a small, wireless, battery powered experimental platform. It is programmed almost entirely in Java to allow regular programmers to create projects that used to require specialized embedded system development skills. The hardware platform includes a range of built-in sensors as well as the ability to easily interface to external devices. Some uses of Sun SPOTs are: The following thesis topics are related to SunSPOTs: A Context-Aware System Using SPOT A Dedicated Language for SPOTs Domain-Specific extensions to Java for SPOTs Thesis topicsVisualización de comportamiento de aspectos at runtimeType: Ingeniera/MSc Un inconveniente para el desarrollador que usa aspectos es que puede resultar difícil determinar donde y cuando se aplican los aspectos en el sistema construido. Eso dificulta la comprensión del comportamiento del sistema, la cual es necesaria, entre otras cosas, para la depuración. Existen algunas visualizaciones que muestran en forma estática donde aspectos van a ser (o podrían ser) aplicados; El AspectJ Development Toolkit de Eclipse es un ejemplo de tal visualización. El problema con esas visualizaciones es que, por ser estáticas, no son adecuadas para mostrar lo que realmente ocurre cuando el sistema se ejecuta. Además, no pueden soportar ningún tipo de aspectos dinámicos. En consecuencia se necesita alguna visualización de los aspectos en tiempo de ejecución (runtime), incluyendo mostrar el ordenamiento y la interacción entre aspectos. El objetivo de esta tesis es construir una semejante visualización, basada en la infraestructura de logging comportamenal de la que disponemos [1, 2], y usando herramientas y técnicas de visualización modernas.
[1] Scalable Omniscient Debugging, G. Pothier, E. Tanter, J. Piquer, Proceedings of ACM OOPSLA 2007. An aspect language for language definition toolkitsType: Ingeniera/MSc New programming languages, especially consdering domain-specific languages, are seldomly written completly from scratch. Usually some lex/yacc like parser builder is used in conjunction with parse tree transformation tools. Let us call this conjunction 'language definition toolkits'. To program language definition toolkits, programming languages specifically created for these toolkits are used. To define a new programming language, a program is written in the toolkit programming language(s). It is known that a number of cross-cutting concerns exist in these programs, i.e. in code defining a new programming language. However because the toolkit programming languages used are not general-purpose, there are no adequate aspect languages that allow us to aspectize these concerns. Some research has been done in this area, but the results can certainly be improved. The goal of this thesis is to build 'the ultimate' aspect language for a specific language definition toolkit, probably using the toolkit to build the aspect language itself. Achieving Robust Software using Aspect-Oriented ProgrammingType: Ingeniera/MSc Unfortunately, bugs are an inherent part of any large software system. However, some bugs can be classified as tolerable (the user is annoyed by the undesired behavior but the program still does its job) whereas other bugs can be classified as intolerable. Intolerable bugs make the system crash causing unsaved documents to be lost; distributed services to become unavailable to their clients… The subject of this proposal is to study how we can transform a program, using an aspect-oriented approach, such that intolerable bugs are automatically turned into tolerable bugs. The objectives of this thesis are:
[1] Rinard, M. 2003. Acceptability-oriented computing. In Companion of the 18th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (Anaheim, CA, USA, October 26 - 30, 2003). OOPSLA '03. ACM, New York, NY, 221-239. DOI= http://doi.acm.org/10.1145/949344.949402 Expressive Scoping of Dynamic Aspects in JavaType: Ingeniera/MSc Dynamically-deploying aspects allows much greater flexibility and adaptability than all-static approaches like AspectJ. In recent work, we have explored a very expressive model for expressive scoping of dynamically-deployed aspects [1]. Scoping refers to the ability to define proper boundaries for aspect application, delimiting a part of the execution trace that the aspect can affect. The model is formulated as a set of Scheme interpreters. The goal of this thesis is to study how the model can be efficiently incarnated in a dynamic aspect infrastructure for Java such as Reflex [2] or CaesarJ [3].
[1] Expressive Scoping of Dynamically-Deployed Aspects. E. Tanter. Proceedings of ACM AOSD 2008. Scoping of Distributed AspectsType: Ingeniera/MSc There exists a number of systems for distributed aspects in Java, such as the AWED language [1] and the ReflexD infrastructure [2]. These proposals however do not consider expressive scoping of aspects. As a result, using aspects in a distributed setting is still subject to many unforeseen issues, such as aspect propagation between hosts, class versioning errors, etc. The goal of this thesis is to study a proper scoping model for distributed aspects by extending the work of [3], and its implementation, either in an “idealized” setting such as Scheme interpreters, or in a dynamic distributed aspect infrastructure for Java such as ReflexD.
[1] Explicitly Distributed AOP using AWED. L.D. Benavides et al. Proceedings of AOSD 2006. Reentrant Aspects in AspectJType: Ingeniera/MSc A huge number of problems in using AspectJ are due to aspects that apply several times when one would expect them to apply only once [1]. The way to address this issue in AspectJ is to manually extend all pointcut definitions with extra conditions. We propose to extend AspectJ with a notion of reentrancy for aspects. Similarly to reentrant locks, a reentrant aspect does not trigger advice when matching a join point in the control flow of an actively-matched join point. The goal of this thesis is to refine this notion and implement it as an extension of AspectJ using the abc compiler [2].
[1] archives of the aspect-users mailing list An Aspect Language for Ambient ActorsType: Ingeniera/MSc The goal of this topic is to define an aspect language for Ambient Actors in the AmbientTalk language [1], in order to address crosscutting concerns in mobile ad hoc networks at an appropriate level of abstraction. Depuración Omnisciente: Estudio de CasosType: Ingeniera/MSc A pesar que las ventajas de la depuración omnisciente sobre los enfoques tradicionales parecen sumamente claras, al día de hoy no existe ningún dato empírico que lo demuestre. El objetivo de este trabajo es llevar a cabo experimentos que demuestren el interés de este enfoque comparando el tiempo requerido para resolver un conjunto de bugs usando paradigmas de depuración tradicionales, y depuración omnisciente. Para lograr este objetivo sera necesario: - Recolectar una cantidad de casos de uso en Java, Python o AspectJ. Esto involucra buscar programas candidatos en sitios de hosting de proyectos open-source (eg. SourceForge), estudiar su base de datos de bugs, e identificar algunos casos “interesantes”. - Preparar un paquete experimental que provea un plan de experimento detallado, así como todo el material que fuese necesario para llevar a cabo el experimento (código fuente, lista de bugs, etc). El paquete debería ser lo suficientemente detallado para permitir que personas externas realicen el experimento (existen posibilidades de colaboración con la Universidad de Montreal y dos universidades brasileñas). - Llevar a cabo el experimento. Eso involucra reclutar “sujetos” y ejecutar el paquete experimental. Extensión del compilador AspectJType: Ingeniera/MSc Para el soporte de AspectJ, el depurador omnisciente TOD se basa actualmente sobre une mecanismo de tagging (etiquetado) que está implementado en abc, un compilador AspectJ experimental, pero no en ajc, el compilador oficial de AspectJ. Para una persona que trabaja con un entorno de desarrollo con soporte para AspectJ (eg. Eclipse), esto no es práctico porque el programa debe ser compilado manualmente por abc en vez de ocupar el sistema automático de compilación incremental del entorno. El mecanismo de tagging consiste en identificar el rol de cada bytecode Java en un programa AspectJ: en un método dado algunos bytecodes corresponden al código del programa base, mientras otros han sido insertados por el compilador AspectJ para implementar la semántica de alguna funcionalidad de AspectJ, por ejemplo una verificación dinámica de condición, o la llamada a un advice. El objetivo de este trabajo es extender el compilador ajc en colaboración con la comunidad de tal forma que (1) la extensión de tagging este integrada en versiones oficiales del compilador y (2) un estándar de tagging sea establecido que pueda también ser usado por otros compiladores AspectJ. Rich interactive application builderType: Ingeniera/MSc Interactive graphical applications are notoriously tedious to develop. Solutions exist that ease the task for simple, form-based applications: the GUI builders commonly found in IDEs permit to easily create forms with buttons, text fields, lists, etc. But even with those builders, the developer must still write a lot of code to provide the functionality of the interface and glue the different elements together. The situation is even worse for richer, non form-based interfaces (eg. a drawing program), as the developer has to write everything from scratch. Moreover, the procedural and object-oriented languages commonly used to build interactive applications are not very well suited to the task: some parts of the application would be best described in an event-based or workflow-based languages, some components rely on finite automata that the programmer must usually implement by hand, some interactions could be implemented more easily using a geometric constraint solving engine, etc. We started the development of a novel interactive application builder, named Uithin, with the following characteristics and goals: - Heterogeneous components: components can be widgets (buttons, text fields, etc.) but also finite state automata, model objects, constraint solvers, scripts, etc. Essentially a component is a black box with a set of valued slots that can be connected to other slots of other components. Whenever the value of a slot changes, it is propagated to its connected slots. Composite components can be created by assembling several components. - Graphical wiring of components: as a great part of the development of an interactive application consists in wiring different components together, this activity is performed graphically (instead of programatically setting up listeners). - Toolkit agnostic: the interface is designed in an abstract way, independantly of the GUI toolkit used (Swing, AWT, SWT, QT/Jambi…). An application can be designed using one toolkit and then executed (or further modified) using another toolkit. - Field-programmable: there is no separation between the development environment and the runtime environment. The application can be switched from design mode to running mode at any time. This means that the end-user is able to fully customize the application without having to download the source in a separate IDE, edit the program, compile it and run it. - Meta-circular: As Uithin itself is an interactive application, most of it will be programmed in itself! The idea is to have a minimal core (currently in Java) and develop the interactions using Uithin. Agregar "operadores" para extender ETMtype: Ingeniera En típicos lenguajes de AOP como AspectJ, los pointcuts no pueden directamente identificar a conjunto de eventos (join points). Un trace-based mechanism permite identificar conjuntos de eventos que cumplan ciertas condiciones (eg. que sean secuencias de eventos). Existen diferentes trace-based mechanisms tales como: tracematches / PQL / PTQL para Java, Halo para Lisp, etc. Cada uno de estos mecanismos tienen sus ventajas y desventajas. Actualmente, se esta construyendo un expresivo trace-base mechanism (ETM) para AspectScript (extensión de AOP para JavaScript) que permita integrar las características de diferentes trace-based mechanisms. Actualmente, hay una expresiva versión de un trace-based mechanism que trabaja bajo AspectScript. Esta versión usa Operadores, cual son solo funciones de JavaScript, para definir cómo nuestro trace-based mechanism identifica un conjunto de eventos. Usando estos operadores es posible permitir a los desarrolladores construir versiones personalizadas de estos mecanismos. El objetivo de esta tesis es desarrollar a conjunto de operadores que representen las diferentes características de los actuales trace-based mechanisms. Software para reconocer estrategias del cálculo mentalGeneralmente, un estudiante realiza tres pasos para resolver un ejercicio: 1) observa, 2) elije una estrategia de varias y finalmente 3) la ejecuta. Esta metodología parece estar bien para resolver ejercicios. Sin embargo, cuando un estudiante solamente conoce una única y universal, no es posible tomar ventajas de un particular ejercicio. Por ejemplo:
El objetivo de esta tesis es desarrollar un software con una rica interacción gráfica que permita reconocer la estrategia que un estudiante esta usando. Esta tesis puede ser financiada! Debugging facilities for an interpreted languageThe purpose of this thesis is to extend an interpreter in order to add support for debugging the programs written in the language the interpreter understands. Ideally, the necessary modifications should be done automatically, ie without manually touching the source code of the interpreter. This has the advantage of permiting the addition of new features to the interpreter wihtout having to worry about how to add support for debugging and also, abstracting the process could serve to add debugging capabilities to any interpreter. Extender Firebug para depurar de aplicaciones de AspectScripttype: Ingeniera The purpose of this thesis is to extend Firebug to support the debugging of AspectScript programs. The challenge is that AspectScript is based on code transformation so that debugging turns out to be almost impossible if the developer has to deal with the transformed source code. In addition, debugging-related tasks such as setting breakpoints and step-by-step debugging, are also significantly more involved. Optimizar la eficiencia del runtime de applicaciones de AspectScripttype: Ingeniera The purpose of this thesis is to optimize the runtime performance of AspectScript applications. AspectScript is heavily based on code transformation for dynamic weaving of aspects which introduces serious performance penalties. The idea of this thesis is to explore different optimizations and techniques to optimize the performance of the runtime weaving process. Obtener una version de AspectScript compatible con actuales browserstype: Ingeniera El proposito de esta tesis es obtener una versión de AspectScript compatible con los browsers Internet Explorer y Safari. Actualmente, AspectScript solamente trabaja bajo el browser de Mozilla Firefox. Para que AspectScript sea adoptado en el mundo real, este lenguaje debe ser compatible con los actuales browsers. Visualizador de tipos para languajes dínamicosType: Ingeniera El proposito de esta tesis es obtener una herramienta de visualización (usando el motor de visualización Mondrian) para tipos graduales en lenguajes con sistema de tipos dinámico, como ser Javascript, Php, Ruby, etc. Eclipse AspectJ crosscut report pluginType: Ingeniera AspectMaps utiliza un plugin Eclipse + AspectJ para extraer la información de los aspectos en el código. Que son los pointcut y advice de los aspectos y donde en el programa interceptan el flujo de control. Este crosscut report plugin no dice nada sobre inter-type declarations, ni sobre aspectos declarados en .java files, … Este trabajo consiste en extender el plugin para que también da esa información. Agregar una 3D visualización a MondrianType: Ingeniera Mondrian es una herramienta de visualización. Con él, se puede tener una representación gráfica en 2D de cualquier tipo de datos. Mondrian se usa principalmente para visualizar software. Extender Mondrian con una librería 3D abrirá muchas puertas a nuevos tipos de visualización. Ese proyecto de ingeniero o investigación puede dar posibilidad a una colaboración con Suiza y Francia. En ingles: Mondrian is a visualization tool. It is essentially used to give a graphical representation of software programs. It renders 2D pictures. The idea of this topic is to combine Lumiere and Mondrian to offer 3D visualization of software. Eclipse plugin exporting Java to MSEType: Ingeniera Moose no trabaja directamente sobre el código fuente del programa, mas bien sobre su propio formato, llamado MSE. Eso permite que Moose funciona con varios lenguaje de programación, si hay un programa de conversión de código fuente a MSE. Hay un programa para código Java: inFusion, pero usarlo requiere hacer esa conversión manualmente cada vez que se hace un cambio al código fuente. Queremos agilizar este proceso con un plugin eclipse que automáticamente produce una version MSE del código fuente después de cada compilación. MSE extension para aspectosType: Ingeneria/Magister Moose no trabaja directamente sobre el código fuente del programa, mas bien sobre su propio formato, llamado MSE. Eso permite que Moose funciona con varios lenguaje de programación. Hasta ahora este formato no tiene soporte para aspectos. AspectMaps usa su proprio formato que ni siquiera parece de lejos a MSE. Este trabajo consiste en diseñar una extension de MSE, basado en un modelo de aspectos que ya tenenemos dentro de Moose+AspectMaps, y cambiar el crosscutting plugin + AspectMaps para que usan este nuevo formato. La versión 'Ingeneria' de este tópico se enfoque en la implementación del plugin eclipse, mientras que la versión 'Magister' abarca todo el proceso y va mas en profundidad. Eclipse scripting pluginType: Ingeneria/Magister Queremos mejor integración de AspectMaps con Eclipse, por ejemplo que cuando uno selecciona un método en AspectMaps el código fuente se muestra en Eclipse. Por eso necesitamos la posibilidad de hacer scripting de Eclipse, de preferencia vía una conexión en red. Ese trabajo consiste en crear un scripting plugin para Eclipse. La versión 'Ingeniera' del plugin acepta comandos sencillas y es relativamente fácil de extender. La versión 'Magister' es un API completo para un lenguaje de scripting, por ejemplo Python. Importer for your favorite languageType: Ingeniera Alexandre Moose es un ambiente para analizar software. Moose es usado en varias universidades y empresas en Europa y Sudamérica. En la actualidad, solamente los lenguajes C, Smalltalk, Java y ADA están reconocidos desde Moose. Falta Javascript y Php. Un objetivo concreto, es de analizar y medir la calidad de softwares cómo Joomla y Gmail. En ingles: Moose is an environment for analyzing software. It is currently used by a number of Universities in Europe and in South America. So far, only C, Smalltalk, Java, ADA are supported in Moose. It would be very cool to have Javascript, Php, python, ruby. One good starting point to build a new importer in moose, is to have an XML representation of your code. Using XPath you can do simple queries then to extract the information. Good case studies include assessing the quality of gmail, googlemaps, ruby on rails. Architectural components in MooseType: Ingeniera Alexandre Moose es un ambiente para analizar software. Moose es usado en varias universidades y empresas en Europa y Sudamérica. Moose tiene un meta-modelo para describir el código fuente de cualquier tipo de aplicación; pero esto es insuficiente cuando el interés es en la arquitectura de la aplicación, un nivel más abstracto de estructura, lo cual es una necesidad para empresas de software que desean tener una satisfactoria calidad de estos. Este proyecto de ingeniería o investigación puede abrir la posibilidad de una colaboración con Suiza y Francia. En ingles: Currently, only classes, packages, methods are supported in Moose as structural elements. Doing a real case study with industrial applications require some coarser grain, such as Component or Layer. It would be cool to have a way to define architectural layers and some visualization associated to it. Un Sistema Dependiente del Contexto usando SPOTTipo: Ingeniera Los sistemas dependientes del contexto adaptan su conducta de acuerdo a el contexto que ellos perciben, e.g Proyecto Locale [1]. Un sistema dependiente del contexto usa sus sensores para obtener inputs del ambiente, luego estos inputs son analizados para determinar el contexto percibido. El propósito de esta memoria es desarrollar un sistema dependiente del contexto que permita percibir algunos contextos como:
A Dedicated Language for SPOTsType: Ingeniera/MSc Currently developing code on SPOTs is done in Java. Not only does this mean we inherit all the problems that Java has, developing on the spot requires a edit-compile-install-reset cycle. The topic of this thesis is to develop a small language for SPOTs, that is free from the Java restrictions, and which is more dynamic in spirit. The SPOT runs an interpreter for the language, and code is downloaded and run immediately via the wireless connection of the base station. Porting AmbientTalk to SPOTsType: Ingeniera/MSc We have experience with a language created specifically for the domain of ambient intelligence, a possible application area of the SPOTs. The SPOTs however have no support for this language. The goal of this topic is to port the AmbientTalk interpreter [1] to the SPOT, exposing the unique features of the SPOT to the application programmer. Domain-Specific extensions to Java for SPOTsType: Ingeniera/MSc Right now, all the special features of the SPOT are exposed to the programmer as Java abstractions. It would make sense to instead enhance Java, e.g. with some special keywords, to reify these features in the language. Resulting SPOT code would be more compact and easy to read. The topic of this thesis is to make such a Java extension using source code transformation tools such as Stratego and Metaborg[1]. |