Download EL LENGUAJE DE ALGORITMOS JE CON SOPORTE PARA ECLIPSE

UNIVERSIDAD DE LAS TUNAS “VLADIMIR ILICH LENIN”
FACULTAD DE CIENCIAS TÉCNICAS
DEPARTAMENTO DE INFORMÁTICA
EL LENGUAJE DE
ALGORITMOS JE CON
SOPORTE PARA ECLIPSE
Trabajo de diploma en opción al título de
Ingeniero Informático
Autor:
Yoandre Saavedra González
Tutores:
MSc. Edilmar Silva Torres
MSc. Risel Fernández Mora
Lic. Sánder Ávalo Fondín
Las Tunas, junio de 2013
Año 55 de la Revolución
PENSAMIENTO
“Aprender a programar una computadora
…te enseña cómo pensar”
RESUMEN
En la universidad V. I. Lenin de Las Tunas se imparte "Introducción a la
programación" auxiliándose de pseudolenguajes con la sintaxis en español y del
entorno educativo de desarrollo Maruga Script. Esta excelente herramienta soporta
un lenguaje para algoritmos en español, ideado para que los alumnos desarrollen
habilidades en la resolución de algoritmos y del pensamiento lógico. Fue pensada
para estudiantes de la enseñanza técnica media y como antecesor de Delphi por lo
que tiene una base adecuada para esta enseñanza pero no para estudiantes de esta
universidad. Estas características lo dejan en desventaja para convertirlo en el medio
de enseñanza principal de la asignatura. Se comprobó en entrevistas a profesores
de la asignatura que los alumnos se adaptan con facilidad al flujo de trabajo de
Maruga Script, pero posteriormente se les hace difícil adaptarse a otros entornos
profesionales como Eclipse. Esta es la plataforma de desarrollo fundamental en el
aprendizaje de las asignaturas de programación I y II por lo que resulta indispensable
su conocimiento. El presente trabajo de investigación tiene como objetivo la
implementación del lenguaje de programación en español jE, sobre el entorno de
desarrollo Eclipse. Su objetivo es facilitar el desarrollo de habilidades en la lógica de
programación con un lenguaje en español sobre la plataforma Eclipse. Incluyendo
estructuras que simulen funciones, así como la familiarización temprana con un único
entorno para las asignaturas de programación en la Universidad V. I. Lenin.
PALABRAS CLAVE
Eclipse, lenguaje, jE
Página | I
ABSTRACT
At the University V. I. Lenin Las Tunas is taught "Introduction to Programming" using
for this languages with Spanish syntax and the educational environment Maruga
Script development, excellent tool that supports a language for algorithms in Spanish,
designed for students to develop skills in solving algorithms and logical thinking in
order to improve traffic to the programming language java general purpose. However,
the pseudo-language Maruga Script was designed for students of middle technical
education so you have a good basis for this teaching but not for university students.
This feature makes it a disadvantage to become the main teaching medium of the
subject. It was found in interviews with teachers of the subject that students adapt
easily to Maruga workflow script, but then find it difficult to adapt to other professional
environments such as Eclipse. Fundamental development platform learning the
programming courses I and II. The present research work aims the implementation of
pseudo-language programming in Spanish jE on the Eclipse development
environment to facilitate the development of skills in programming logic, including
structures that simulate functions and procedures, as well as early familiarization with
a single environment for programming courses at the University V. I. Lenin.
KEYWORDS
Eclipse, language, jE
Página | II
ÍNDICE
INTRODUCCIÓN .................................................................................................................................... 1
CAPITULO I: FUNDAMENTACIÓN TEÓRICA ............................................................................... 6
1.1. Introducción................................................................................................................................... 6
1.1.1. La enseñanza de la informática en Cuba ................................................................................ 6
1.2. Estudio de la teoría para la construcción de intérpretes ............................................................. 7
1.2.1. Estructura de un intérprete .................................................................................................... 8
1.2.2. Interpretación iterativa .......................................................................................................... 9
1.2.3. Interpretación recursiva ....................................................................................................... 10
1.2.4. Ventajas de la utilización de intérpretes .............................................................................. 10
1.2.5. Aplicaciones de los sistemas basados en intérpretes .......................................................... 12
1.2.6. Diseño de lenguajes de programación ................................................................................. 13
1.2.7. Técnicas de especificación semántica .................................................................................. 14
1.2.8. Conceptos de análisis lexicográfico ...................................................................................... 17
1.2.9. Conceptos de Token, patrón y lexema.................................................................................. 18
1.2.10. Expresiones regulares y lenguajes regulares ...................................................................... 19
1.2.11. Gramáticas y lenguajes libres de contexto ......................................................................... 20
1.3. Estado del arte de las herramientas que auxilian el proceso de enseñanza-aprendizaje de la
programación ..................................................................................................................................... 21
1.3.1. Greenfoot ............................................................................................................................. 22
1.3.2. BlueJ ..................................................................................................................................... 22
1.3.3. AlgoBox................................................................................................................................. 23
1.3.4. Léxico .................................................................................................................................... 23
1.3.5. PseudoDSL ............................................................................................................................ 24
1.3.6. Maruga Script ....................................................................................................................... 24
1.3.7. Necesidad de desarrollar una nueva herramienta ............................................................... 24
1.4. Descripción de la Metodología de Desarrollo a utilizar .............................................................. 25
1.2.1. Metodología Ágil eXtreme Programming (XP) ..................................................................... 26
Página | III
1.2.2 Proceso Racional Unificado ................................................................................................... 27
1.2.3 Lenguaje de modelado UML ................................................................................................. 27
1.5. Descripción de las Herramientas y las Tecnologías a utilizar ...................................................... 28
1.5.1. Eclipse ................................................................................................................................... 28
1.5.2. Lenguaje de Programación Java ........................................................................................... 30
1.5.3. La Máquina virtual Java ........................................................................................................ 32
1.5.4. El framework Xtext ............................................................................................................... 33
1.5 Conclusión parcial ........................................................................................................................ 34
CAPÍTULO II. DESCRIPCIÓN Y ANÁLISIS DE LA SOLUCIÓN PROPUESTA.................... 35
2.1. Introducción ................................................................................................................................ 35
2.2. Fase Visión y Alcance................................................................................................................... 35
2.2.1. Propuesta de solución .......................................................................................................... 35
2.2.2. Metodología a utilizar .......................................................................................................... 36
2.2.3. Vista conceptual del sistema como Modelo del Dominio .................................................... 36
2.2.4. Requisitos funcionales .......................................................................................................... 37
2.2.5. Requisitos no funcionales..................................................................................................... 38
2.3. Modelado del Sistema ................................................................................................................. 40
2.3.1. Actores y su justificación ...................................................................................................... 40
2.3.2. Diagrama de Casos de Uso del Sistema ................................................................................ 40
2.3.3. Descripción Textual de los Casos de Uso del Sistema .......................................................... 41
2.4. Diagramas de Secuencia .............................................................................................................. 43
2.5. Conclusión Parcial........................................................................................................................ 45
CAPÍTULO III. IMPLEMENTACIÓN DEL SISTEMA .................................................................. 46
3.1 Introducción ................................................................................................................................. 46
3.2 Diagrama de Clases del Diseño .................................................................................................... 46
3.3. Características del proyecto en Xtext .......................................................................................... 47
3.4. Diagrama de Componentes ......................................................................................................... 48
3.5. Diagrama de despliegue .............................................................................................................. 50
Página | IV
3.6. Interfaz gráfica ............................................................................................................................. 51
3.6. Pruebas al sistema....................................................................................................................... 52
3.6.1. Pruebas de caja blanca ......................................................................................................... 52
3.6.2. Pruebas de caja negra .......................................................................................................... 52
3.2. Conclusión parcial ....................................................................................................................... 53
CONCLUSIONES ................................................................................................................................. 54
RECOMENDACIONES ........................................................................................................................ 55
BIBLIOGRAFÍA ..................................................................................................................................... 56
Página | V
INTRODUCCIÓN
Los avances a nivel global en tecnologías de interfaces informáticas están dirigidos
hacia el empleo de novedosas y ergonómicas interfaces de usuario como el ratón,
las pantallas táctiles, las tabletas gráficas, etc. Las acciones que el usuario realiza
sobre estas interfaces se traducen antes o después a secuencias de comandos que
son ejecutadas como si hubieran sido introducidas por el teclado.
Desde el punto de vista de un profesional de la Informática, para alcanzar un mejor
desempeño en sus funciones es necesario conocer la comunicación textual directa
con la computadora, ya sea utilizando un intérprete de comandos (shell), la
construcción de ficheros de trabajo por lotes, programación en diferentes lenguajes,
etc. Incluso procesadores de texto como WordPerfect y MS Word almacenan los
documentos escritos por el usuario mediante codificación textual estructurada que,
cada vez que se abre el documento es reconocida, recorrida y presentada en
pantalla.(Sergio Gálvez Rojas, 2005)
Conocedores de su importancia las máximas autoridades del país priorizaron que en
los planes de estudio de la mayoría de las carreras universitarias vinculadas a las
ciencias se introdujera la programación. Así fue introducida en 1970 la asignatura
Análisis y Programación en FORTRAN IV. Justo en los inicios de la creación de las
carreras de Ingeniería en Computación y las maestrías en Sistemas Digitales. Con el
desarrollo de nuevas técnicas y lenguajes se fueron incorporando otros de diferente
complejidad.(Tomás López Jiménez, 2010)
En nuestra provincia las habilidades en la programación de ordenadores son
fundamentales en el proceso de aprendizaje de todos los estudiantes que cursan los
diferentes años de la carrera Ingeniería Informática en la Universidad Vladimir Ilich
Lenin. Los conocimientos y habilidades que desarrollan cuando son capaces de
programar ordenadores complementan el resto de su formación académica y los
prepara para el futuro como los trabajadores altamente calificados que nuestra
Revolución Cubana necesita en su desarrollo y defensa, en concordancia con el
Página | 1
lineamiento 131 que de manera escueta plantea “Sostener y desarrollar los
resultados alcanzados en el campo de la industria del software y el proceso de
informatización de la sociedad, las tecnologías educativas que reporten un alto valor
agregado”.(Lineamientos de la política económica y social del partido y la
Revolución, 2011)
Para cumplir este objetivo en esta universidad se imparte la asignatura “Introducción
a la programación” auxiliándose del entorno integrado de desarrollo de algoritmos
Maruga Script, fruto de la investigación de (SEGURA, 2006) donde se implementa un
Entorno Integrado de Desarrollo e investiga las bases didácticas sobre las que
sustenta el uso de este entorno. Sin embargo, el lenguaje que soporta Maruga Script
fue pensado y desarrollado teniendo en cuenta las necesidades de los estudiantes
del IPI Simón Bolívar por lo que no fue dotado con estructuras que soportan
funciones por considerarse a este nivel de enseñanza algo complejo. Esta
característica, con el tiempo, lo deja en desventaja para convertirlo en el medio de
enseñanza principal de la asignatura Introducción a la Lógica de Programación.
Se comprobó en entrevistas a profesores de la asignatura que los alumnos se
adaptan con facilidad al flujo de trabajo de Maruga Script y su lenguaje, pero
posteriormente se les hace difícil adaptarse a otros lenguajes como Java y a
entornos profesionales como Entorno Integrado de Desarrollo (EID) Eclipse, lenguaje
y plataforma de desarrollo fundamental en el aprendizaje de las asignaturas de
Programación I y II. El lenguaje Maruga Script comparte una similitud léxica y
sintáctica con el lenguaje pascal, pues fue desarrollado como antecedente para
Delphi. Lo anterior señala que no cumple algunas necesidades primordiales en la
enseñanza universitaria con el fin de introducir la mayor cantidad de conceptos
cercanos a la programación en java.
Teniendo en cuenta estos hechos se plantea como problema científico: ¿cómo
crear y desarrollar un lenguaje de programación a través de algoritmos que facilite el
tránsito al lenguaje de programación java y al EID Eclipse de los estudiantes de
Ingeniería Informática de la Universidad Vladimir I. Lenin de Las Tunas?
Página | 2
Siguiendo los principios de reusabilidad e integración, la investigación se basa en
trabajos previos. No pretende plantear una solución definitiva al problema, sino que
trata de enriquecer las herramientas existentes desde una perspectiva más orientada
a las tecnologías y tomando como bases didácticas las descritas por (SEGURA,
2006)
Se asume como objeto de estudio de la investigación el proceso de creación y
desarrollo de lenguajes de programación.
El objetivo general está dirigido al desarrollo del lenguaje jE sobre el EID Eclipse
para la programación a través de algoritmos que facilite el tránsito a la programación
java y al EID, de los estudiantes en la carrera Ingeniería en Informática de la
Universidad Vladimir I. Lenin.
Se define como campo de acción los lenguajes para la programación a través de
algoritmos.
Se defiende la idea: con la elaboración e instalación de un plugin para eclipse que
soporte el lenguaje jE, donde se integren características acordes a estudiantes de
nivel universitario y el uso de funciones y procedimientos, se mejorará su compresión
en las técnicas de programación desde la algoritmia hasta la programación java y se
logrará una familiarización temprana con el Entorno Integrado de Desarrollo Eclipse.
Tareas de la investigación:
 Caracterizar la teoría de lenguajes y construcción de compiladores.
 Caracterizar el framework Xtext.
 Caracterizar Eclipse.
 Crear un plugin que integre en Eclipse el uso del lenguaje en español jE.
