REINGENIERÍA DE UN COMPILADOR EDUCATIVO

CGPI 20070913

Autores:
Isaac Andrés Canales Martínez
microbenjager@aim.com
Michel Ruiz Tejeida
minamrg@aol.com

Coautores:
MC Sergio Fuenlabrada Velázquez
fuensergio@yahoo.com.mx

Instituto Politécnico Nacional

Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias Sociales y Administrativas
Av. Té 950, Col. Granjas México, CP. 08100,
Teléfono (55) 5624-2000 extensiones 70355 y 70365.

Como estudiantes dentro del área de informática una
de las características que se nos atribuye es la
solución de problemas mediante el uso de recursos
computacionales; sin embargo la creación de una
solución con las características mencionadas
requiere de cierto grado de conocimiento y habilidad
que, finalmente nos indicará la eficiencia de la
solución propuesta.
¿Cómo sabemos si nuestra solución es
eficiente?
Para aquellos que desarrollan sistemas que utilicen
un equipo de cómputo1, es un gran reto identificar si
finalmente la solución es la deseada por el usuario y
si ésta cumple las características adecuadas para
ser un buen sistema.
correcto funcionamiento, considerando los requisitos
del problema, y evitar la inestabilidad. Todas estas
metodologías y procesos que se deben de seguir, es
lo que se conoce como Ingeniería de Software.
Formalmente la Ingeniería de Software se define
como “la aplicación de un enfoque sistemático,
disciplinado y cuantificable hacia el desarrollo,
operación y mantenimiento del software.”
Lo anterior se refiere al proceso de creación del
sistema computacional modelando y adaptándolo a
las necesidades del usuario, siguiendo estándares
de calidad que permitirán la mejor solución posible.
¿Qué pasa si el sistema está terminado y no
seguimos los procedimientos adecuados?

Como se sabe, el proceso de creación lleva consigo
una serie de pasos sistematizados y metodológicos;
sin embargo, en la aplicación diaria se pasan por alto
tareas y actividades que son consideradas inútiles o
innecesarias, que posteriormente se verá reflejado
en la productividad del mismo.
Por todo lo anterior, el desarrollo de un sistema debe
seguir normas y metodologías, para asegurar el
1
Conocido también como Sistema Computacional
Al crear aplicaciones para solucionar problemas
específicos, en ocasiones, se omiten algunos pasos
al seguir cierta metodología, lo que trae consigo
problemáticas comunes, dentro de las más
destacadas encontramos: crear características del
sistema que no resuelven el problema principal,
agregar funciones extras para mejorar la aplicación y
hacerla más robusta pero que finalmente no son
necesarias, entre otras.

