Tareas

Entregado	En esta entrega
Introducción al proyecto Límites y alcance Descripción funcional	Planificación
	En Proceso
	Definición formal del lenguaje Definición de la arquitectura
	Pendiente

Problemas Presentados

Problema	Detalles
Demora en la entrega de la planificación	Dificultad para desarrollar la WBS dadas las diferencias entre las alternativas de arquitectura.

Alternativas de Implementación

Después de muchas horas de ardua investigación y análisis se nos presentaron varias alternativas de implementación del lenguaje: Si bien tendríamos que haber definido el lenguaje en sí antes de empezar a pensar la implementación, el avance de la materia nos pide que ya planeemos todo, así que nos tenemos que comer y/o paralelizar algunas etapas que deberían ir en serie. Pensar en la implementación es una de ellas. Las alternativas (pensando en la portabilidad del entorno y el lenguaje) que se nos ocurrieron son las siguientes:

1. Lenguaje interpretado:
   Esta es la solución más directa, por decirlo de alguna forma.
   1. Todo en Java
      Facilita la creación del IDE multiplataforma, mejora la sobrecarga en cuanto el GC nos despreocupa el manejo de memoria y muchas cosas ya están implementadas cualquiera sea el sistema donde corra. Como contraparte, para la implementación del intérprete necesitamos una gestionar la memoria de las estructuras nosotros mismos, cosa que Java no nos deja.
      
   2. Todo en C/C++
      Podemos gestionar la memoria, pero la creación del IDE demandaría más tiempo del que disponemos para finalizar el proyecto.
      
   3. IDE en Java, Intérprete en C/C++
      Tomamos las ventajas de las dos implementaciones anteriores, pero se suma la conexión de ambos sistemas, que puede ser por sockets.
   A todos se añade la complejidad del intérprete y resolver dinamicamente las direcciones e invocaciones. Un aspecto negativo respecto a ser interpretado se basa en que pueden haber vínculos que no se pueden resolver, causando la terminación de los programas y problemas que no se adaptan al objetivo.
   
2. Lenguaje compilado a máquina virtual:
   Esta solución es la que más nos gusta. Las funciones de depuración se incluyen en la misma máquina virtual.
   
   1. Todo en Java
      Lo mismo que el anterior. La gestión de memoria no la vamos a poder hacer.
   2. Todo en C/C++
      Igual que antes, los tiempos de desarrollo se multiplican.
   3. IDE y Compilador en Java, Máquina Virtual en C/C++
      Facilita la creación del IDE y la conexión con el compilador. La creación de la máquina virtual es mucho más simple, dado que no es una máquina virtual corriendo sobre una máquina virtual.
      
   4. IDE en Java, Compilador y Máquina Virtual en C/C++
      Facilita la creación del IDE y la creación del compilador.
      
   5. IDE y Compilador en Java, Máquina Virtual: JVM
      Quita la necesidad de crear una máquina virtual, reemplazándola por una que ya se sabe que anda. Como contraparte, las aplicaciones tienen que adaptarse a la estructura de la máquina virtual, que nativamente ejecuta objetos.
      
   Se suma la complejidad de crear la máquina virtual junto con su repertorio de instrucciones, registros y todo lo que hace a la máquina.
   
3. Lenguaje compilado a máquina real:
   Esta solución ata mucho a la plataforma para la que se genera el binario y tendríamos que crear bibliotecas según la plataforma donde estemos parados.
   
   1. IDE y Compilador en Java, Depurador en C/C++
      Esta solución unifica el desarrollo, aunque habría que crear un compilador para cada plataforma. Dado que Java es independiente de la plataforma el depurador no se puede construir en ese lenguaje. El depurador depende de cada plataforma.
      
   2. IDE en Java, Compilador y Depurador en C/C++
      Se tiene que crear un compilador y un depurador para cada plataforma.
   3. IDE en Java, Compilador: gcc, Depurador: gdb
      Se puede integrar el lenguaje a los lenguajes que compila el gcc y depura el gdb. Aporta el hecho de tener años de desarrollo. Requiere muchas tareas de análisis de la documentación y adaptación del lenguaje.
      
   En todos los casos se dificulta la depuración.
   

Seguro hay otras formas de hacerlo, pero de estas que enumeramos, las dos ideas que más nos convencieron son las 2.3 y 2.4. En estos días vamos a tener que decidirnos por alguna de todas esta gama de posibilidades que se desplegó frente a nosotros.
Hasta la próxima.

Presentación

Inaugurando este espacio, paso a comentar el por qué de su existencia.
Somos alumnos de la carrera de Ingeniería en Sistemas de Información de la Facultad Regional Buenos Aires de la Universidad Tecnológica Nacional. Estamos terminando nuestros estudios y como integración de los conocimientos adquiridos debemos presentar para la asignatura Proyecto un proyecto (valga la redundancia) relacionado con nuestra carrera. Pueden leer más abajo de qué se trata nuestra elección.
En este espacio vamos a ir subiendo informes, novedades, problemas, soluciones, anécdotas y todo lo relacionado con el avance de nuestro proyecto, esto tiene como fin facilitar la comunicación entre el grupo y los docentes, quienes estén interesados y, por qué no, curiosos. Como valor agregado se puede sumar que todo lo expuesto aquí puede servir para marcar las bases de los caminos de otros grupos en años siguientes, siendo un reflejo de nuestras experiencias.
A continuación una breve descripción del proyecto:

Objetivo

Crear un lenguaje de programación gráfico que facilite el aprendizaje de la programación y sus principales conceptos.

Alcances funcionales

• Diseño del lenguaje.
• Relevamiento de especificaciones en conjunto con profesores de la materia Algoritmos y Estructura de Datos.
• El lenguaje, como tal, tendrá características propias que lo distinguen del resto, no teniendo isomorfismo con otro lenguaje actual.
• Entorno de programación multiplataforma.
• Seguimiento de algoritmos en tiempo de ejecución (depuración).
• Asistencia al usuario en la realización de programas.
• Interfaz para agregados de posterior realización, para sumar funcionalidades nuevas.
• Por ejemplo, generación de código fuente en distintos lenguajes.
  

Resultado esperado

Que se logre implementar su utilización en el dictado de la materia Algoritmos y Estructura de Datos, como soporte para práctica por parte de los alumnos y corrección por parte de los profesores, ya que facilitaría el aprendizaje y el intercambio de ejercicios a través de la red.

Bueno, habiéndonos dado a conocer, pueden echar un vistazo sobre lo que se trata todo esto.
Saludos, y gracias por interesarse en nuestro Proyecto.