Para desarrollar esta investigación se utilizan principalmente los siguientes métodos
de investigación:
Métodos teóricos:

Histórico - lógico: Se empleó en el análisis de la dinámica del proceso de
asimilación de las técnicas básicas y lenguajes de programación de la asignatura
Página | 3
“Introducción a la programación” de la carrera Ingeniería en Informática de la
Universidad “V. I. Lenin” de Las Tunas.

Análisis – síntesis: utilizado en el análisis teórico de las fuentes, la
aplicación de los métodos y técnicas investigativas y el balance crítico de las
acciones y etapas.

Análisis documental: se utilizó para la consulta bibliográfica referente al tema,
objeto de investigación y la selección de elementos que pueden servir
como presupuestos teóricos del presente trabajo.

Inducción – deducción: se revela en la relación entre el proceso que
se mueven tanto de lo particular a lo general como en sentido contrario
y en todas las etapas de la investigación.

Sistémico – estructural: utilizado en la proyección de las acciones a partir de la
propuesta y relacionada con las diferentes etapas de la investigación.

Modelación: para realizar una reproducción simplificada teórica del uso de este
medio en la enseñanza de las técnicas básicas y lenguajes de programación, de
lo que puede ser en la práctica.
Métodos prácticos o empíricos:

Entrevista: A los profesores que imparten programación en el Departamento de
Informática de la Universidad V. I. Lenin. Aportó información que nos permitió
sostener la necesidad de un trabajo como la propuesta.

Observaciones directas: a clases y sus alumnos en sus diversas actividades para
acceder a las relaciones dinámicas, situaciones y transformaciones que
experimentó el grupo y el contexto en que fue aplicado.

Análisis del producto de la actividad: para conocer fundamentalmente a través de
las actividades prácticas realizadas por los alumnos el desarrollo alcanzado en el
dominio de las técnicas básicas y lenguajes de programación.
Los métodos y técnicas empleadas coherentemente con un enfoque de carácter
dialéctico – materialista elegido para la investigación posibilitaron establecer el marco
teórico, metodológico y valorativo de esta tesis para poder estructurar la alternativa
didáctica.
Página | 4
La población la constituye los estudiantes de Ingeniería Informática de la Universidad
de Las Tunas “Vladimir Ilich Lenin”, mientras que la muestra es el grupo de primer
año de Ingeniería Informática de la Facultad de Ciencias Técnicas de dicho centro.
La aplicación de
dichos métodos permitió documentar datos obtenidos a través de
las entrevistas y que permitieron confirmar la idea de la realización del proyecto.
Esperamos que el principal aporte práctico se concrete en la elaboración del
lenguaje en español jE soportado a través de un plugin para Eclipse, con el propósito
de que los estudiantes mejoren la cantidad de conceptos que aprenden en la
asignatura “Introducción a la programación”.
El documento está estructurado por capítulos en el siguiente orden:
 Capítulo I: Fundamentación teórica: Describe conceptos fundamentales al
dominio del problema. Analizamos las soluciones existentes y el lugar que
ocuparía nuestra propuesta. Explicamos y justificamos las herramientas
tecnológicas que apoyan la solución del problema.

Capítulo II: Diseño del producto: Analizamos y modelamos la estructura de
nuestra aplicación. Se trabaja de forma independiente la lógica cumpliendo las
interfaces de comunicación con Eclipse, con el fin de que el plugin se integre
correctamente.

Capítulo III: Construcción del producto: Construimos la estructura de la
aplicación.
Página | 5
CAPITULO I: FUNDAMENTACIÓN TEÓRICA
1.1. Introducción
La informática, por su utilidad y versatilidad en cuanto a asistencia a las tareas del
hombre, ha permeado casi todas las aristas de la vida del hombre, son utilizadas en
el trabajo, el ocio, las comunicaciones, la salud y la educación. En esta última se
utiliza como un potente recurso que permite hacer llegar una serie de herramientas a
los estudiantes para su mejor compresión de distintas asignaturas. Así que de cierta
forma existe una predisposición favorable a que sean incluidas en las escuelas
iniciativas dirigidas a educar y formar en la sociedad de la información y las
tecnologías.
1.1.1. La enseñanza de la informática en Cuba
En 1970, a cinco años de fundado el primer Departamento de Ciencias de la
Computación por la Universidad de Stanford, la Universidad de La Habana inició las
carreras de pregrado en Licenciatura en Ciencias de la Computación y la de
Ingeniería en Computación, esta última con estudiantes con el 4to año concluido en
Telecomunicaciones o en Controles automáticos y como especialidad completa
desde 1972. En 1970 la Universidad de La Habana incluyó la especialidad de
computación en la Licenciatura en Matemática. Ese mismo año se introdujo la
asignatura de Análisis y Programación en FORTRAN IV en numerosas carreras
universitarias y el Centro de Investigaciones Digitales (CID) inició la maestría en
Sistemas Digitales en colaboración con universidades canadienses.
En abril de 1970 la Facultad de Tecnología de la Universidad de La Habana creó el
Centro de Estudios de Ingeniería de Sistemas (CEIS), para garantizar la
incorporación y desarrollo de la enseñanza de la computación en las diferentes
carreras, en el postgrado y en la práctica profesional. Para enfrentar el gran
incremento de graduados del grado doce se crearon nuevas universidades y se
ampliaron las capacidades de las ya existentes. En julio de 1976 la Facultad de
Tecnología de la Universidad de La Habana se convirtió en el Instituto Superior
Politécnico “José Antonio Echeverría” (ISPJE); en 1977 inició la carrera de Ingeniería
Página | 6
de Sistemas Automatizados de Dirección (SAD), con estudiantes del primer y
segundo año, realizando la primera graduación en 1981. La Ingeniería en SAD
cubana fue la génesis de la actual ingeniería informática. Su perfil terminal resultó
muy similar al de la Ingeniería en Sistemas de Información de los estándares de la
Association for Computing Machinery ( ACM) y el Institute of Electrical and Electronics
Engineers (IEEE), de manera que ese currículo se inició en Cuba algunos años
antes, desde 1990 esta carrera se denominó Ingeniería informática.
En 1982 los Institutos Superiores Pedagógicos incorporaron la carrera de
Licenciatura en Matemática Computación para la formación de profesores de la
enseñanza media. En el 2000 incluyeron la Licenciatura en Informática como opción
para los más de diez mil nuevos profesores de computación de ese nivel.
En septiembre del 2002 se creó la Universidad de Ciencias Informáticas (UCI),
comenzando su primer curso con 2000 estudiantes. El 19 de julio de 2007 se
graduaron sus primeros 1334 alumnos, diplomados en Ciencias Informáticas.
1.2. Estudio de la teoría para la construcción de intérpretes
Un intérprete es un programa que analiza y ejecuta simultáneamente un programa
escrito en un lenguaje fuente. Generalmente es visto como una caja negra. Cualquier
intérprete tiene dos entradas, como podemos ver en la Ilustración 1: un programa P
escrito en un lenguaje fuente, junto con los datos de entrada, a partir de dicha
entrada produce un resultado.
Página | 7
Ilustración 1: Esquema general de un intérprete.
Los compiladores, a diferencia de los intérpretes, transforman el programa a un
programa equivalente en un código objeto (fase de compilación), y en un segundo
paso generan los resultados a partir de los datos de entrada. El código que generan
puede ser ejecutado por la arquitectura de máquina objetivo. Se consideran más
rápidos pues su código no está completamente en memoria.
1.2.1. Estructura de un intérprete
En la construcción de intérpretes es conveniente utilizar una representación interna
del lenguaje fuente a analizar. De esta forma, la organización interna de la mayoría
de los intérpretes se descompone en los módulos:

Traductor a Representación Interna: Toma como entrada el código del
programa del estudiante en lenguaje fuente, lo analiza y lo transforma a la
representación interna correspondiente a dicho programa.

Representación interna: La representación interna debe ser consistente con
el programa original. Entre los tipos de representación interna, los árboles
sintácticos son los más utilizados si las características del lenguaje lo
permiten, pueden utilizarse estructuras de pila para una mayor eficiencia.

Tablas de símbolos: Durante el proceso de traducción, es conveniente ir
creando una tabla con información relativa a los símbolos que aparecen. La
Página | 8
información a almacenar en dicha tabla de símbolos depende de la
complejidad del lenguaje fuente. Se pueden almacenar etiquetas para
instrucciones de salto, información sobre identificadores (nombre, tipo, línea
en que aparecen, etc.) o cualquier otro tipo de información que se necesite en
la etapa de evaluación.

Evaluador de Representación Interna: A partir de la representación interna
anterior y de los datos de entrada, se llevan a cabo las acciones indicadas
para obtener los resultados. Durante el proceso de evaluación es necesario
contemplar la aparición de errores.

Tratamiento de errores: Durante el proceso de evaluación pueden aparecer
diversos errores como desbordamiento de la pila, divisiones por cero, etc. que
el intérprete debe contemplar.
Dependiendo de la complejidad del código a analizar, el intérprete puede contener
módulos similares a los de un compilador tradicional: Análisis léxico, Sintáctico y
Semántico. Durante la evaluación, el intérprete puede interaccionar con los recursos
del sistema como la memoria, discos, etc. Muchos sistemas interpretados liberan al
programador del manejo explícito de memoria mediante técnicas de recolección de
basura. A la hora de evaluar la representación interna, existen dos métodos
fundamentales: la interpretación iterativa y la interpretación recursiva.
1.2.2. Interpretación iterativa
La interpretación iterativa es apropiada para lenguajes sencillos, donde se analiza y
ejecuta cada expresión de forma directa, como podrían ser los códigos de máquinas
abstractas o lenguajes de sentencias simples. La interpretación consiste en un ciclo
básico de búsqueda, análisis y ejecución de instrucciones.
El esquema sería:
Inicializar
REPETIR
Buscar siguiente instrucción i
SI Encontrada ENTONCES
Página | 9
Analizar i
Ejecutar i
HASTA (que no haya más instrucciones)
Ilustración 2: Pseudocódigo que simula la interpretación iterativa
Cada instrucción su busca en el almacenamiento (memoria o disco) o, algunos
casos, es introducida directamente por el usuario. Luego, la instrucción es analizada
en sus componentes y ejecutada. Normalmente, el lenguaje fuente contiene varios
tipos de instrucciones, de forma que la ejecución se descompone en varios casos,
uno por cada tipo de instrucción.
1.2.3. Interpretación recursiva
Comúnmente el diseño de nuevos lenguajes de programación se realiza en dos
fases: una primera fase de especificación semántica mediante la construcción de un
intérprete prototipo que actúa como una especificación ejecutable y una segunda
fase de implementación del compilador de dicho lenguaje. Para la construcción de
prototipos suele utilizarse un modelo de interpretación recursiva donde las sentencias
pueden estar compuestas por otras sentencias y la ejecución se una sentencia
puede lanzar la ejecución de otras sentencias de forma recursiva.
Los intérpretes recursivos no son apropiados para aplicaciones prácticas debido a su
ineficiencia y se utilizan únicamente como prototipo ejecutable del lenguaje. El
problema de especificar un lenguaje mediante un intérprete prototipo es decidir en
qué
lenguaje
se
implementa
dicho
intérprete.
Dicho
lenguaje
debe
ser
suficientemente expresivo y no ambiguo para definir claramente cómo funcionan las
diferentes construcciones. En muchos casos se opta por utilizar lenguajes ya
implementados pero que carecen de una especificación semántica clara. La
tendencia actual es investigar técnicas de especificación semántica formal que
permitan generar automáticamente este tipo de intérpretes. (Gayo, 2004)
1.2.4. Ventajas de la utilización de intérpretes
Los intérpretes, por definición, realizan la fase de análisis y ejecución a la vez, lo cual
imposibilita algunas optimizaciones. Es por esta causa que los sistemas
Página | 10
interpretados suelen tener un costo mayor de procesamiento con respecto a los
compilados. No obstante, a medida que se implementan avances en la forma de la
recolección de basura o adelantos en la forma de cargar en memoria se optimizan
los tiempos de procesamiento y la capacidad de memoria de los ordenadores.
Actualmente, la eficiencia no es el criterio fundamental en el desarrollo de este tipo
de aplicaciones, sino que se prioriza los sistemas que permiten el desarrollo rápido
de aplicaciones que cumplan fielmente la tarea a realizar.
Algunas ventajas de los sistemas interpretados son:
 De forma general son más fáciles de implementar. Lo cual facilita la corrección