1
La solución para determinar si el sistema cumple su
función la podemos encontrar dentro de la
Reingeniería de Software, ya que ésta es el proceso
de revisión de aplicaciones de software con el
propósito de reutilizar el sistema actual.
La Reingeniería de Software utiliza las mismas
técnicas y principios de la Ingeniería de Software,
con la diferencia de que ahora será un proceso
comparativo entre lo que se debió haber hecho y lo
que existe actualmente, para con ello identificar las
fallas y puntos débiles del sistema, que permitirá
posteriormente corregir la aplicación y evitar iniciar
un nuevo proyecto, lo que ahorrará tiempo y reducirá
costos.
Podríamos explicar detalladamente cada una de
estas metodologías, sin embargo, nuestro propósito
se centra en la aplicación de lo que se ha venido
explicando a un sistema terminado.
Los autores, siendo estudiantes de la carrera de
Ingeniería en Informática de la UPIICSA, llevaron a
cabo el desarrollo de un compilador, para la materia
de Compiladores que se cursa en el 4º semestre de
dicha carrera; es necesario mencionar que el
producto fue realizado sin la aplicación de una
metodología de Ingeniería de Software.
Compilador
Un compilador es un programa que lee un programa
escrito en un lenguaje (lenguaje fuente), y lo traduce
a un programa equivalente en otro lenguaje
(lenguaje objeto) como lo muestra la figura 1. Como
parte importante de este proceso de traducción, el
compilador informa a su usuario de la presencia de
errores en el programa fuente.
Fig. 1. Diagrama representativo de un compilador.
La escritura de compiladores comprende los
lenguajes de programación, la arquitectura de
computadoras, la teoría de lenguajes, los algoritmos
y la ingeniería de software. Es importante aclarar
algunas definiciones primordiales antes de
mencionar las herramientas utilizadas; dichas
definiciones se muestran en los siguientes párrafos.
Expresión Regular. Es una expresión que describe
un conjunto de cadenas sin enumerar sus
elementos. Las expresiones regulares son
simplemente fórmulas cuyo propósito es representar
cada una de ellas un lenguaje. Así, el lenguaje de
una expresión regular es simplemente el lenguaje
que ella representa.
Autómata Finito. Un autómata finito se puede
representar diagramáticamente mediante un grafo
dirigido etiquetado, llamado grafo de transiciones, en
el que los nodos son los estados y las aristas
etiquetadas representan la función de transición, ver
la figura 2.
Fig. 2. Un autómata finito en su representación
gráfica.
El autómata finito también tiene una representación
matemática formada por una 5-tupla (S, Σ, δ, so, F)
donde.
- S es el conjunto de estados
- Σ es el alfabeto utilizado
- δ es el conjunto de las funciones de transición
- so es el estado inicial
Tabla de Símbolos. Es una estructura de datos que
contiene un registro por cada lexema (componente
del lenguaje), y se utiliza para reunir información
sobre los distintos atributos que posee cada lexema
(ver figura 5).
2
JFlex. Es un generador de analizadores léxicos para
Java, escrito en Java. JFlex fue diseñado para
trabajar en conjunto con CUP (generador de
Analizadores Sintácticos LALR). Para su
construcción requieres de la definición del lenguaje
por medio de expresiones regulares, que
posteriormente son convertidas de forma automática
a autómatas, para la generación de los lexemas que
serán utilizados por el analizador sintáctico.

CUP. Generador de analizadores sintácticos para

Java, escrito en Java. Como se mencionó
Figura 3. Como todo compilador iniciamos leyendo
previamente, tiene gran compatibilidad con JFlex.
un programa en código fuente.
CUP genera analizadores sintácticos del tipo LALR
(lookahead Left-to-Right), que se definen por medio El código fuente debe tener la característica
de un archivo externo, utilizando gramáticas. exclusiva de estar enfocado al paradigma de
programación estructurada y no en la programación
Descripción del compilador.
orientada a objetos.
Hasta el momento los resultados arrojados por el
El código fuente del compilador se almacena en un
compilador presentan un avance significativo, se ha
archivo que tiene por nombre el seleccionado por el
llegado a la etapa de generación de código
programador, con una extensión .rot soportada por la
intermedio (código de tres direcciones) que
interfaz gráfica del mismo; en donde se puede
posteriormente se transformará al código
modificar libremente y compilarlo de forma sencilla y
ensamblador.
rápida presionando tan solo un botón.
A continuación explicaremos a detalle el proceso de
Análisis Léxico. Es la primer fase del compilador; su
compilación realizado por el proyecto en cuestión.
función es la de identificar cada uno de los
Código Fuente. El compilador lee el programa a caracteres del código fuente, para generar como
partir de un código fuente de alto nivel, la sintaxis de salida los componentes léxicos que utilizará el
éste es muy semejante al utilizado en lenguajes de analizador sintáctico. El analizador léxico interactúa
programación como C o Java; dentro de lo que se con la tabla de símbolos, de tal forma que es el que
puede destacar: algunas de las palabras reservadas se encarga de llenarla y definir los atributos de cada
de ambos lenguajes, la estructura de funciones, lexema (ver figura 4).
asignaciones y operadores lógicos y aritméticos (ver
figura 3).

3

