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 á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

Agregar "operadores" para extender ETM

Á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 plugin exporting Java to MSE

Eclipse AspectJ crosscut report plugin

MSE extension para aspectos

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

Eclipse plugin exporting Java to MSE

Architectural components in Moose

Enlaces relevantes:

  1. other very cool projects:

Proyecto ECOCAM: Estrategias COgnitvas para el CÁlculo Mental

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

Software para reconocer estrategias del cálculo mental

Á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 Context-Aware System Using SPOT

A Dedicated Language for SPOTs

Porting AmbientTalk to 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).

Reentrant Aspects in AspectJ

Type: Ingeniera/MSc

Éric / Rodolfo

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
[2] abc: an Extensible AspectJ Compiler. P. Avgustinov et al. Proceedings of AOSD 2005.

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://prog.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.

Agregar "operadores" para extender ETM

type: Ingeniera

Éric / Paul

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 mental

Éric / Paul

Generalmente, 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:

  • “9 + 17” ⇒ “10 + 17 - 1”. Completar la sentencia.
  • “15 + 14” ⇒ “2*15 - 1”. Calcular el doble mas cercano y suma o restar el faltante correspondiente.
  • “24 + 36” ⇒ “20 + 40”. Modificar la operación para facilitar el ejercicio..

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 language

Éric / Rodolfo

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

Eclipse AspectJ crosscut report plugin

Type: Ingeniera

Johan

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 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 plugin exporting Java to MSE

Type: Ingeniera

Johan

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 aspectos

Type: Ingeneria/Magister

Johan

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

Un Sistema Dependiente del Contexto usando SPOT

Tipo: Ingeniera

Johan / Paul

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:

  • Frío usando el sensor de temperatura del SPOT, es posible detectar el contexto de frío en una casa.
  • Trote usando el sensor de movimiento del SPOT, es posible detectar el ritmo del trote para elegir el adecuado tipo de música.


[1] http://code.google.com/android/adc_gallery/app.html?id=25

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.

Porting AmbientTalk to SPOTs

Type: Ingeniera/MSc

Johan / Éric

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.

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

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

 

DCC
Universidad de Chile