del intérprete y desarrollar nuevas líneas de investigación como la generación
automática de intérpretes a partir de las especificaciones semánticas del
lenguaje.
 Proporcionan una mayor flexibilidad que permite modificar y ampliar las
características del lenguaje fuente. Muchos lenguajes como Lisp, APL, Prolog,
etc. surgieron en primer lugar como sistemas interpretados y posteriormente
surgieron sus respectivos compiladores.
 No es necesario contener en memoria todo el código fuente. Esto permite su
utilización en sistemas de poca memoria o en entornos de red, en los que se
puede obtener el código fuente a medida que se necesita.(Ron K Cytron,
1997)
 Hacen más fácil la meta-programación. Un programa puede manipular su
propio código fuente a medida que se ejecuta. Esto facilita la implementación
de sistemas de aprendizaje automatizado y reflectividad. (H, 1991)
 Aumenta la portabilidad del lenguaje: para que el lenguaje interpretado
funcione en otra máquina virtual sólo es necesario que el intérprete funcione
en dicha máquina.
 Puesto que no existen etapas intermedias de compilación, los sistemas
interpretados facilitan el desarrollo rápido de prototipos, potencian la utilización
de sistemas interactivos y facilitan las tareas de depuración.
Página | 11
1.2.5. Aplicaciones de los sistemas basados en intérpretes
Los sistemas interpretados han sido importantes desde la aparición de los primeros
ordenadores. En la actualidad, la evolución del hardware abre nuevas posibilidades a
los sistemas interpretados. La preocupación ya no es tanto la eficiencia como la
capacidad de desarrollo rápido de nuevas aplicaciones. Las principales aplicaciones
pueden agruparse cómo:
 Intérpretes de Comandos: Son importantes en los Sistemas Operativos,
como el Korn-Shell, C-Shell, JCl, etc. donde son utilitarios capaces de tomar
un lenguaje fuente que puede incluir sentencias de control (bucles,
condiciones, asignaciones, etc.) y ejecutar los diferentes comandos que
aparecen en el lenguaje.
 Lenguajes basados en Escritos (Scripting Languages): Diseñados como
herramientas que sirvan de enlace entre diferentes sistemas o aplicaciones.
Suelen ser interpretados con el fin de admitir una mayor flexibilidad a la hora
de afrontar las peculiaridades de cada sistema. Podrían destacarse Perl,
Tcl/Tk, Java Script, Word Basic.
 Entornos de Programación: Existen ciertos lenguajes que contienen
características que impiden su compilación o cuya compilación no es efectiva.
Estos lenguajes suelen disponer de un complejo entorno de desarrollo
interactivo con facilidades para la depuración de programas. Entre estos
sistemas pueden destacarse los entornos de desarrollo Lisp, Visual Basic,
Smalltalk, etc.
 Lenguajes de Propósitos Específicos: Lenguajes que incluyen sentencias
que realizan tareas complejas en contextos específicos. Existe una gran
variedad de aplicaciones en las que se utiliza este tipo de lenguaje como
consultas a bases de datos, simulación, descripción de hardware, robótica,
CAD/CAM, música, etc.
 Sistemas en tiempo real: Entornos que permiten modificar el código de una
aplicación en tiempo de ejecución de forma interactiva.
Página | 12
 Intérprete de código intermedio: Una tendencia tradicional en el diseño de
compiladores es la generación de código intermedio para una máquina
abstracta, por ejemplo el P-Code de Pascal o los bytecodes de Java. El
siguiente paso puede ser la generación de código objeto a partir del código
intermedio para una máquina concreta, finalizando el proceso de compilación
o interpretar dicho código intermedio en una máquina concreta. La tendencia
habitual es definir un lenguaje intermedio independiente de la máquina
concreta. Para ello suele definirse una máquina virtual que contenga las
instrucciones definidas por el lenguaje intermedio, permitiendo una mayor
portabilidad. Un ejemplo sería la Máquina Virtual de Java, que es simulada en
la mayoría de los navegadores web.(Gayo, 2004)
1.2.6. Diseño de lenguajes de programación
Al diseñar lenguajes de programación a menudo es necesario tomar decisiones
sobre las características que se incluyen de forma permanente, las características
que no se incluyen pero que existen mecanismos que facilitan su inclusión y las que
no se permiten. Estas decisiones pueden afectar al diseño final del lenguaje y a
menudo entra en conflicto con otros aspectos del lenguaje.
Algunos principios de diseño de lenguajes de programación son:
 Concisión notacional: El lenguaje proporciona el marco conceptual para
pensar algoritmos y expresar dichos algoritmos con el nivel de detalle
adecuado. El lenguaje debe ser una ayuda al programador (incluso antes de
comenzar a codificar) proporcionando un conjunto de conceptos claros,
simples y unificados. La sintaxis debe ser legible por el programador.
 Ortogonalidad: Dos características de un lenguaje son ortogonales si pueden
ser comprendidas y combinadas de forma independiente. Cuando las
características del lenguaje son ortogonales, el lenguaje es más sencillo de
comprender, porque hay menos situaciones excepcionales a memorizar. La
ortogonalidad ofrece la posibilidad de combinar características de todas
formas posibles. La falta de ortogonalidad puede suponer la enumeración de
situaciones excepcionales o la aparición de incoherencias.
Página | 13
 Abstracción: El lenguaje debe evitar forzar a los programadores a tener que
enunciar algo más de una vez. El lenguaje debe permitir al programador la
identificación de patrones repetitivos y automatizar tareas mecánicas, tediosas
o susceptibles de cometer errores.
 Seguridad: La fiabilidad de los productos software es muy importante. Lo
ideal es que los programas incorrectos no pertenezcan al lenguaje y sean
rechazados por el intérprete.
 Expresividad: El programador debe poder expresar sus intenciones. En
ocasiones demasiada expresividad puede implicar falta de seguridad.
 Extensibilidad: El lenguaje debe facilitar mecanismos para que el
programador pueda aumentar la capacidad expresiva del lenguaje añadiendo
nuevas construcciones.
 Portabilidad: El intérprete debe estar disponible en la mayor cantidad de
entornos computacionales posibles.
 Eficiencia: El programador debe poder expresar algoritmos suficientemente
eficientes o el lenguaje debe incorporar técnicas de optimización de los
programas escritos en él.
 Librerías de interacción con el exterior: La inclusión de un conjunto de
librerías que facilita el rápido desarrollo de aplicaciones es una componente
esencial de la popularidad de los lenguajes. Si no se dispone de tales librerías,
es necesario contemplar mecanismos de enlace con otros lenguajes que
faciliten la incorporación de librerías externas.
 Entorno: Aunque el entorno no forma parte del lenguaje, muchos lenguajes
débiles técnicamente son ampliamente utilizados debido a que disponen de un
entorno de desarrollo potente o agradable. De la misma forma la disposición
de documentación, ejemplos de programas e incluso programadores pueden
ser factores clave de la popularidad de un lenguaje.(Gayo, 2004)
1.2.7. Técnicas de especificación semántica
Es imprescindible distinguir entre la sintaxis y la semántica de un lenguaje de
programación. La sintaxis describe la estructura aparente del lenguaje, qué
Página | 14
constituye un token, un bloque, un procedimiento, un identificador, etc. La semántica
asume que el programa ya ha sido analizado sintácticamente y relaciona la
estructura del programa con su comportamiento, qué hace el programa, qué cálculos
realiza, que muestra por pantalla, etc.
En general la sintaxis es más fácil de afrontar. En la definición de Algol 60, se utilizó
con gran éxito la notación BNF (Backus-Naur Form) para especificar la sintaxis del
lenguaje. Esta forma desplazó otras técnicas de especificación semántica. Más
tempranamente se comienza a utilizar al BNF extendida o EBNF.
Sin embargo no existe una notación aceptada universalmente de especificación
semántica. Por el contrario se han inventado un gran número de notaciones y se
siguen inventando nuevas de forma regular. La razón recae en que la descripción del
comportamiento de los programas tiene una mayor complejidad que la de su
estructura.
Hay que mencionar que la búsqueda de técnicas de especificación semántica se ve
motivada por las siguientes aplicaciones:
 En el diseño de lenguajes de programación. Los diseñadores necesitan una
técnica que les permita registrar las decisiones sobre construcciones
particulares del lenguaje y el descubrimiento de posibles irregularidades u
omisiones

Durante la implementación del lenguaje, la semántica puede ayudar a
asegurar que la implementación se comporta de forma adecuada
 La estandarización del lenguaje se debe realizar mediante la publicación de
una semántica no ambigua. Los programas deben ejecutarse de una
implementación a otra exhibiendo el mismo comportamiento
 La comprensión de un lenguaje por parte del programador requiere el
aprendizaje de su comportamiento, es decir de su semántica. La semántica
debe aclarar el comportamiento del lenguaje y sus diversas construcciones en
términos de conceptos familiares, haciendo aparente la relación entre el
lenguaje considerado y otros lenguajes familiares para el programador
Página | 15
 La semántica asiste al programador durante la el razonamiento sobre el
programa, verificando que hace lo que se pretende. Esto requiere la
manipulación matemática de programas y significados para poder demostrar
que los programas cumplen ciertas condiciones
 El estudio de las especificaciones semánticas ayudará a comprender las
relaciones entre diferentes lenguajes de programación, aislando propiedades
comunes que permitan avanzar la investigación de nuevos lenguajes de
programación
A la hora de diseñar un nuevo lenguaje de programación se usan las técnicas de
especificación semántica del lenguaje, las cuales se pueden agrupar en:
 Descripción en lenguaje natural: La especificación de la mayoría de los
lenguajes de programación desde Fortran hasta Java se ha realizado en
lenguaje natural más o menos formal, lo que acarrea un serie de problemas
como la falta de rigurosidad, la ambigüedad, entre otras que dificultan la
verificación formal de programas y corrección de las implementaciones
 Implementaciones prototipo: Se define un intérprete estándar para el
lenguaje que funciona en una determinada máquina. El problema es decidir
qué lenguaje se utiliza en la construcción de dicho intérprete. En muchas
ocasiones se utilizan lenguajes ya implementados con el fin de ofrecer
especificaciones ejecutables. En otras ocasiones, se utiliza el mismo lenguaje
que se está definiendo. En todos los casos se produce una sobreespecificación (donde no es necesario solo especificar el lenguaje objeto, sino
también el lenguaje de implementación)
 Semántica denotacional: Se describe el comportamiento del programa
modelando los significados (efectos de las diversas construcciones del
lenguaje) mediante entidades matemáticas. La denotación de un programa se
considera como una función del estado anterior al comienzo de la ejecución al
estado final
 Semántica operacional: Los significados del programa son descritos en
