Hoy me dediqué a "Asalto Pingüino", el proyecto para Taller de Desarrollo de Software del cuál soy parte. Somos un equipo de 4 personas, muuuuy ocupadas (e inexpertas) , así que el porcentaje de desarrollo está muy cercano a 0%... y el tiempo avanza!!!. Hoy continué con el primer esbozo de la estructura de clases del servidor del juego. Hace un par de meses instalé crossover , para usar el Enterprise Architect , porque me aburrí de esperar por soporte java 1.5 en Poseidon. Pero la versión "emulada" por crossover presenta errores a menudo, que a la larga me aburrieron, como fallas en la renderización de algunos artefactos en los diagramas o en el manejo de elementos en el Project Browser.

Aprovechando que ahora tengo una máquina más decente, decidí darle una oportunidad a vmware, y me ha sorprendido lo bien que se ha desempeñado (a lo largo del día [mean]). Evidentemente el rendimiento de la máquina virtual es menor, hay que pagar todas esas capas de software intermedias, pero para aplicaciones como EA no es notorio (quizás cuando está generando código es apreciable). El roundtrip se hace un poco más engorroso, ya que se debe dejar disponible el directorio src en el proyecto a través de samba, e indicarle a EA en la máquina virtual que tire el código al recurso compartido.

EA en vmware

A pesar de que todo ya está "funcionando", para desarrollo C++ el combo EA+Eclipse aún no me satisface. EA es una de las herramientas de modelado que más flores recibe en la blogosfera y sitios "tech", y es buena en realidad, PERO aún puede mejorar mucho. Cuando un diagrama de clases empieza a ser menos "trivial", el código C++ generado por EA deja de ser compilable, y hay que empezar a corregir sus desinteligencias a mano.

EA no maneja adecuadamente las referencias circulares, y porfía en agregar "#includes" que generan errores de compilación en cada sincronización. Al momento de generar código se agradecería un "warning", y la opción para indicar en que lado de la asociación se declara un tipo incompleto. Tampoco he visto como poder agregar un "using namespace::clase"; se extraña una vista que cumpla esa función tal como hay una para agregar #includes.

Se pierde información en un ciclo de sincronización. Por ejemplo, EA permite modelar interfaces en el diagrama de clases, generando código C++ con métodos virtuales puros. El problema, es que cuando se sincroniza desde el código al modelo, EA hace caso omiso  de que ya existe una relación de "realización" entre la clase y la interface en cuestión, y agrega una relación de "generalización". Lamentablemente lo más sensato es no usar realizaciones, y modelar las implementaciones de interfaces usando generalizaciones, porque si no en cada sincronización habría que borrar una pila de relaciones redundantes a mano. Evidentemente este problema surge del hecho que C++ no cuenta con un constructo para representar interfaces. Sin embargo, EA debería ser los suficientemente "inteligente" como para darse cuenta que en C++ un método virtual puro es la especificación de una operación, y que por lo tanto una clase compuesta exclusivamente de este tipo de métodos es una interface.

Más de forma que de fondo, me carga el formato de las constantes que define EA en cada header. Es un string gigantesco, supongo que para identificar de alguna manera el archivo entre cada sincronización, ya que en la plantilla que genera el código dice claramente: "WARNING: DO NOT MODIFY THIS TEMPLATE BELOW THIS POINT". Podría ser algo más legible, como se acostumbra.
Hay algunas falencias en las plantillas de código C++, que causan errores de compilación. Me llama la atención que los setters tengan "hardcoded" en la plantilla el nombre del argumento!. Observando la plantilla OperationBody de C++, se puede ver:

EA template
 
%elseIf opStereotype == "property set" and opTag:"attribute_name" != ""%
 \t%opTag:"attribute_name"% = newVal;
 
   

Esto hace que EA genere todos los setters de la forma:

setter
 
void Shape::setWidth(int newVal)
 {
    width = newVal;
 }
  
   

No importa que se cambie el nombre del parámetro!, igual usará newVal, provocando código erróneo:

setter
 
void Shape::setWidth(int otroNombre)
 {
    width = newVal;
 }
  
   

En este caso se espera una plantilla un poco más inteligente no?, que además chequee si el nombre del argumento es igual al de la propiedad, para agregar un this-> si corresponde. A mi me gustan los setters del tipo:

setter
 
void Shape::setWidth(int width)
 {
    this->width = width;
 }
  
   

Asi que, cambié la plantilla a:

EA template
 
%elseIf opStereotype == "property set" and opTag:"attribute_name" != ""%
 \tthis->%opTag:"attribute_name"% = %opTag:"attribute_name"%;
  
   

Por el otro lado, Eclipse igual tiene sus falencias. El CDT todavía está lejos de alcanzar el nivel que brinda JDT. Faltan muchas de las características que permiten desarrollar rápido y con mayor calidad. Uno extraña cosas como los refactors, un indexador más poderoso, autocompletación más inteligente, un "organice includes", etc. Algo que me llama mucho la atención es por qué puedo formatear UN archivo fuente y no TODO el proyecto?; si Shift+Alt+F está funcionando… entonces cuál es el drama de repetir eso para cada archivo fuente?. Por suerte se pueden incorporar herramientas externas a eclipse. En "run / Externals Tools" se pueden configurar invocaciones a programas, pasando como parámetros variables de eclipse. Hice un pequeño script bash para formatear el directorio src con astyle:

Astylizar.sh
 
#!/bin/sh
 for file in $(find $1 -name \*.cpp -print); do
    astyle --style=ansi --indent=tab --pad=oper --suffix=none $file
 done
 for file in $(find $1 -name \*.h -print); do
    astyle --style=ansi --indent=tab --pad=oper --suffix=none $file
 done
  
   

Se poco de bash, así que si hay una forma de hacer lo mismo con una sola línea y la mitad de iteraciones, perdónenme por newbie :roll:. Luego en "run / Externals Tools/Open External Tools Dialog…", se crea un nuevo programa, se le asigna un nombre, la ruta del script astylizar.sh, y en la lista de argumentos de escribe la variable ${project_loc}, que representa la ruta absoluta del recurso seleccionado. Así, para formatear todo el código del proyecto, se selecciona el directorio src y se llama a Astylizar vía "External Tools".

A pesar de que le falta a CDT, le tengo fé a la comunidad eclipse. Se ve actividad y progreso en el news del proyecto, y el resultado de las iniciativas de la comunidad en otras herramientas hace pensar que probablemente eclipse se alce como uno de los IDEs open source preponderantes para C++ en el futuro.

Hasta acá dejo mis lloriqueos, y mejor sigo trabajando . A pesar de que EA y Eclipse tienen sus bemoles, son dos grandes herramientas que ayudan mucho en el desarrollo de software. Atrás quedaron los dias de block de notas y cuaderno.

Comentarios (1)

Nombre

Sitio Web

Comentario

corto | largo

Nuevo Comentario