Estás en:   ArielOrtiz.com > Traductores > Compilador de Lenguaje Nyota

Compilador de Lenguaje Nyota

Objetivos

Durante esta actividad:

Esta actividad promueve las siguientes habilidades, valores y actitudes: trabajo en equipo, análisis y síntesis, capacidad para identificar y resolver problemas, y uso eficiente de la informática.

Descripción de la Actividad

De manera individual o en equipos de dos personas, construir un compilador para el lenguaje de programación Nyota.

Todos los archivos fuentes que conformen su proyecto deben incluir nombre y matrícula de los autores en un comentario al inicio. Se penalizará con 5 puntos de la calificación de la fase correspondiente si se omiten estos datos.

Se asume que los equipos de dos personas trabajarán bajo el modelo de programación en parejas. Por ese motivo, se espera que cualquiera de los dos integrantes pueda explicar adecuadamente el funcionamiento de cualquier parte del proyecto.

La siguiente tabla desglosa cada una de las fases del proyecto.

Fase % de Calif. Final Descripción Herra-
mientas
Entregables
1. Análisis léxico y sintáctico 5% Diseñar e implementar en Scala un parser que permita reconocer programas válidos del lenguaje fuente. Scala, JUnit

Por equipo, subir a SETA un archivo .ZIP con los siguientes documentos:

Fecha límite: martes, 16 de junio, antes de la hora de clase.

2. Árbol de sintaxis abstracta 5% Modificar el código fuente de la fase 1 para añadir funciones de transformación que permitan la construcción de un árbol de sintaxis abstracta (AST) a partir de un programa válido en el lenguaje fuente. Si no hay errores sintácticos, debe desplegar el AST en la salida estándar. Scala, JUnit

Por equipo, subir a SETA un archivo .ZIP con los siguientes documentos:

Fecha límite: martes, 23 de junio, antes de la hora de clase.

3. Análisis semántico 10% A partir del AST, realizar el análisis semántico del programa fuente. En caso de encontrar un error semántico, se debe desplegar el mensaje de error y el número de línea en donde ocurre. De lo contrario, se debe desplegar la tabla de símbolos. Scala, JUnit

Por equipo, subir a SETA un archivo .ZIP con los siguientes documentos:

Fecha límite: martes, 30 de junio, antes de la hora de clase.

4. Generación de código 10% A partir del AST, realizar la generación de código de ensamblador CIL (Common Intermediate Language) del programa fuente. Al ejecutar ilasm sobre el código generado se debe producir un archivo .EXE para la plataforma CLI (Common Language Infrastructure). Scala, JUnit, Mono

Por equipo, subir a SETA un archivo .ZIP con los siguientes documentos:

Fecha límite: lunes, 6 de julio, a la hora que indique el profesor.

5. Biblioteca para tiempo de ejecución 5% Escribir en C# la biblioteca de funciones para tiempo de ejecución (runtime library) del lenguaje fuente.
Además de los procedimientos descritos en la especificación, la biblioteca deberá incluir al menos veinte procedimientos externos adicionales, cuyo diseño e implementación es libre. Los procedimientos externos pueden generar excepciones a tiempo de ejecución si alguna de sus entradas es inválida.
Mono, C#

Bitácora de Trabajo

En cada fase se debe incluir una bitácora de trabajo. La bitácora de trabajo es un archivo de texto (bitacora.txt) o documento de Word (bitacora.doc), el cual debe contener lo siguiente por cada sesión de trabajo:

La omisión de la bitácora de trabajo implicará un decremento de 20 puntos en la calificación de la fase correspondiente.

Pruebas de Unidad

Las pruebas de unidad son un mecanismo fundamental para incrementar de manera significativa la calidad de un producto de software.

En cada fase del proyecto se debe usar el framework de JUnit para escribir pruebas de unidad que validen la correcta implementación de todo el código producido. Es indispensable que cada posible camino dentro del código sea ejecutado bajo el control de una o más pruebas. Normalmente el número de líneas en las pruebas de unidad supera por mucho al número de líneas del código siendo probado.

Se sugiere fuertemente utilizar la técnica de TDD (Test Driven Development) durante todo el desarrollo del proyecto. Básicamente, esta técnica consiste en escribir incrementalmente las pruebas antes que el código.

La pruebas de unidad corresponden al 30% de la calificación de cada fase.

Deshonestidad Académica

La detección de fraude o plagio, ya sea total o parcial, será penalizada con DA en la calificación parcial o incluso final, dependiendo del momento en el que ocurra.

Si de manera razonable utilizan o se basan en el código elaborado por cualquier otra persona ajena al equipo, se deberá brindar el crédito correspondiente en un comentario al inicio del archivo fuente en donde se está usando dicho código.

© 1996-2009 por Ariel Ortiz Ramírez (ariel.ortiz@itesm.mx)
Desarrollado en Django | Licencia de Creative Commons | XHTML válido | CSS válido