términos operacionales. Se utiliza un lenguaje basado en reglas de inferencia
Página | 16
lógicas en las que se describen formalmente las secuencias de ejecución de
las diferentes instrucciones en una máquina abstracta
 Semántica axiomática: Emplea un sistema formal de razonamiento sobre los
significados de los programas como una descripción del comportamiento del
lenguaje. El sistema permite estudiar formalmente las propiedades del
lenguaje y se requiere la utilización de sistemas consistentes y completos que
no siembre son accesibles
Existen sistemas híbridos como la semántica de acción de Mosses o la semántica
monádica modular que facilitan la legibilidad sin prejuicio de la rigurosidad
matemática. Permitiendo además la automatización de la construcción de prototipos.
1.2.8. Conceptos de análisis lexicográfico
La primera fase de un intérprete lo constituye el análisis lexicográfico o análisis
léxico. Las técnicas utilizadas para construir analizadores léxicos también se pueden
aplicar a otras áreas como, por ejemplo, a lenguajes de consultas y sistemas de
recuperación de información. En cada aplicación, el problema de fondo es la
especificación y diseño de programas que ejecuten las acciones activadas por
palabras que siguen ciertos patrones dentro de las cadenas a reconocer. Dado que la
programación por patrones está ampliamente extendida existen numerosos
metalenguajes que permiten establecer pares de la forma patrón-acción, de manera
que la acción se ejecuta cada vez que el sistema se encuentra una serie de
caracteres cuya estructura coincide con la del patrón.
Existen herramientas software que automatizan la construcción de analizadores
léxicos, como flex/yacc, Xtext, permiten que personas con diferentes conocimientos
utilicen la concordancia de patrones en sus propias áreas de aplicación sin ser
especialistas en programación, debido a que han sido concebidas como
herramientas fáciles de usar.
El analizador léxico es el encargado de buscar los componentes léxicos o palabras
que componen el programa fuente, según reglas o patrones.
La entrada puede definirse como una secuencia de caracteres, que el analizador
divide en palabras con significado propio y las convierte a secuencias de terminales
Página | 17
que luego son procesadas por el analizador sintáctico para hacer el análisis. Además
cumple otras funciones de importancia:
 Elimina los comentarios del programa.
 Elimina espacios en blanco, tabuladores, retornos de carro, etc., y todo aquello
que carezca de significado en según la sintaxis del lenguaje.
 Reconocer los identificadores de usuario, números, palabras reservadas del
lenguaje, etc. y tratarlos correctamente con respecto a la tabla de símbolos.
 Avisar los errores léxicos.
 También puede hacer funciones de preprocesador.
La decisión de separar el análisis léxico del sintáctico responde a la ventaja de
simplificar una, otra o ambas fases. Al añadir un analizador léxico se permite
simplificar considerablemente. La simplificación se hace patente cuando es necesario
realizar modificaciones o extensiones al lenguaje inicialmente ideado, en otras
palabras, se facilita el mantenimiento del intérprete a medida que el lenguaje
evoluciona.
1.2.9. Conceptos de Token, patrón y lexema
Desde un punto de vista generalizado, un programa que implementa un análisis
lexicográfico se puede abstraer como:
(Expresión regular)1
{Acción a ejecutar} 1
(Expresión regular)2
{Acción a ejecutar} 2
(Expresión regular)3
{Acción a ejecutar} 3
Donde cada acción a ejecutar es un fragmento de programa que describe cuál ha de
ser la acción del analizador léxico cuando la secuencia de entrada coincida con la
expresión regular. Normalmente esta acción suele finalizar con devolución de una
categoría léxica.
Estos son conceptos importantes en el desarrollo de un analizador léxico:
 Patrón: es una expresión regular
 Token: es una categoría léxica asociada a un patrón. Cada token se convierte
en un número o código identificador único. En algunos casos, cada número
tiene asociada información adicional necesaria para las fases posteriores de la
Página | 18
etapa de análisis. El concepto de token coincide directamente con el concepto
de terminal desde el punto de vista de la gramática utilizada por el analizador
sintáctico.
 Lexema: Es cada secuencia de caracteres concreta que encaja con un patrón.
