La ida y vuelta con Sparx .qea

El dato más útil sobre un archivo .qea es que es una base de datos SQLite. No un zip de XML, no un blob binario propietario: un archivo que puedes abrir con cualquier cliente de SQLite y consultar. Dentro está el esquema de repositorio de Enterprise Architect, el mismo que usa Sparx cuando un equipo pone su repositorio en un SQL Server compartido en vez de en un archivo.

Por eso existe el formato. Los antiguos archivos .eap y .eapx eran bases Jet y Access, lo que ataba toda la herramienta a Windows y a un motor de base de datos que dejó de importarle a Microsoft. SQLite funciona en todas partes, y eso es lo que permite a una herramienta en el navegador escribir un archivo que Enterprise Architect abrirá.

La fila del GUID merece detenerse. Como los identificadores de elemento sobreviven, una ida y vuelta genuina es posible en principio: exportar, editar en otro sitio, reimportar, y la herramienta puede emparejar los elementos entrantes con los que ya tiene en lugar de crear una segunda copia de todo. Que lo haga es una propiedad de la herramienta que importa, no del archivo.

Abre el archivo exportado en un navegador de SQLite antes de abrirlo en Sparx. Cuenta las filas de t_object y compáralas con el número de elementos que esperabas. Un archivo al que le faltan elementos es obvio ahí en cinco segundos y tarda media hora en notarse en una herramienta de modelado.

Mantén plana la estructura de paquetes a la salida. El anidamiento profundo es donde se esconden los errores de clave ajena, y un conjunto plano de paquetes que reorganizas después dentro de Enterprise Architect es más rápido que depurar una jerarquía que llegó a medio enganchar.

No esperes que el archivo lleve un proceso. Líneas base, comentarios de revisión, trazabilidad de requisitos y datos de gestión de proyecto son partes reales de un repositorio de Enterprise Architect y ninguna existe en un modelo construido en otro sitio. Un .qea generado te da el modelo; el proceso empieza de cero.