Figura 4. Resultado del código analizado por el
analizador léxico.
Durante toda la fase de compilación se realizan las
pruebas pertinentes para la detección de errores; en
la fase de análisis léxico los errores que pueden
ocurrir es el declarar dentro del código fuente algún
carácter que no pertenezca al lenguaje, este puede
ser un signo de puntuación o algún carácter especial.
Figura 5. Al realizar el análisis léxico actualizamos la
tabla de símbolos del compilador.
Analizador Sintáctico LALR. Es la parte del
compilador que agrupa los componentes léxicos de
un programa fuente, en frases que el compilador
utiliza para sintetizar la salida. Este tipo de
analizadores utiliza funciones y algoritmos para la
generación de tablas de análisis sintáctico, que
posteriormente determinan si una entrada pertenece
o no a una gramática. El resultado del análisis
sintáctico se muestra en la figura 6.
Figura 6. Ejemplo de un árbol de análisis sintáctico.
Analizador Semántico. Etapa del compilador que
revisa el programa fuente para tratar de encontrar
errores semánticos y reúne la información sobre
tipos para la fase posterior de generación de código
(esto gracias a la tabla de símbolos ver la figura 5).
Una parte importante, es la verificación de tipos, aquí
es donde el compilador verifica si cada operador
tiene operandos permitidos por la especificación del
lenguaje.
Generación de código intermedio. Después de los
análisis sintáctico y semántico, algunos compiladores
generan una representación intermedia explícita del
programa fuente. Se puede considerar
representación intermedia como un programa para
máquina abstracta. En la figura 7 se muestra un
ejemplo de código intermedio.
4

Figura 7. Finalmente obtenemos el código de tres
direcciones.
Optimización de código. Esta fase tiene el propósito
de mejorar el código intermedio, de modo que resulte
un código máquina más rápido de ejecutar.
Figura 8. La optimización de código mejora la forma
de realizar los cálculos reduciendo el mismo código a
solo dos direcciones.
Generación de código. La fase final de un compilador
es la generación de código objeto, que por lo general
consiste en código ensamblador (ver figura 9). Las
posiciones de memoria se seleccionan para cada
una de las variables usadas por el programa.
Después, cada una de las instrucciones intermedias
se traduce a una secuencia de instrucciones de
máquina que ejecuta la misma tarea. Finalmente
hemos concluido con todas las fases que forman un
compilador, sin embargo existe un procedimiento
que se realiza de forma implícito durante todo el
proceso de compilación que es la detección y
manejo de errores.
Figura 9. Utilizando únicamente los registros 1 y 2, la
traducción del código optimizado puede convertirse en
un código ensamblador eficiente.
Detección e información de errores. Cada fase
puede encontrar errores. Sin embargo, después de
detectar un error, se debe tratar de alguna forma ese
error, para poder continuar la compilación,
permitiendo la detección de más errores en el
programa fuente. Un compilador que se detiene
cuando encuentra el primer error, no resulta tan útil
como debiera, ya que se comportaría como un
traductor.
Proceso de Reingeniería
Como en toda metodología de creación de sistemas
es de vital importancia identificar la factibilidad y así
saber si continuamos con el siguiente paso o
debemos cambiar de estrategia de solución, de igual
forma en la reingeniería de software debemos estar
seguros al aplicar el proceso o si debemos realizar
un plan de acción alternativo.
Inicialmente lo más conveniente es comprobar que el
sistema actual requiere del proceso de reingeniería,
lo cual se lleva a cabo identificando si el software
cumple adecuadamente los requerimientos para los
que fue creado. El siguiente paso es el de
asegurarse que el sistema requiere necesariamente
ser modificado, con lo que obtenemos los puntos
débiles y zonas críticas. Resulta conveniente
basarse en la documentación del sistema para
entender su funcionamiento y poder realizar una
evaluación adecuada de los cambios que deberán
realizarse.
Una vez que se ha determinado que el sistema
realmente requiere de una reingeniería, se debe
tener en cuenta que el trabajo de ésta será menor al
5
de la creación de uno nuevo, pero que finalmente el
precio será alto.
Al realizar la reingeniería del compilador se basó el
desarrollo en un modelo que describe
detalladamente lo mencionado; en donde cada
actividad realiza una mejora progresiva y que de
acuerdo al diagrama presentado a continuación,
cada una de éstas puede repetirse en otras
ocasiones con la particularidad de que el ciclo puede
terminar después de cualquiera de estas actividades.
El proceso de reingeniería se muestra gráficamente
en la figura 10.
Implementación del analizador semántico y verificación
de tipos de acuerdo a los resultados del analizador
sintáctico.
Generación de código.
Tabla 1. Requerimientos del compilador
Tomando en cuenta los requerimientos es necesario
analizar las funciones que fueron establecidas para
cumplirlos y así verificar que solo existan funciones
dedicadas a dicho propósito, esta actividad recibe el
nombre de Ingeniería Inversa, la cual será tratada
más adelante.
Reestructuración de documentos.