El número de lexemas que puede encajar con un patrón puede ser finito o
infinito.
Cuando se ha detectado que un grupo de caracteres coincide con un patrón, se
considera que se ha detectado un lexema. A continuación se le asocia el número de
su categoría léxica, y dicho número o token se le pasa al analizador sintáctico junto
con información adicional.
1.2.10. Expresiones regulares y lenguajes regulares
Un lenguaje formal es un conjunto numerable de cadenas finitas. Las cadenas están
formadas por símbolos que pertenecen a un conjunto finito llamado alfabeto.
Un lenguaje es regular si puede ser reconocido por un autómata finito determinista.
Un autómata finito determinista es una quinteta <Q, Σ, δ, q0, F> dónde:
•
Q es un conjunto finito de estados,
•
Σ es un conjunto finito de símbolos y es denominado alfabeto de entrada,
•
δ es un conjunto de reglas de transición de la forma Q × Σ → Q,
•
q0 es un estado perteneciente a Q y es el estado inicial y
•
F es un subconjunto de Q y denota el conjunto de estados de aceptación.
El autómata opera de la siguiente forma: se lee un símbolo de la entrada. De acuerdo
al símbolo leído el autómata pasa a un nuevo estado y avanza al siguiente símbolo
de la cadena. Si el autómata termina en un estado de aceptación al consumir la
totalidad de la cadena, la cadena es aceptada.
Las expresiones regulares son cadenas escritas en un lenguaje formal y son capaces
de describir la forma de las cadenas que pertenecen a un lenguaje regular. Son
equivalentes en poder a los autómatas finitos. Es más común describir un lenguaje
Página | 19
regular en términos de una expresión regular que en términos de las reglas de
transición de un autómata finito.
1.2.11. Gramáticas y lenguajes libres de contexto
Un lenguaje también puede describirse mediante una gramática, la cual
describe la forma de generar las cadenas que pertenecen a dicho lenguaje. Una
gramática es una cuarteta <N, Σ, P, S> dónde:
• N es un conjunto finito de símbolos no terminales,
• Σ es un conjunto finito disjunto a N de símbolos terminales,
• P es un conjunto finito de reglas de producción de la forma
(Σ υN)* N (Σ υN)* → (Σ υ N)* y
• S es un elemento de N llamado símbolo inicial.
Arriba, * es el operador de Kleene que actúa sobre un conjunto de símbolos y que
denota al conjunto de cadenas formadas por la concatenación de cero o más de las
cadenas contenidas en el operando.
Una gramática también es llamada sistema de reescritura pues las reglas de
producción son usadas como un mecanismo de expansión que permite la generación
de cadenas diversas. El análisis sintáctico es el proceso de reconocer si una cadena
pertenece a un lenguaje mediante la aplicación de las reglas de producción. La
generación de las cadenas del lenguaje se logra mediante la reescritura de un
símbolo inicial y la aplicación sucesiva de las reglas de producción las veces que
sean necesarias y en cualquier orden. Si existe más de una manera de generar la
misma cadena, la gramática se denomina ambigua.
Una gramática libre de contexto es aquella en la que las reescrituras se aplican
recursivamente pero no se sobreponen. Un ejemplo de una gramática que no es
libre de contexto es una gramática que deba verificar paréntesis balanceados
pero a la que se le pide que deba poder manejar el caso “ ( [ ) ] ” donde la verificación
del cierre de “ ) ” interrumpiría la verificación del cierre del “ [ “ abierto si esto se
hiciera de manera recursiva. Un lenguaje es libre de contexto si existe una gramática
libre de contexto que lo genere.
Página | 20
Para expresar una gramática libre de contexto usualmente se utiliza la
notación Backus-Naur y algunas variantes como la Backus-Naur extendida:
no_terminal =
regla de producción ;
regla de producción:
,
concatenación
|
disyunción
“…”
terminal
[…]
opcional
{…}
repetición (cero o más veces)
(…)
agrupamiento
“0” ... “9”
secuencia especial
La notación Backus-Naur extendida incorpora a estas reglas los siguientes
operadores:
 * Símbolo de repetición.
 - Símbolo de excepción.
 , Símbolo de concatenación.
 | Símbolo de separador de disyunción.
 = Símbolo de asignación.
 ; Símbolo de terminación de la regla;
1.3. Estado del arte de las herramientas que auxilian el proceso de enseñanzaaprendizaje de la programación
La problemática de construir herramientas que faciliten el proceso de enseñanzaaprendizaje de la programación ha sido abordada a través del tiempo por numerosos
autores y equipos de trabajo, desde donde han evolucionado diferentes herramientas
tratando de aportar las mejores respuestas a su solución.
Existen un sinnúmero de herramientas gratuitas para enseñar a programar, desde la
niñez casi para todas las etapas de la vida, sin embrago vamos a detenernos en
Página | 21
aquellas que por sus posibilidades se acercan más a los jóvenes estudiantes de
universidades.
1.3.1. Greenfoot
Greenfoot se recomienda para jóvenes entre 18 y 21 años. Fue creado por Michael
Kölling de la Universidad de Kent en Inglaterra y con el apoyo de un grupo de
investigadores de la Universidad La Trobe en Australia.
Greenfoot soporta completamente el lenguaje Java y es especialmente útil para
programar proyectos que contienen un elemento visual. Greenfoot mantiene el
atractivo visual y amigabilidad para el usuario pero su formalidad en cuanto al
lenguaje es tan poderosa que permite la creación de aplicaciones desde sencillas
hasta muy complejas tales como pequeños videojuegos. El concepto de herencia es
fácilmente entendido dado que la interface fuerza al usuario a utilizar un árbol de
herencia donde cualquier nueva clase deberá heredar de la clase Actor al igual que
cualquier Mundo (como se conoce en Greenfoot a los escenarios) deben heredar de
la clase World.(Greenfoot, 2012)
Esta excelente herramienta sin embargo esta en inglés, lo que supone una barrera
para los estudiantes que hablan español y que tienen que concentrarse más en
aprenderse las palabras del inglés y traducir su significado al español dejando en un
segundo plano el pensamiento algorítmico. Su trabajo se orienta también al trabajo
gráfico por lo que lo consideramos más como un Lenguaje de Dominio Especifico
(DSL) orientado al trabajo gráfico que como un lenguaje de carácter general.
1.3.2. BlueJ
BlueJ es un IDE para el lenguaje de programación Java, desarrollado principalmente
con propósitos educativos, pero también es adecuado para el desarrollo de software
a pequeña escala.
BlueJ fue desarrollado para apoyar la enseñanza y el aprendizaje de la programación
orientada a objetos, y como resultado, su diseño difiere de otros entornos de
desarrollo. La pantalla principal muestra gráficamente la estructura de clases de una
aplicación en desarrollo (en un diagrama muy parecido a UML), y los objetos pueden
ser creados y probados interactivamente. Combinado con una interfaz de usuario
Página | 22
simple, esta facilidad de interacción permite experimentar de manera sencilla con los
objetos en desarrollo. Los conceptos de la orientación a objetos (clases, objetos,
comunicación a través de llamadas a métodos) son representados visualmente en el
diseño de interacción en la interfaz.(Bluej, 2012)
El objetivo de BlueJ es el proporcionar experiencias concretas, en un ambiente
gráfico tipo UML, de conceptos abstractos tales como relación entre clase y objeto,
creación de instancias de objetos, llamadas a métodos y paso de parámetros. BlueJ
cuenta con un banco de objetos que pueden ser inspeccionados lo que ayuda a los
programadores novatos a la comprensión de los conceptos mencionados.
BlueJ está soportado por las compañías Oracle y por la prestigiosa Universidad de
Kent del Reino Unido. Como podemos apreciar son herramientas donde la
documentación y los cursos están pensada para hablantes de idioma inglés y los
procesos de desarrollo monopolizados por estos gigantes.
1.3.3. AlgoBox
AlgoBox es una herramienta francesa que se encuentra actualmente en estado de
gestación (versión actual 0.7.1) que propone un entorno de desarrollo de algoritmos
pensado desde la lógica de programación sin tener como objetivo el tránsito del
estudiante a un lenguaje de propósito general posteriormente. El programa así como
toda la documentación disponible solo se encuentra en francés, hermosa lengua pero
que se aleja del objetivo de la asignatura de concentrarse en la creación de
algoritmos.(AlgoBox, 2012)
1.3.4. Léxico
Léxico es desarrollado por los Laboratorios Riosur.net E.U. que es una empresa
dedicada a desarrollar ayudas para la enseñanza. Propone un interesante
acercamiento a un lenguaje en español introductorio a la programación orientada
objetos. Supone una visión más entendible de lo que es crear algoritmos en español.
Sus elementos sintácticos y semánticos se alejan del lenguaje java.
Sin embargo le herramienta es propiedad privada y corre sobre la plataforma .NET lo
que supone un contratiempo a la hora de hacerlo funcionar en plataformas Linux,
Página | 23
indispensable para estar en concordancia con la estrategia de migración a software
libre que lleva a cabo el país.(Riosur, 2013)
1.3.5. PseudoDSL
PseudoDSL es un lenguaje de algoritmos dedicado a la enseñanza de la
programación por personas que hablan español, el mismo se integra a Eclipse a
través de un plugin. Su sintaxis está orientada al lenguaje Pascal. La tecnología que
soporta este lenguaje permite construir traductores a código C++ que el estudiante
posteriormente podría ejecutar en Eclipse e integrar a otros programas, sin embargo
no soporta interpretación y mucho menos compilación, lo cual pierde al estudiante de
la experiencia didáctica de entender la ejecución de su propio código fuente y le
muestra el proceso de traducción como una caja negra muy poco provechoso como
concepto para aprender.(José J. Marente Florín, 2013)
1.3.6. Maruga Script
Desarrollado en Cuba y más específicamente en nuestra provincia, como resultado
del trabajo de curso de (SEGURA, 2006) en la Universidad de Ciencias Pedagógicas
“Pepito Tey”. Cuenta con una gramática en español orientada a conceptos de Pascal.
Está desarrollado sobre el sistema operativo Windows sin posibilidades de migración
a Linux. Contempla un intérprete para el lenguaje y un pequeño conjunto de
funciones matemáticas.
1.3.7. Necesidad de desarrollar una nueva herramienta
Los cambios en la tecnología por problemas como el de la migración al software libre
y la constante actualización de las teorías y soporte para la construcción de este tipo
de herramienta, impone la continua búsqueda de soluciones que mejoren las
prestaciones de las anteriores. Se trata de un ciclo donde se actualiza la teoría y a
continuación la práctica, siendo esta la que retroalimenta la teoría y el ciclo continúa.
De lo que se trata es de encontrar la herramienta ideal de aprendizaje que aproveche
todas las potencialidades de los estudiantes.
La necesidad de desarrollar esta nueva herramienta de basa en la búsqueda de
mejorar el proceso de enseñanza – aprendizaje de la asignatura “Introducción a la
Página | 24
programación” manteniendo un lenguaje en español y sobre el entorno Eclipse se
basa la necesidad de desarrollar esta nueva herramienta.
1.4. Descripción de la Metodología de Desarrollo a utilizar
En un proyecto de software, las metodologías definen quién debe hacer que, cuando
y como debe hacerlo, constituyen la columna vertebral del proceso de desarrollo de
software.
Metodología se refiere a los métodos de investigación de una ciencia. Se entiende
como la parte del proceso de investigación que permite sistematizar los métodos y
las técnicas necesarias para llevarla a cabo.
Imponen un proceso disciplinado sobre el desarrollo del software con el fin de
hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con
un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería.
Para asumir el proceso de desarrollo de software se han incorporado métodos
ingenieros casi desde los primeros pasos de la informática. Estas metodologías en el
transcurso del tiempo se han ganado una pésima reputación dentro de la comunidad
de programadores de todo el mundo. La crítica más extendida es su carácter
burocrático y de lastre al equipo, pues pierden tanto tiempo siguiendo la metodología
que retarda la entrega en el tiempo especificado.
Como el desarrollo de software era algo nuevo, las metodologías tradicionales
incorporaron métodos ingenieros de otras ciencias de producción y las adaptaron a
los entorno de este tipo de trabajos. A medida que se iba añadiendo complejidad a lo
que podía hacer un software, su desarrollo podía tornarse caótico y fracasar en el
tiempo si todo el equipo no se refería a los procesos y artefactos con las mismas
denominaciones, si no podían tener la misma conciencia global e implementaban
interfaces que se comunicaran sin errores entre sí. Además debían coordinar
grandes equipos de desarrollo, directivos y clientes que tenían diferentes puntos de
vista sobre la funcionalidad y tiempo de entrega del producto. Poco a poco se fue
aumentado el proceso, en cada paso agregándole documentación y diagramas
necesarios hasta llegar el inmenso tamaño que presentan hoy en día y el enorme
esfuerzo que implica usar constantemente una metodología tradicional.
Página | 25
Como alternativa a las metodologías tradicionales se han desarrollado alternativas,
conocidas popularmente como ágiles.
Las metodologías ágiles surgieron en la década del 90 de la mano de un grupo de
desarrolladores de software con el propósito de tener un proceso de desarrollo más
liviano, maniobrable y adaptable a ambientes cambiantes y turbulentos. Estas
comparten algunos aspectos comunes a pesar de que los detalles de desarrollo
varían en dependencia de la metodología que se emplea, además forman parte del
movimiento de desarrollo ágil de software, que se basa en la adaptabilidad de
cualquier cambio como medio para aumentar las posibilidades de éxito de un
proyecto. Se les denomina ágiles por los cortos tiempos de desarrollo que implican,
con respecto a metodologías tradiciones, lo que impacta positivamente en la
maximización de beneficios.
En general las metodologías ágiles comparten el uso de procesos de construcción
iterativos, la entrega de software funcional en el menor tiempo posible y hacen
énfasis en el valor del grupo sobre el proceso. De esta forma se favorece el trabajo
colaborativo y la comunicación entre el equipo.
Se ha decidido utilizar la metodología ágil XP pues nuestros recursos humanos son
limitados, el proceso de desarrollo debe ser adaptable al cambio que pueda surgir de
la exploración de una tecnología desconocida. Se escoge teniendo en cuenta la
naturaleza del trabajo y el criterio de tutores.
1.2.1. Metodología Ágil eXtreme Programming (XP)
Constituye un proceso ligero, de bajo riesgo, flexible, predecible, científico y divertido
de desarrollar software. Pura lógica es la palabra que usan entendidos y
desarrolladores para calificar la Programación Extrema, las prácticas de este método
están basadas en la simplicidad, la comunicación y el reciclado continuo de código.
XP, como también se le conoce, es la integración de las prácticas de métodos
tradicionales resumiendo y reutilizando lo más práctico y eficaz. Su fin, además de
desarrollar software de calidad en tiempo y recursos, se basa en la satisfacción del
cliente, integración del cliente con el grupo de desarrollo y capacidad del equipo de
Página | 26
trabajo de adaptarse rápidamente a los cambios, ya sean de tecnología o de
metáforas dentro del negocio.
Como roles fundamentales en esta metodología podemos mencionar.
 Jefe de Proyecto: organiza y guía las reuniones, asegura las condiciones para
el proyecto.
 Programador: es el responsable de las decisiones técnicas y de construir el
sistema sin distinción entre analistas, diseñadores o codificadores. En XP, los
programadores diseñan, programan y son los encargados de las pruebas.
 Cliente: es parte del equipo, determina que construir y cuando, establece las
pruebas funcionales.
1.2.2 Proceso Racional Unificado
RUP, en inglés Rational Unified Process, es un proceso para el desarrollo de un
proyecto de software que define claramente quién, cómo, cuándo y qué debe
hacerse
en
el
proyecto.
Es
una metodología
tradicional.
Tiene
tres
características esenciales: está dirigido por los casos de uso, los cuales
orientan el proyecto según lo que el usuario necesita, está centrado en la
arquitectura, lo que relaciona, la toma de decisiones que indican cómo tiene que ser
construido el sistema y en qué orden, y por último, es iterativo e incremental, lo que
divide el proyecto en mini-proyectos donde los casos de uso y la arquitectura
cumplen sus objetivos de manera más depurada.
1.2.3 Lenguaje de modelado UML
Es un lenguaje gráfico para visualizar, especificar y documentar cada una de las
partes que comprende el desarrollo de software, utilizado para la construcción de
aplicaciones basadas en conceptos orientados a objetos. Se usa para especificar
pues construye modelos sin ambigüedad y completos. UML tiene una sintaxis y
semántica bien definidas, permitiendo representar el modelado de sistemas mediante
el uso de una notación común. Se caracteriza por su flexibilidad, es extensible e
independiente de los diversos procesos del análisis y diseño orientado a objetos.
Página | 27
1.5. Descripción de las Herramientas y las Tecnologías a utilizar
El análisis, diseño y construcción de intérpretes se apoya en la utilización de
herramientas, tecnologías y metodologías que permiten obtener productos de calidad
en tiempo y coste planificados. Si desarrollar los primeros intérpretes tomaba años y
grandes costes, hoy con una fracción pero usando mejores herramientas, se
obtienen productos de
mejor calidad. Existe en este campo una renovación
constante que influye en toda la cadena de desarrollo de software para su beneficio.
Se escogen herramientas y tecnologías libres que responden al proceso de
migración al software libre que lleva al país, sugerido por tutores como vía de apoyo
a esta iniciativa estatal.
1.5.1. Eclipse
Eclipse es definido en la Ecured como: un entorno de desarrollo integrado, de Código
abierto y Multiplataforma. Mayoritariamente se utiliza para desarrollar lo que se
conoce
como "Aplicaciones
de
Cliente
Enriquecido",
opuesto
a
las
aplicaciones "Cliente-liviano" basadas en navegadores. Es una potente y completa
plataforma de Programación, desarrollo y compilación de elementos tan variados
como sitios web, programas en C++ o aplicaciones Java.
Debemos señalar que este entorno una de las mejores cosas que tiene es que es
código abierto, lo que garantiza que se inserte perfectamente en los planes de
migración al software libre que intenta desde hace años llevar a cabo el país.
Esta plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo
integrados (del inglés IDE), como el IDE de Java llamado Java Development Toolkit
(JDT) y el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados
también para desarrollar el mismo Eclipse). Sin embargo, también se puede usar
para otros tipos de aplicaciones cliente, como BitTorrentAzureus.
Descripción del Concepto Plataforma de cliente enriquecido
La base para Eclipse es la plataforma de cliente enriquecido (del Inglés Rich Client
Platform RCP). La Plataforma de Cliente enriquecido está constituida por los
siguientes componentes:
 Plataforma principal - inicio de Eclipse, ejecución de plugins
Página | 28
 OSGi - una plataforma para bundling estándar.
 El Standard Widget Toolkit (SWT) - Un widget toolkit portable.
 Face - manejo de archivos, manejo de texto, editores de texto
 El Workbench de Eclipse - vistas, editores, perspectivas, asistentes
Características de Eclipse
Dispone de un editor de texto con resaltado de sintaxis donde puedes ver el
contenido del fichero en el que estás trabajando. Contiene una lista de tareas y otros
módulos similares. La compilación es en tiempo real. Tiene pruebas unitarias con
JUnit. Integración con Ant, asistentes (wizards) para creación de proyectos, clases,
tests, etc., y refactorización.
Si bien las funciones de Eclipse son más bien de carácter general, las características
del programa se pueden ampliar y mejorar mediante el uso de plugins. Asimismo, a
través de estos "plugins" libremente disponibles es posible añadir un sistema de
control de versiones a través de Subversion y a la vez lograr una integración
mediante Hibernate.
Los widgets de Eclipse están implementados por una herramienta de widget
para Java llamada SWT, a diferencia de la mayoría de las aplicaciones Java, que
usan las opciones estándar Abstract Window Toolkit (AWT) o Swing. La interfaz de
usuario de Eclipse también tiene una capa GUI intermedia llamada JFace, la cual
simplifica la construcción de aplicaciones basadas en SWT.
Ventajas tecnológicas en la utilización de Eclipse
El entorno de desarrollo integrado (IDE) de Eclipse emplea módulos (en inglés
plugin)
para
proporcionar
toda
su
funcionalidad
al
frente
de
la Plataforma de Cliente rico, a diferencia de otros entornos monolíticos donde las
funcionalidades están todas incluidas, las necesite el usuario o no.
Este mecanismo de módulos es una plataforma ligera para componentes de
software. Adicionalmente a permitirle a Eclipse extenderse usando otros lenguajes de
programación como son C/C++ y Python, permite a Eclipse trabajar con lenguajes
para procesado de texto como LaTeX, aplicaciones en red como Telnet y Sistema de
gestión de base de datos.
Página | 29
La arquitectura plugin permite escribir cualquier extensión deseada en el ambiente,
como sería Gestión de la configuración. Se provee soporte para Java y CVS en el
SDK de Eclipse. Y no tiene por qué ser usado únicamente para soportar
otros Lenguajes de programación.
La definición que da el proyecto Eclipse acerca de su Software es: "una especie de
herramienta universal - un IDE abierto y extensible para todo y nada en particular".
En cuanto a la utilización de eclipse para la creación de aplicaciones clientes se
puede decir que:

