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 o Alexandre.

Temas de tésis por área

Tópicos relacionado a AspectScript

AspectScript 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 Aspectos

Área Depuración Omnisciente

La 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

Depuración Omnisciente: Estudio de Casos

Extensión del compilador AspectJ

Área Visualización, Interacción, calidad de Software

AspectMaps

AspectMaps 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 scripting plugin

Trabajos con Moose

Moose 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

Architectural components in Moose

Enlaces relevantes:

  1. other very cool projects:

Área SunSPOT

The 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 Dedicated Language for SPOTs

Domain-Specific extensions to Java for SPOTs


Thesis topics

Visualización de comportamiento de aspectos at runtime

Type: Ingeniera/MSc

Johan / Guillaume / Éric

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.
[2] Extending Omniscient Debugging to Support Aspect-Oriented Programming, G. Pothier, E. Tanter, Proceedings of ACM SAC 2008.

An aspect language for language definition toolkits

Type: Ingeniera/MSc

Johan / Rodolfo

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 Programming

Type: Ingeniera/MSc

Éric

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:

  • Study the root causes of bugs that can make a system crash (I.e. null pointer exceptions, array out of bounds exceptions, …)
  • Study patterns of software patches such that intolerable bugs can be turned into tolerable bugs.
  • Define and implement advices and join points such that these patterns can be woven into the program.

[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
[2] Gabriel, R. P. and Goldman, R. 2006. Conscientious software. SIGPLAN Not. 41, 10 (Oct. 2006), 433-450. DOI= http://doi.acm.org/10.1145/1167515.1167510

Expressive Scoping of Dynamic Aspects in Java

Type: Ingeniera/MSc

Éric / Rodolfo

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.
[2] A Versatile Kernel for Multi-Language Aspect-Oriented Programming. E. Tanter, J. Noyé, Proceedings of ACM GPCE 2005.
[3] An Overview of CaesarJ, Transactions on AOSD, 2006.

Scoping of Distributed Aspects

Type: Ingeniera/MSc

Éric / Rodolfo

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.
[2] A Versatile Kernel for Distributed Aspect-Oriented Programming. E. Tanter, R. Toledo. Proceedings of DAIS 2006.
[3] Expressive Scoping of Dynamically-Deployed Aspects. E. Tanter. To appear in AOSD 2008 (available upon request).

An Aspect Language for Ambient Actors

Type: Ingeniera/MSc

Johan / Éric

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.

[1] http://soft.vub.ac.be/amop

Depuración Omnisciente: Estudio de Casos

Type: Ingeniera/MSc

Éric / Guillaume

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 AspectJ

Type: Ingeniera/MSc

Éric / Guillaume

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 builder

Type: Ingeniera/MSc

Éric / Guillaume

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.

Extender Firebug para depurar de aplicaciones de AspectScript

type: Ingeniera

Éric / Paul / Rodolfo

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 AspectScript

type: Ingeniera

Éric / Paul / Rodolfo

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 browsers

type: Ingeniera

Éric / Paul / Rodolfo

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ínamicos

Type: Ingeniera

Éric/Oscar/Alexander

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.

Agregar una 3D visualización a Mondrian

Type: Ingeniera

Alexandre

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 scripting plugin

Type: Ingeneria/Magister

Johan/Guillaume

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 language

Type: 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 Moose

Type: 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.

A Dedicated Language for SPOTs

Type: Ingeniera/MSc

Johan / Éric

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.

Domain-Specific extensions to Java for SPOTs

Type: Ingeniera/MSc

Johan / Éric

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].

http://strategoxt.org/Stratego/MetaBorg

Better integration of Gradualtalk in Smalltalk

Type: Ingeniera

Johan

Gradualtalk is a gradually typed Smalltalk. It provides tools for the programmers to type only certain sections of code. However, critical features of Smalltalk does not support it or the support is minimal. These features are Monticello, the package manager, and Nautilus, the code browser. The topic of this thesis is to make extensions to these tools to add better support for Gradualtalk.

http://www.pleiad.cl/gradualtalk