Análisis de Uno de los aspectos más importantes en los ciclos

Inventario.
de vida de sistemas es la documentación, en donde
Reconstrucci se localizará los aspectos técnicos del sistema,
Ingeniería
directa.
ón de
Documentos.
desde el análisis de los requerimientos hasta la
especificación del proceso de implementación.

De tal forma, es conveniente examinar la

documentación actual y compararla con las
Reestructura
ción de
Ingeniería características y funciones del sistema, con el
inversa.
datos.
propósito de conocer si la documentación realmente
Reestructura describe lo que el software hace, y saber si ésta
ción de
código. debe actualizarse.

Desgraciadamente el compilador que aquí se trata

Figura 10. Modelo de proceso de reingeniería de
software.
Requerimientos. Inicialmente todo sistema
computacional tiene una lista de requerimientos que
dieron origen a su creación, del cual es conveniente
analizar para comprobar que cada función realizada
fue diseñada exclusivamente para resolverlo.
Creación de un lenguaje.
Realizar las gramáticas regulares al lenguaje creado.
Identificación de las palabras reservadas del lenguaje.
Definir los operadores lógicos, aritméticos y
relacionales.
Lectura de código fuente desde un archivo de texto o
entrada del teclado.
Creación de la tabla de símbolos y la función de
actualización.
Desarrollar el analizador léxico en base al lenguaje
propuesto.
Creación del analizador sintáctico a partir del código
generado por el analizador léxico.
no cuenta con documentación alguna, ya que éste
no fue creado siguiendo los lineamientos de la
ingeniería de software.
El desarrollo del compilador, fue la etapa que utilizó
la mayoría del tiempo destinado, lo cual llevó a la
ausencia de documentación.
Los lineamientos de la Reingeniería señalan que hay
varias opciones para llevar a cabo la reestructuración
de documentos, una de esas alternativas es la de
volver a documentar por completo.
Esta opción de reestructuración indica el hecho de
que es necesario partir de cero, es decir, suponiendo
que no hay documentación existente, caso que se
presenta en el compilador aquí expuesto, y se
sugiere documentar un mínimo esencial.