Eclipse provee al programador con Frameworks muy ricos para el desarrollo de
aplicaciones
gráficas,
definición
y
manipulación
de
modelos
de Software, Aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing
Framework - Framework para la edición gráfica) es un plugin de Eclipse para el
desarrollo de editores visuales que pueden ir desde procesadores de texto
wysiwyg hasta editores de diagramas UML, interfaces gráficas para el usuario
(GUI), etc. Dado que los editores realizados con GEF "viven" dentro de
Eclipse, además de poder ser usados conjuntamente con otros plugins, hacen
uso de su interfaz gráfica personalizable y profesional.

El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo
un IDE con un compilador de Java interno y un modelo completo de los
archivos fuente de Java. Esto permite técnicas avanzadas de refactorización y
análisis de código.
El IDE también hace uso de un espacio de trabajo, en este caso un grupo de
metadata en un espacio para archivos plano, permitiendo modificaciones externas a
los archivos en tanto se refresque el espacio de trabajo correspondiente.
1.5.2. Lenguaje de Programación Java
Java es un lenguaje de desarrollo de propósito general, y como tal es válido para
realizar todo tipo de aplicaciones profesionales. Entre sus características más
importantes está que los ejecutables creados por el compilado de Java son
independientes de la arquitectura, es decir que deben ser capaces de ejecutarse
Página | 30
indistintamente y con los idénticos resultados en una variedad de equipos con
diferentes microprocesadores y sistemas operativos diferentes.(Colectivo, 1996)
En una ocasión la propia Sun, empresa creadora del lenguaje definió Java como: un
lenguaje simple, orientado a objetos, distribuido, intérprete, robusto, seguro, de
arquitectura
neutra,
portátil,
de
alto
desempeño,
de
hilos
múltiples
y
dinámico.(Flanagan, 1999)
1.5.2.1. Patrón de diseño singleton
El patrón de diseño singleton (instancia única) está diseñado para restringir la
creación de objetos pertenecientes a una clase o el valor de un tipo a un único
objeto. Su intención consiste en garantizar que una clase sólo tenga una instancia y
proporcionar un punto de acceso global a ella. El patrón singleton se implementa
creando en nuestra clase un método que crea una instancia del objeto
sólo si
todavía no existe alguna. Para asegurar que la clase no puede ser instanciada
nuevamente se regula el alcance del constructor (con atributos como protegido o
privado).
El patrón singleton provee una única instancia global gracias a que:
 La propia clase es responsable de crear la única instancia.
 Permite el acceso global a dicha instancia mediante un método de clase.
 Declara el constructor de clase como privado para que no sea instanciable
directamente.
1.5.2.2. Patrón Inyección de Dependencias (Dependency Injection, DI)
Inyección de Dependencias es un patrón de diseño orientado a objetos, en el que
se suministran objetos a una clase en lugar de ser la propia clase quien cree el
objeto. El término fue acuñado por primera vez por Martin Fowler.
1.5.2.3. Patrón Modelo Vista Controlador (MVC)
Modelo Vista Controlador divide una aplicación interactiva en tres componentes. El
modelo contiene una especificación de datos que son necesarios, la vista es contiene
las especificaciones para que el estudiantes interactúe con el sistema y el
controlador maneja las peticiones de los usuarios, se refiere a ejecutar acciones.
Página | 31
1.5.3. La Máquina virtual Java
La Máquina Virtual Java (MVJ) es el núcleo del lenguaje de programación Java. De
hecho, es imposible ejecutar un programa Java sin ejecutar alguna implantación de
la MVJ. En la MVJ se encuentra el motor que en realidad ejecuta el programa Java y
es la clave de muchas de las características principales de Java, como la
portabilidad, la eficiencia y la seguridad. Siempre que se corre un programa Java, las
instrucciones que lo componen no son ejecutadas directamente por el hardware
sobre el que subyace, sino que son pasadas a un elemento de software intermedio,
que es el encargado de que las instrucciones sean ejecutadas por el hardware. El
código Java no se ejecuta directamente sobre un procesador físico, sino sobre un
procesador virtual Java.
Sun utiliza el término "Máquina Virtual Java", para referirse a la especificación
abstracta de una máquina de software para ejecutar programas Java. La
especificación de esta máquina virtual, define elementos como el formato de los
archivos de clases de Java (.class), así como la semántica de cada una de las
instrucciones que componen el conjunto de instrucciones de la máquina virtual. A las
implantaciones de esta especificación se les conocen como "Sistemas en Tiempo de
Ejecución Java".
Un sistema de tiempo de ejecución incluye típicamente:

Motor de ejecución. El procesador virtual que se encarga de ejecutar el código
(bytecode), generado por algún compilador de Java o por algún ensamblador[3]
del procesador virtual Java.

Manejador de memoria. Encargado de obtener memoria para las nuevas
instancias de objetos, arreglos, etcétera, y realizar tareas de recolección de
basura.

Manejador de errores y excepciones. Encargado de generar, lanzar y atrapar
excepciones.

Soporte de métodos nativos. Encargado de llamar métodos de C++ o
funciones de C, desde métodos Java y viceversa.
Página | 32

Interfaz multihilos. Encargada de proporcionar el soporte para hilos y
monitores.

Cargador de clases. Su función es cargar dinámicamente las clases Java a
partir de los archivos de clase (.class).

Administrador de seguridad. Se encarga de asegurar que las clases cargadas
sean seguras, así como controlar el acceso a los recursos del sistema.
Adicionalmente, existe un conjunto de clases Java estándar, fuertemente ligadas a la
implantación de cada MVJ en particular. Ejemplos de esto los tenemos en las clases
encargadas de funciones, como los accesos a los recursos de la red, manejar el
sistema de ventanas, los hilos y el sistema de archivos local. Todos estos elementos
en conjunto actúan como una interfaz de alto nivel, para acceder a los recursos del
sistema operativo. Es esta interfaz la clave de la portabilidad de los programas Java,
debido a que independientemente del hardware o sistema operativo sobre el que se
esté trabajando, la máquina virtual Java oculta todas estas diferencias. (MsC.
Rolando Menchaca Méndez, 2000)
1.5.4. El framework Xtext
La ayuda de Xtext para la versión 2.0 del año 2012 define el campo de uso del
framework de la siguiente manera “No importa si usted desea crear un pequeño texto
específico del dominio lingüístico (DSL1) o si desea implementar un verdadero
lenguaje de programación de propósito general. Con Xtext usted puede crear sus
propios lenguajes en un instante. Además, si usted ya tiene un lenguaje existente
pero carece de soporte de una herramienta decente, puede utilizar Xtext para crear
un sofisticado entorno de desarrollo basado en Eclipse, proporcionando la
experiencia de utilizar los entornos modernos de Java y aprender a utilizarlos en un
período sorprendentemente corto de tiempo. Llamamos Xtext un marco de desarrollo
del lenguaje.” (Eclipse Community Forums, 2012)
Aunque la cantidad de preguntas de los usuarios en el Forum de Eclipse EMF (Xtext)
puede demostrar que no es tan “sencillo” construir un DSL, está claro que el
framework apoya muchos aspectos de la creación de un lenguaje. Incorpora al
1
DSL – Lenguaje Específico del Dominio (por sus siglas en inglés)
Página | 33
menos dos lenguajes para automatizar tareas. Xtend que puede servir como lenguaje
de macros, además de ser un lenguaje general. Xbase un lenguaje embebido dentro
del framework y para el cual se le han creado un compilador a código fuente java y
un intérprete.
Como documentación también puede utilizarse un número de traductores de código
importante que aparecen en la red, tecnología no necesariamente tan abstracta
como la construcción de intérpretes, pero si beneficiosa como ayuda para comenzar
su utilización. Carente resulta la documentación sobre la construcción de intérpretes.
Las preguntas relacionadas a este ámbito rondan más de veinte mil visitas, lo que
demuestra la atención que recibe de parte de la comunidad.
1.5 Conclusión parcial
En el desarrollo del capítulo se realiza un recorrido por diferentes teorías de
especificación de lenguajes, así como metodologías y tecnologías software con el
objetivo de hacer una valoración realista que mejor se adapte a las necesidades del
proyecto.
La elección de las tecnologías, herramientas y metodología de desarrollo fueron
definidas con los tutores en el análisis de propuestas similares anteriores. Se tuvo en
cuenta además la relevancia de esta tecnología como software libre y su inserción en
el marco de la estrategia nacional de migración. Además se tuvo en cuenta las
habilidades y experiencias del grupo de desarrollo en la programación.
De esta forma se concluye con la fundamentación teórica y se da paso a la
descripción y análisis de la solución propuesta.
Página | 34
CAPÍTULO II. DESCRIPCIÓN Y ANÁLISIS DE LA SOLUCIÓN PROPUESTA
2.1. Introducción
En este capítulo se hace una descripción del proceso de análisis y diseño de la
solución a desarrollar. Se obtienen y refinan los requisitos funcionales y no
funcionales, como forma de controlar la funcionalidad y el desarrollo de la solución.
Luego de una investigación detallada se define el objeto a automatizar. Se realiza un
Modelo del Dominio y se modela el Sistema con el fin de establecer una arquitectura
candidata, que permite obtener una visión global para la totalidad y una específica
para los detalles del sistema.
2.2. Fase Visión y Alcance
Durante el desarrollo de la solución es imprescindible tener presentes la visión y
alcance del producto con el objetivo de delimitar las acciones de desarrollo al marco
del dominio del problema. Esto proporciona la coherencia y optimización necesarias
del proyecto. Reduce a su vez la inconsistencia interna que pudiera introducir errores
al declarar objetos que posteriormente no se utilizan para lo cual fueron diseñados.
2.2.1. Propuesta de solución
Teniendo en cuenta la problemática a resolver se propone el desarrollo de una
solución informática que le permita al estudiante escribir sus algoritmos utilizando un
lenguaje en español en el que desarrolle un mejor entendimiento de los pasos en la
solución del problema. Para que la solución impacte también en el tránsito del
estudiante desde la etapa inicial de aprendizaje a la etapa posterior de programación
se plantea integrarla al Entorno Integrado de Desarrollo Eclipse, herramienta utilizada
en las asignaturas de programación.
Los algoritmos que el estudiante introduce al sistema deben ser capaces de mostrar
su funcionamiento, por lo que se plantea la necesidad de desarrollar un intérprete de
la gramática del lenguaje que permita su procesamiento y que los resultados sean
visibles. Además que tenga la capacidad de detectar algunos errores de semántica a
medida que se escribe.
Página | 35
2.2.2. Metodología a utilizar
El desarrollo de este tipo de solución es poco conocido en nuestro entorno, nos
atenemos pues a un dominio sin experiencia previa, a una tecnología cuya
documentación está en inglés y que no se domina en el país. Ante este escenario se
decide hacer uso de la Metodología de Desarrollo XP. Se busca de esta forma
alcanzar rápidamente prototipos funcionales que permitan estudiar la materia y ganar
en conocimiento sobre el framework.
Se tiene en cuenta que en la revisión bibliográfica no se encontró documentación tan
amplia de ingeniería de estos sistemas, como si gran cantidad de código directo que
se escribe probando conceptos del lenguaje a desarrollar. También se tiene en
cuenta los requerimientos de tiempo que se demandan y las características de la
complejidad deseada.
2.2.3. Vista conceptual del sistema como Modelo del Dominio
Un modelo de dominio captura los objetos más importantes en contexto del sistema,
objetos que existen o representan las cosas o los eventos que suceden en el entorno
donde trabaja el
sistema. Muchos de estos objetos representan las clases o
acciones a realizar que pueden ser obtenidas a partir de entrevistas con los expertos.
El modelo de dominio se representa mediante la relación de clases de diagramas
UML relacionadas entre sí mediante asociaciones.
Se modela el Maruga Script como dominio de problema, dado que es el principal
medio de enseñanza de la asignatura “Introducción a la programación”. Este nos
permite entender los principales objetos que utiliza el estudiante en el proceso de
declarar un algoritmo en este sistema.
Descripción:
 Estudiante: representa al usuario del sistema
 Proyecto: representa la creación de un nuevo proyecto en Maruga Script
 Maruga Script: sistema principal, soporte de funcionalidad como análisis
