La ida y vuelta con Sparx .qea
Qué es de verdad un fichero .qea, qué sobrevive al viaje de una herramienta a Enterprise Architect, y las partes que nunca llegan.
6 min de lecturaXMI 2.5.12 de 3
01A database, not a document
The single most useful fact about a .qea file is that it is a SQLite database. Not a zip of XML, not a proprietary binary blob - a file you can open with any SQLite client and query. Inside it is Enterprise Architect's repository schema, the same schema Sparx uses when a team puts its repository on a shared SQL Server instead of a file.
That is why the format exists at all. The older .eap and .eapx files were Jet and Access databases, which tied the whole tool to Windows and to a database engine Microsoft stopped caring about. SQLite runs everywhere, which is what makes it possible for a browser-based tool to write a file Enterprise Architect will open.
02What a round trip preserves
| Element | Notation | What it means |
|---|---|---|
| Elements | Preserved | Name, type, stereotype, notes and package placement, in t_object. |
| Attributes and operations | Preserved | Their own tables, keyed to the owning object. Types and multiplicity included. |
| Connectors | Preserved | Both ends, the relationship kind, and the role and cardinality on each end. |
| Diagram layout | Preserved | The reason to prefer .qea over XMI: coordinates are first-class rows rather than an extension. |
| GUIDs | Preserved | Every element keeps its identifier, which is what lets a later re-import update rather than duplicate. |
| Baselines and version history | Lost | A generated file is a first version. Nothing outside the tool can reconstruct a history it never had. |
The GUID row is the one worth dwelling on. Because element identifiers survive, a genuine round trip is possible in principle: export, edit elsewhere, re-import, and the tool can match the incoming elements to the ones it already has rather than creating a second copy of everything. Whether it does is a property of the importing tool, not of the file.
03Doing it without losing a Friday
Open the exported file in a SQLite browser before you open it in Sparx. Count the rows in t_object and compare against the number of elements you expected. A file that is missing elements is obvious in five seconds there and takes half an hour to notice in a modelling tool.
Keep the package structure shallow on the way out. Deep nesting is where foreign-key mistakes hide, and a flat set of packages that you re-organise inside Enterprise Architect afterwards is faster than debugging a hierarchy that arrived half-attached.
Do not expect the file to carry a process. Baselines, review comments, requirement traceability and project-management data are all real parts of an Enterprise Architect repository and none of them exists in a model that was built somewhere else. A generated .qea gives you the model; the process starts over.
In one line each
- 01A .qea file is a SQLite database holding Enterprise Architect's repository schema.
- 02It replaced .eap and .eapx to escape Access, which is why non-Windows tools can write it.
- 03Layout is preserved because coordinates are rows in the schema, not an optional extension.
- 04GUIDs survive, which is what makes a genuine round trip possible rather than a duplicate import.
- 05Baselines, reviews and requirement links are repository process, and no generated file has them.
04Preguntas frecuentes
¿Qué es un fichero .qea?
Una base de datos SQLite que lleva el esquema de repositorio de Enterprise Architect. Sustituyó a los ficheros .eap y .eapx basados en Access como formato local por defecto de Sparx, y por eso se abre con herramientas de macOS y Linux.
¿Qué diferencia hay entre .eap y .qea?
El envase, no el contenido. Ambos llevan el mismo esquema de repositorio; .eap y .eapx son bases Jet o Access atadas a Windows, mientras que .qea es SQLite y portable. Sparx convierte entre ellos y el modelo de dentro no cambia con la conversión.
¿Una ida y vuelta con .qea conserva la disposición?
Sí, a diferencia de XMI, porque la disposición forma parte del esquema y no de una extensión opcional. Los objetos de diagrama llevan sus coordenadas en la misma base que los elementos que muestran, así que un fichero bien escrito se abre con sus vistas intactas.
Lecturas relacionadas