6
El proceso elegido, al aplicarlo al compilador, dio
como resultado la obtención de documentos que
indican las funciones de cada clase, variables,
funciones y procedimientos, todo lo anterior aplicado
al código; en lo referente a la parte del análisis, se
definieron y documentaron los requerimientos,
diseño, palabras reservadas, operadores y
componentes del lenguaje.
Ingeniería Inversa.
Cuando existe un sistema informático al cual se le
aplica un proceso de reingeniería, es necesario
regresar a la etapa de diseño incluso si no hay
documentación, esto es para analizar posibles
errores de análisis y posteriormente hacer las
debidas correcciones; la ingeniería inversa permite
realizar lo anterior.
La realización de una ingeniería inversa, consiste en
“desmembrar” el sistema existente y posteriormente
estudiar y analizar detalladamente cada uno de esos
miembros o partes resultantes, para saber cómo se
obtiene el resultado, cómo se realiza el proceso o
simplemente para saber porque el código está
estructurado de cierta forma.
Es muy importante tener un criterio y grado de
abstracción muy amplia, para poder pensar como lo
hizo el equipo de desarrollo del sistema estudiado;
en caso de que el proceso de ingeniería inversa sea
realizado por aquellos que desarrollaron el sistema,
las cosas se simplifican bastante. En el caso
concreto del compilador, el lector podrá darse cuenta
que el proceso de reingeniería se llevó a cabo por
los mismos desarrolladores.
La ingeniería inversa aplicada al sistema tratado, no
fue un proceso muy laborioso, ya que sólo hubo
optimización de ciertas partes en la lógica del código,
eliminación de algunas variables o simplemente la
verificación de que los resultados que arroja el
compilador los hiciera como se planeó desde un
principio.
Reestructuración de código.
La lógica de programación es diferente dependiendo
del programador, ya que se puede llegar a la misma
solución de diferentes formas, pero esto no significa
que todas sean las mejores, por eso se recomienda
establecer estándares en el código, ya sea que las
variables comiencen siempre de alguna forma, que
las funciones o procedimientos tenga nombres
coherentes de acuerdo a lo que hacen, u otros
patrones.
Si no se han fijado lineamentos o estándares en el
código, el proceso de mantenimiento será algo
realmente complicado, por consecuente, la
reingeniería debe tocar este importante punto y
hacer algo al respecto.
La reestructuración de código tiene como objetivo
identificar partes del código fuente que violen el
funcionamiento natural de las estructuras de control
o que no cumplan con lo establecido por la
programación estructurada u orientada a objetos,
para posteriormente corregir esos errores, poner a
prueba el nuevo código, y finalmente documentar los
cambios realizados.
El proceso de reestructuración de código del
compilador, permitió identificar ciertas funciones y
procedimientos que realizaban su tarea de forma
correcta, pero no óptima.
Algunas partes del código que se encontraron como
defectuosas, resultaron ser aquellas donde se
realizaban procesos de traducción al código de tres
direcciones y procesos de análisis del archivo fuente;
dichos defectos no permitían que el proceso de
compilación se realice de forma correcta, lo que
daba como resultado una salida incorrecta o
incompleta al usuario del sistema informático.
Reestructuración de datos.
Como se mencionó anteriormente, se puede llegar a
una solución de diferentes formas, aunque
primeramente se pueda pensar en los ciclos de
7
ejecución, también existen variaciones en las
estructuras y tipos de datos utilizados para llegar a
esa solución.
La utilización de ciertos tipos de datos y la definición
y/o implementación de estructuras de control, es de
vital importancia para el óptimo desempeño y
utilización de recursos de un programa, ya que se
puede desperdiciar memoria si se utiliza un tipo de
dato en vez de otro o se puede complicar la
resolución del problema al no utilizar una estructura
de datos correcta.
Si se detectan problemas de definición de datos, es
necesario analizar el porqué no es buena esa
implementación y seleccionar otro tipo o estructura
de dato, y al igual que el proceso de reingeniería
anterior “Reestructuración de código”, poner a
prueba el nuevo código, y finalmente documentar los
cambios realizados.
Java fue el lenguaje de programación utilizado para
desarrollar el compilador, por consecuente se utilizó
la orientación a objetos, y es por ello que casi todo
dentro del desarrollo de esta herramienta informática
está declarado en clases.
Las estructuras de datos que se utilizaron en el
código fuente son muy básicas, arreglos y listas
enlazadas por mencionar algunas, y los tipos de
datos también son tipos básicos, como String2,
enteros y caracteres.
Es importante mencionar que la reestructuración de
datos brinda el soporte para que la aplicación tenga
un largo plazo de vida, esto se debe al avance que
van teniendo los lenguajes de programación, porque
en algunos desaparecen ciertos tipos de datos, no
dan soporte a algunas funciones como en el caso
que ocurre entre los compiladores de C estándar y
los desarrollados por Borland o Microsoft, y en Java
el hecho de que desaparecen funciones conforme se
actualiza la versión de su máquina virtual o
simplemente al dar mantenimiento al código no se
2
Cadena de caracteres
lleva a cabo de forma satisfactoria la re-compilación
del nuevo código.
Ingeniería Directa.
La ingeniería de software tiene la finalidad de crear
sistemas computacionales de calidad, cubriendo
estándares y facilitando el análisis de los procesos y
resultados que debe arrojar.
La ingeniería directa se refiere a la aplicación de las
técnicas de ingeniería de software, pero en una
forma menos compleja, es decir, aplicar un proceso
de análisis y diseño a lo que se obtuvo en las etapas
anteriores de reingeniería, tomando en cuenta sólo
aquellas partes donde existieron cambios.
Al aplicar la ingeniería directa, se pretende añadir
funciones que sirvan para la mejora del sistema en
forma modular e incluso en forma global.
El compilador aquí descrito pasó por esta etapa de
reingeniería, y los resultados obtenidos fueron muy
notorios.
Primeramente, el proceso de ingeniería directa
permitió establecer un diseño de interfaz gráfica, ya
que la primera versión del compilador se ejecutaba
en línea de comandos, lo que puede ser difícil de
utilizar para algunas personas.
Una vez que se tenía el diseño de la interfaz,
también se tomó la decisión de que el compilador
debería integrar un editor de código, ya que como se
mencionó antes, al ser la interfaz línea de comandos,
sólo se podían compilar archivos que ya estuvieran
previamente capturados en otro editor de texto.
Al principio de este escrito se abordaron las
consideraciones teóricas del compilador, como son,
tabla de símbolos, análisis léxico, análisis sintáctico,
entre otros; todas estas etapas de compilación
generan un resultado, y al aplicar la ingeniería
directa, se decidió mostrar de forma gráfica al
usuario todos los resultados de cada uno de los
procesos de compilación, ya que la primera versión
8
solo mostraba el producto final, que es el código de 3
direcciones, como el mostrado en la figura 7.
Finalmente, el usuario del compilador es capaz de
modificar, crear y abrir sus códigos en el entorno
gráfico, y compilar dichos archivos fuente con sólo
dar clic en un botón.
Conclusión
La ingeniería de software es una herramienta que se
debe aplicar en el desarrollo de sistemas
computacionales actuales tanto a los dirigidos al
usuario como el llamado software de base, debido a
que en estos días, la demanda de la manipulación y
control de información es bastante grande, y se debe
contar con herramientas de tecnologías de
información que nos brinden seguridad y facilidad de
uso.
Un problema actual que se presenta dentro de las
organizaciones, es el hecho de contar con un
sistema informático que haya sido desarrollado sin
haber aplicado ingeniería de software, ya que dichos
sistemas pueden no tener la productividad deseada
o requerida.
La solución al problema anterior, es la aplicación de
la reingeniería de software, que es el proceso por
medio del cual el sistema pasará a ser un producto
con una mejor funcionalidad, mejor desempeño y
fiabilidad, así como mejorar y facilitar el
mantenimiento del mismo.
El proceso de reingeniería se lleva a cabo, al igual
que la ingeniería de software, por etapas, entre las
cuales figuran: Reestructuración de documentos,
Ingeniería Inversa, Reestructuración de código,
Reestructuración de datos e Ingeniería Directa.
Cada etapa cumple una función específica dentro de
la reingeniería, ya sea que se orienten a la
documentación del sistema, a la optimización de
código o a la realización de un nuevo análisis.
El proceso de reingeniería se puede aplicar tanto a
grandes o pequeños, simples o complejos sistemas
informáticos.
Referencias.
[1] Pressman, R., (2006). Ingeniería de software
(Sexta edición). (Ojeda, R., Morales, I., Yägue,
V., Sánchez, S.) Madrid, España: McGraw-Hill.
[2] V. Aho, A., Sethi, R., & D. Ulman, J. (1998).
Compiladores (Primera edición ed.). (P. Flores
Suárez, & P. Botella i López, Trads.) Naucalpan
de Juárez, Estado de México, México: Addison
Wesley Longman.
[3] Kelley, D. (1995). Teoría de autómatas y
lenguajes formales. (L. D. Platas, Trans.)
Ciudad de México, Distrito Federal, México:
Prentice-Hall.
[4] GNU General Public License. (2004, November
7). JFlex. Retrieved July 24, 2005, from The Fast
Scanner Generator for Java:
http://jflex.de/index.html visitada septiembre
2007
[5] Scott Hudson, F. F. (1999, July 24). CUP. (C. S.
Ananian, Editor) Retrieved from Parser
Generator for Java:
http://www2.cs.tum.edu/projects/cup/ visitada
septiembre 2007