léxico, sintáctico, control de errores, administrador del flujo de entrada/salida,
etc.
Página | 36
 Gramática: forma de especificar un algoritmo en Maruga Script y que define
todas las posibles palabras claves utilizables correctamente, también es un
modelo con el cual se nutre la generación de errores
 Intérprete: funcionalidad que recibe una entrada, la procesa y devuelve un
resultado dado por la entrada que es un archivo tipo Maruga Script
 Consola de E/S: funcionalidad que encapsula la entrada/salida del intérprete,
forma que tiene el estudiante de comunicarse con su algoritmo y de ofrecerle
datos y visualizar resultados
En la Ilustración 3 se muestra el Modelo de Dominio.
Ilustración 3: Modelo de Dominio
Del sistema anterior se plantea desarrollar una solución que utilice tecnología libre,
soporte a nueva funcionalidades y que permita utilizarse desde Eclipse.
2.2.4. Requisitos funcionales
La especificación de requisitos representa la funcionalidad deseada en la solución
informática.
Página | 37
Requisitos funcionales
Casos de Uso
RF-1
Análisis del archivo fuente
Gestionar
RF-2
Análisis léxico
RF-3
Análisis semántico
RF-4
Análisis sintáctico
RF-5
Importar el código fuente de Java Español (JE)
RF-6
Convertir árbol de sintaxis abstracta
RF-7
Crear intérprete de Java Español (JE)
RF-8
Crear consola de Java Español (JE)
archivo
JE
Ejecutar archivo JE
Ilustración 4: Requisitos funcionales
Es importante destacar que los requisitos funcionales que se relacionan con el Caso
de Uso Gestionar Archivo JE están ligados con los requisitos de especificación del
lenguaje. Para la consulta de estos requisitos remitimos al Anexo I Especificación del
lenguaje JE.
2.2.5. Requisitos no funcionales
Los requisitos no funcionales son propiedades o cualidades que el sistema a
desarrollar debe cumplir para poder realizar con eficiencia sus tareas y son
fundamentales para el éxito del producto. Definiendo propiedades o características
que hacen al producto atractivo, usable, rápido y confiable. Estos requerimientos no
funcionales (RNF) son fundamentales en el éxito del producto y normalmente están
vinculados a requerimientos funcionales, es decir, una vez que se conozca lo que el
sistema debe hacer, se puede determinar cómo ha de comportarse, qué cualidades
debe tener o cuán rápido o grande debe ser.
Página | 38
Requisitos de Software
RNF 1 Tener una máquina de java instalada, al menos versión 1.5
RNF 2 Portabilidad entre Linux y Windows
Requisitos de Usabilidad
RNF
3 El sistema podrá ser utilizado por todos los estudiantes de la carrera
Ingeniería Informática por defecto, pero su uso puede extenderse a otras carreras.
Requisitos de Rendimiento
RNF 4 El sistema operativo debe ser capaz de ejecutar Eclipse.
Requisitos de Apariencia o Interfaz Externa
RNF 5 Debe poseer una interfaz semejante a la de Eclipse, reutilizando sus
características externas.
RNF 6 Todos los componentes del sistema deben desarrollarse siguiendo el principio
de máxima cohesión y mínimo acoplamiento.
RFN 7 Las clases deben integrar los patrones que implementa el framework Xtext,
como el Modelo Vista Controlador (MVC).
Requisitos de Seguridad
RFN 8 El software debe utilizar la memoria en un contexto limitado sin acceder a la
memoria de otros programas ni escritura de memoria en el contexto del Sistema
Operativo.
Requerimientos de Hardware
PC Estudiante
RNF 9 Microprocesador P3 o Superior.
RNF 10 256 mb de memoria RAM o Superior.
RNF 11 Disco duro de 5 GB o Superior.
RNF 12Teclado
Página | 39
RNF 13 Monitor
Requerimientos de Portabilidad
RNF 14 Empaquetamiento en un plugin redistribuible
Requerimientos de Ayuda y Documentación
RNF 15 La solución contará con un manual de usuario que documente la forma de
integrarlo a Eclipse, soporte tecnológico, posibles problemas, portabilidad.
RNF 16 Se dispondrá de una especificación del lenguaje JE.
2.3. Modelado del Sistema
Con los Casos de Uso especificados se llega a un mejor entendimiento sobre la
utilización del Sistema. El actor utiliza el sistema y se beneficia directamente de él.
2.3.1. Actores y su justificación
Actores:
 Estudiante
El estudiante utilizará el lenguaje JE (Java en Español) para especificar un algoritmo
en español que dé solución a un problema computacional. El algoritmo es una
secuencia de acciones que se ejecutan para modificar el estado inicial del contexto
del problema y llevarlo a un estado final o solución esperada.
2.3.2. Diagrama de Casos de Uso del Sistema
Los diagramas de Casos de Uso del Sistema representan gráficamente los actores
en sus interacciones con los procesos. En nuestro caso vemos el software en dos
momentos, un momento en el cuál el software está solo recibiendo texto y
editándolo, encontrando errores, etc. y otro en el cuál se ejecuta ese algoritmo y que
implica procesos como ejecutar el intérprete o un proceso asociado a la consola.
Esta análisis sirve de base para entender que el cómo hacer y nos guía a la hora de
encontrar la funcionalidad relacionada con cada caso de uso.
Página | 40
Ilustración 5: Diagrama de Casos de Uso del Sistema
Se definen dos Casos de Uso o formas de utilizar el sistema.
Casos de Uso del Sistema identificados:
 CUS Gestionar Archivo JE
 CUS Ejecutar Archivo JE
2.3.3. Descripción Textual de los Casos de Uso del Sistema
La representación gráfica de los Casos de Uso no es suficiente para entender las
relaciones que existen entre ellos. La descripción textual es un método que ofrece
una visión detallada de la funcionalidad de un caso de uso.
Nombre del Caso de Uso
Gestionar Archivo JE
Actor
Estudiante
Propósito
Crear un archivo en java en español.
Resumen
El caso de uso inicia cuando el usuario selecciona la opción de
Crear Archivo JE, al mostrar el editor asociado a al archivo el
Eclipse verifica el código que se está introduciendo en el editor y
mostrará la sintaxis y los errores resaltada de color.
Referencias
RF-1,RF-2, RF-3,RF-4
Página | 41
Precondiciones
Que el entorno de Eclipse se esté ejecutando
Poscondiciones
El sistema crea un fichero y lo asocia al editor de texto jE.
Curso Normal de los Eventos
Acciones del Actor
Respuesta del Sistema
1. El estudiante selecciona la opción 2- El sistema muestra un editor asociado a
Crear Archivo JE.
la gramática de JE.
3- El estudiante introduce el código.
4. El sistema verifica que
introducido es válido. CA #1
el
código
5- El sistema colorea de azul el código
correspondiente a la gramática.
Curso Alternativo de los eventos
CA # 1 El sistema emite un mensaje de error subrayando el código en rojo. Y continúa
en el paso 4.
Ilustración 6: Descripción Caso de Uso del Sistema Gestionar Archivo jE
Página | 42
Nombre del Caso de Uso
Ejecutar archivo JE
Actor
Estudiante
Propósito
Interpretar el archivo JE
Resumen
El caso de uso inicia cuando el estudiante en el editor JE
selecciona la opción Ejecutar JE, entonces el sistema interpreta el
código fuente, obtiene una consola de Eclipse y muestra por ella
los.
Referencias
RF-5,RF-6, RF-7,RF-8
Precondiciones
Que el sistema haya creado un fichero y lo haya asociado a un
editor de texto.
Poscondiciones
Que el sistema interprete el código fuente y muestre los
resultados por consola.
Curso Normal de los Eventos
Acciones del Actor
Respuesta del Sistema
1.El sistema muestra el editor de JE
2. El estudiante selecciona la opción 3. El sistema interpreta
Ejecutar JE.
fuente.CA#1, CA#2
el
código
4. El sistema muestra los resultados por la
consola.
Curso Alternativo de los eventos
CA # 1 Muestra mensaje de error ('Error Semántico').Y continúa en el paso 1 del FNE.
CA #2 Muestra mensaje ('Error interno').Y continúa en el paso 1 del FNE.
Caso de Uso Asociado.
Gestionar Archivo JE
Ilustración 7: Descripción Caso de Uso del Sistema Ejecutar Archivo jE
2.4. Diagramas de Secuencia
Los Diagramas de Secuencia muestras las interacciones entre objetos a través de
una secuencia temporal. Muestra los actores interactuando con los objetos
participantes mediante mensajes intercambiados entre ellos.
Página | 43
Ilustración 8: Diagrama secuencia Gestionar Archivo JE Flujo Normal
Ilustración 9: Diagrama secuencia Ejecutar Archivo JE
Página | 44
2.5. Conclusión Parcial
El capítulo describió la estructura arquitectónica propuesta para la solución.
Partiendo de lo desconocido a lo conocido, se definieron los detalles y las
descripciones de las clases de diseño. Con esta estructura arquitectónica se
aumenta la compresión del dominio del problema y se avanza en la gestión del
proyecto, pudiendo aplicar métodos ingenieros a su desarrollo.
Página | 45
CAPÍTULO III. IMPLEMENTACIÓN DEL SISTEMA
3.1 Introducción
Durante el flujo de trabajo que lleva el nombre de este capítulo se implementan
clases y objetos en ficheros fuentes, binarios, ejecutables y demás. El resultado de
este flujo de trabajo es un sistema ejecutable.(Alejandro Martínez, 2011)
A manera de ejemplificación se decidió en este capítulo mostrar los diagramas de
clases de diseño para suplir el código real de la aplicación.
Para la implementación del lenguaje y su correspondiente intérprete, de acuerdo con
el diseño realizado por los analistas, es necesario aplicar un estándar de codificación
que haga el programa más comprensible para otros miembros del equipo de
desarrollo y que cumpla con las funcionalidades necesarias, además de desglosarlas
en tareas que permitan programar de una manera más clara y organizada.
Se asume las tecnologías libres como vía para contribuir al proceso de Migración al
Software Libre que lleva a cabo el país.
3.2 Diagrama de Clases del Diseño
Aunque pertenecen al flujo de trabajo de Análisis y Diseño se han movido a
Implementación como forma de mostrar de la mejor manera, la distribución
fundamental de la codificación con el objetivo de obtener una visión global de las
principales clases del sistema.
La forma de Gestionar un archivo JE se basa en la utilización de componentes
internos de Eclipse, en este caso se menciona, sin embargo pueden ser vistas como
funciones de biblioteca externa sin afectar la arquitectura del sistema. Además este
sistema ha sido diseñado como entidad independiente, el sistema debe ser capaz
además de funcionar con ANT, pero esta tecnología está fuera del alcance de este
trabajo.
Página | 46
Ilustración 10: Diagramas de clases de diseño: Gestionar Archivo jE
Ilustración 11: Diagrama de clase de diseño: Ejecutar Archivo jE
3.3. Características del proyecto en Xtext
Un proyecto Xtext concilia tres proyectos Java, uno que especifica la funcionalidad
referente al lenguaje, otro al entorno en tiempo de ejecución y un tercero a pruebas
sobre el lenguaje
Página | 47
Se define como nombre de los proyectos
 cu.lt.vlenin.jE: para el proyecto de lenguaje.
 cu.lt.vlenin.jE.ui: para la funcionalidad del entorno en tiempo de ejecución.
 cu.lt.vlenin.jE.test: pruebas al lenguaje.
