domingo, marzo 13, 2005

MonoUML, Ingeniería Inversa. Segunda Parte

Después de un día de arduo trabajo, he subido al CVS la versión actual de la parte de ingeniería inversa aunque he detectado los siguientes detalles:

  1. El proceso de importación del ensamblado al XMI no es lento, tampoco la serialización, algo muy bueno.
  2. El proceso de importación del XMI, es decir las deserialización, en MonoUML es un poco tardado (en mi P4 2.8/512 RAM, tardo unos 2 minutos).
  3. Las pruebas que hice fueron con un XMI de unos 5.0MB, es decir la librería de Gtk# completa (además de TODAS sus dependencias), algo no tan bueno aunque viéndolo bien 5.0MB de XMI no es tanto, pues esta completa la librería.
  4. Al XMI aún le hace falta aumentar en tamaño, pues apenas agregue las clases (constructores, métodos) y las enumeraciones además de los tipos primitivos, así que según mis cálculos aumentará un 50% más en tamaño.

Después de esperar aproximadamente 2 minutos para deserializar se ve lo siguiente:

GTK# Cargado GTK# Cargado

Es claro que en el diálogo Reverse Engineering se deben utilizar threads para que el usuario no crea que se ha colgado la aplicación. Cuando todo este mejor sin duda haré el dialogo de importación simultanea de ensamblados para ser salvados en un sólo XMI, aunque sería bueno ayudar a Rodolfo para permitir que dentro de la librería XMI se permitan múltiples archivos simultaneamente, posiblemente eso mejore el serialización de XMI al igual que su deserialización en MonoUML.

Además de todo lo anterior, Rodolfo se propuso hacer esa característica de poder cortar los Edges (asociaciones) como lo hace Poseidón y ArgoUML, y lo ha logrado:

UMLCanvas#

Y no sólo eso, sino que junto con algunas características anteriores escritas por Manuel el canvas se esta convirtiendo en algo más usable, olvidemonos de cosas arcaicas como los Glue Points :) ¡Felicidades!

PD. Que bonito el tema de ClearLooks

2 Comentarios:

At 3/13/2005 05:01:00 p.m., Blogger Rodolfo Campero dijo...

Mario, he probado deserializando un XMI de 4.1MB (el resultado de procesar gtk-sharp con tu herramienta) y en mi maquina (Athlon 2600+ con 256MB de RAM) tarda 3581.376 ms, o sea tres segundos y medio, con lo cual sospecho que el problema está en otro lado, tal vez durante el pintado del arbol de MonoUML.

 
At 3/13/2005 06:32:00 p.m., Blogger Mario Carrion dijo...

Si, eso sin duda, la serialización y deserialización es rápida, lo más lento es el pintado en el árbol, y no mencionar que la memoria en MonoUML no es liberada al cargar otro XMI, hay que mirarlo detenidamente, espero solucionarlo pronto.

 

Publicar un comentario

<< Inicio