Der Sparx-.qea-Rundlauf
Was eine .qea-Datei tatsächlich ist, was den Weg aus einem Werkzeug in Enterprise Architect übersteht, und welche Teile es nie schaffen.
6 Min. LesezeitXMI 2.5.12 von 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.
04Häufige Fragen
Was ist eine .qea-Datei?
Eine SQLite-Datenbank mit dem Repository-Schema von Enterprise Architect. Sie hat die Access-basierten .eap- und .eapx-Dateien als Sparx' lokales Standardformat abgelöst, weshalb sie sich auch mit macOS- und Linux-Werkzeugen öffnen lässt.
Was unterscheidet .eap und .qea?
Der Behälter, nicht der Inhalt. Beide tragen dasselbe Repository-Schema; .eap und .eapx sind Jet- oder Access-Datenbanken und an Windows gebunden, .qea ist SQLite und portabel. Sparx kann zwischen ihnen konvertieren, und das Modell darin bleibt unverändert.
Bleibt beim .qea-Rundlauf das Diagrammlayout erhalten?
Ja, anders als bei XMI, weil das Layout Teil des Schemas ist und keine optionale Erweiterung. Diagrammobjekte tragen ihre Koordinaten in derselben Datenbank wie die Elemente, die sie zeigen - eine korrekt geschriebene Datei öffnet also mit intakten Sichten.
Passend dazu