Debemos mencionar que existen componentes dentro de Eclipse que deben ser
obtenidos en tiempo de ejecución a través de la inyección de dependencias,
conceptos de programación que se mencionaron en el capítulo I.
Este proyecto se realiza en java, realizando recursividades profundas hasta
descomponer expresiones en símbolos.
Este proyecto se realiza además, usando lenguajes auxiliares como Xtend y Xbase.
En el caso de Xtend no se especifican funcionalidades críticas y es el sistema el que
automáticamente genera código auxiliar.
Xbase es un lenguaje interno, importante en el desarrollo del intérprete, sin embargo
no se utiliza directamente, es decir no se programa con él, sino que se utilizan sus
estructuras para modelar la forma en que el intérprete responde.
Para acceder a las funcionalidades de Eclipse se utiliza una filosofía denominada
contribuciones al entorno, usted hace una contribución al entorno cuando especifica
en el archivo Plugin.xml una nueva funcionalidad y lo asocia con una clase.
3.4. Diagrama de Componentes
El diagrama muestra una arquitectura Modelo Vista Controlador donde están
agrupados en los proyectos las clases específicas por la función que realizan en
archivos separados. El framework Xtext no está estructurado en este patrón y
dificulta un poco la localización de los ficheros fuentes.
Página | 48
Ilustración 12: Diagrama de componentes
Diagrama de Componentes de las Vistas
Relación entre los objetos que se especifican y su interacción con los estudiantes.
Ilustración 13: Diagrama de componentes Controladores
Página | 49
Ilustración 14: Diagrama de componentes Modelo
Ilustración 15: Diagrama de componentes Vistas
3.5. Diagrama de despliegue
Un diagrama de despliegue muestra las relaciones físicas entre los distintos nodos
que componen el sistema. La vista de despliegue representa la disposición de las
instancias de componentes de ejecución en instancias de nodos conectados por
enlaces de comunicación.
Página | 50
Ilustración 16: Diagrama de despliegue
El diagrama anterior muestra la distribución, en este caso de nuestro único nodo, que
lo constituye la PC del estudiante, con la máquina virtual de Java instalada para
poder utilizar el Eclipse + JE, independiente del sistema operativo.
3.6. Interfaz gráfica
Ilustración 17: Interfaz gráfica principal
Página | 51
Como se expuso anteriormente la principal Interfaz gráfica está relacionada con la de
Eclipse, esta se reutiliza utilizando contribuciones al entorno y agregando las
opciones que deseamos. Un ejemplo es el editor de texto jE que hereda del editor
estándar y se acondiciona con la gramática del lenguaje jE.
3.6. Pruebas al sistema
Las pruebas acompañan el desarrollo del software mucho antes de escribirse la
primera línea de código. Se prueban los artefactos de cada flujo de trabajo, la
documentación técnica y el resultado del trabajo del equipo.
En este caso probaremos el sistema antes de su entrega final con el objetivo de
detectar los posibles errores y corregirlos. El primer paso corresponde a identificar
los tipos de pruebas que se van a desarrollar.
3.6.1. Pruebas de caja blanca
Las pruebas de caja blanca son un tipo de pruebas al sistema que se basan en el
minucioso examen de los detalles procedimentales. Se comprueban los caminos
lógicos del software proponiendo casos de prueba que ejerciten conjuntos
específicos de condiciones y/o bucles. Se puede examinar el estado del programa en
varios puntos para determinar si el estado final coincide con el esperado. (Pressman,
2005)
3.6.2. Pruebas de caja negra
Las pruebas de caja negra se refieren a las pruebas que se llevan a cabo
sobre la interfaz del software. Los casos de pruebas pretenden demostrar que las
funciones del producto son operativas, que la entrada se realiza de manera
adecuada, que se produce un resultado correcto y que la integridad de la
información externa se
mantiene. Las pruebas de
caja negra examinan
algunos aspectos del modelo fundamental del sistema sin valorar demasiado la
estructura lógica interna del software. Se centran principalmente en los requisitos
funcionales del software y permiten obtener un
conjunto
de
condiciones
de
entrada que ejerciten completamente estos requisitos ignorándose la estructura
de control.(Pressman, 2005)
Página | 52
3.2. Conclusión parcial
El sistema desarrollado posibilita editar y ejecutar algoritmos escritos en el lenguaje
jE y el estudiante reciba retroalimentación de los errores. Se realizaron las
contribuciones al entorno Eclipse siguiendo el patrón de xml para este tipo de
aplicaciones. El proceso de empaquetamiento en un plugin se realiza agregando las
dependencias a otros plugin que utiliza el sistema y exportándose como fragmento y
características. Para instalar el plugin solo hay que copiarlos a la carpeta plugin
dentro de la carpeta Eclipse que contiene el ejecutable eclipse.exe. Se puede afirmar
que la aplicación ha alcanzado el nivel de madurez requerido para auxiliar el proceso
de enseñanza aprendizaje de los estudiantes de nuestra universidad.
Página | 53
CONCLUSIONES
El desarrollo de este trabajo permitió elaborar el lenguaje jE e integrarlo al Entorno
Integrado de Desarrollo (EID) Eclipse a través de un plugin, para ello se cumplieron
los objetivos y tareas planificadas.
 Se entrevistaron profesores y estudiantes, y se constataron las herramientas
que se usaban en el proceso de enseñanza – aprendizaje. Se captaron las
posibles mejoras y se agregaron a la definición del lenguaje.
 Se tuvo en cuenta la importancia de la utilización de herramientas libres y el
estado actual de las herramientas, lo cual llevo a decantarse por el lenguaje
java, el EID Eclipse y el framework Xtext.
 El plugin tiene un diseño orientado a objetos y utiliza patrones como el
singleton y el injector.
 El sistema cuenta con una gramática especificada en EBNF, lo que permite
eliminar ambigüedad y problemas de recursión por la derecha.
 La aplicación se desarrolló en el tiempo establecido y se cumplieron las
funcionalidades que se describieron.
 Se revisó temas complejos con la Comunidad Eclipse EMF (Xtext) los que
aportaron sugerencias para el desarrollo.
Página | 54
RECOMENDACIONES
 Extender su uso a otra Universidades.
 Ampliar la gramática, la corrección de errores, el alcance de variables y el
sistema de tipos.
 Desarrollar el sistema de alcance de nombres de espacio.
 Desarrollar un compilador a bytecode Java para que los estudiantes realicen
verdaderos programas con él.
 Integrar la tecnología gráfica (GMF) para que los estudiantes en el futuro
puedan programar algoritmos a través de un diseñador gráfico.
 Mantener la arquitectura independiente con el fin de que el sistema se pueda
ejecutar desde otros entornos, como ANT.
Página | 55
BIBLIOGRAFÍA
1. Alejandro Martínez Raúl Martínez Guía a Rational Unified Process. - Escuela Politécnica
Superior de Albacete : [s.n.], 2011.
2. AlgoBox Team [En línea]. - 12 de Diciembre de 2012. http://www.xm1math.net/algobox/index.html.
3. Bluej Team Sitio Oficial Bluej [En línea]. - 13 de Diciembre de 2012. - http://bluej.org .
4. Colectivo El lenguaje de programación Java [Libro]. - 1996.
5. Eclipse Community Forums EMF(Xtext) Xtext 2.3 Documentation [Libro]. - [s.l.] : Eclipse
Project, 2012.
6. Flanagan David Java en pocas palabras [Libro]. - México DF : McGraw-Hill, 1999.
7. Gayo José Emilio Labra Intérpretes y Diseño de Lenguajes de Programación [Libro]. - 2004.
8. Greenfoot Team Sitio Oficial Greenfoot [En línea]. - 11 de Diciembre de 2012. http://www.greenfoot.org/door.
9. H Ait Kaci Warrens Abstract Machine, a tutorial recosntruction. - [s.l.] : MIT Press, 1991.
10. José J. Marente Florín Sergio Ruiz Piulestán Pseudocódigo DSL [En línea]. - 20 de febrero de
2013. - http://wikis.uca.es/wikiPLII/index.php/Pseudoc%C3%B3digo_DSL.
11. Lineamientos de la política económica y social del partido y la Revolución. [Libro]. - [s.l.] :
Partido Comunista de Cuba, 2011.
12. MsC. Rolando Menchaca Méndez Dr. Félix García Carballeira Arquitectura de la Máquina
Virtual Java [Publicación periódica] // Revista Digital Universitaria UNAM México. - 2000.
13. Pressman R. S. Ingenieria de Software. Un enfoque Práctico (Sexta Edición) [Libro]. - 2005.
14. Riosur Laboratorios [En línea]. - 8 de Enero de 2013. - https://sites.google.com/site/riosur/.
15. Ron K Cytron Micheal Plezbert Does "Just In Time" = "Better Late than Never?" // 24 Annual
SIGPLAN-SIGACT Symposium of Principles of Programming Languages. - 1997.
16. SEGURA YANIRA ULIVER Entorno Integrado de Desarrollo de Algoritmos [Libro]. - Las Tunas :
Trabajo de Diploma. Universidad de Ciencias Pedagógicas "Pepito Tey", 2006.
17. Sergio Gálvez Rojas Miguel Ángel Mora Mata Traductores y compiladores con Lex/Yacc
[Libro]. - Málaga : Universidad de Málaga, 2005.
18. Tomás López Jiménez Melchor Félix Gil Morell, Adriana Estrada Negrín Momentos del
desarrollo de la informática y de su enseñanza en Cuba [Libro]. - La Habana : Ediciones Futuro,
2010.
Página | 56
ANEXO I: Especificaciones para el lenguaje jE
Para que Eclipse reconozca un archivo JE debe ser creado con extensión .je dentro
de un proyecto Java. El editor JE tiene la opción Ejecutar JE en el menú contextual.
Palabras clave
Palabra
Significado
algoritmoJE Inicia un nuevo algoritmo. A continuación se espera el nombre
del algoritmo.
escribir
leer
Función de salida por consola de un texto
Función de entrada por consola
entero
Corresponde al tipo de datos para número entero
cadena
Corresponde al tipo de datos de texto
real
si - sino
para
mientras
Corresponde al tipo de datos numérico con decimales
Condicional bifurcación.
Condición repetitiva
Ciclo repetitivo condicional
Ilustración 18: Palabras claves del lenguaje
Soporte para:

Uso de comentarios de una línea y de varios.

Soporte para tipos de datos primitivos (enteros, reales y cadenas)

Función de entrada/salida por consola.

Alcance de variables a nivel de funciones.

Declaración de variables tipadas.

Soporte a operaciones aritméticas (+, -, *, /)

Asignación de valores a variables y entre ellas.
Página | 57
ANEXO II: Diagrama de secuencia. Ejecutar archivo JE
El siguiente flujo alterno de eventos para Ejecutar archivo JE se diseñó teniendo en
cuenta el proceso interno del intérprete, el cuál puede encontrar errores en la
semántica
del
algoritmo
especificado
por
el
estudiante.
Proporciona
la
retroalimentación necesaria siempre en lo que respecta a procesamiento interno, por
tanto sus mensajes son más informativos sobre el token o la estructura que generó el
error que la línea de código donde se encuentra.
Ilustración 19: Diagrama de secuencia. Ejecutar archivo JE Flujo Alterno
Página | 58
ANEXO III: Diagrama de secuencia. Gestionar archivo JE
Resulta importante gestionar el archivo JE que contiene el algoritmo del estudiante.
No solo por que el estudiante debe ser capaz de crear, editar y eliminar un archivo
JE, sino porque el sistema interactúa con él a través de procesos o hilos paralelos
que ejecutan tareas como identificar con otro color las palabras claves o la búsqueda
de errores. Una clase importante es el modelo Ecore del lenguaje. Es utilizada para
parear las expresiones del algoritmo con las que admite el lenguaje y así marcar las
palabras claves.
Ilustración 20: Diagrama de secuencia. Gestionar archivo JE Flujo Alterno
Página | 59
ANEXO IV: Interfaz principal
La interfaz principal es la primera vista que obtiene el estudiante al crear un nuevo
proyecto JE. Como tal es la misma que ofrece Eclipse, pero esta vez estará
habilitada para soportar el lenguaje JE.
Ilustración 21: Interfaz principal de la aplicación
Página | 60