Cesta tam a zpět přes Sparx .qea

Nejužitečnější fakt o souboru .qea je, že je to databáze SQLite. Ne zip s XML, ne proprietární binární blob - soubor, který otevřete jakýmkoli SQLite klientem a umíte se na něj ptát. Uvnitř je repozitářové schéma Enterprise Architectu, totéž, které Sparx používá, když si tým dá repozitář na sdílený SQL Server místo souboru.

Právě proto formát vůbec existuje. Starší soubory .eap a .eapx byly databáze Jet a Access, což vázalo celý nástroj na Windows a na databázový engine, o který Microsoft přestal mít zájem. SQLite běží všude, a to je to, co umožňuje nástroji v prohlížeči zapsat soubor, který Enterprise Architect otevře.

Řádek s GUID stojí za zastavení. Protože identifikátory prvků přežijí, je v principu možná skutečná okružní cesta: exportovat, upravit jinde, re-importovat - a nástroj umí příchozí prvky spárovat s těmi, které už má, místo aby vyrobil druhou kopii všeho. Zda to opravdu udělá, je vlastností importujícího nástroje, ne souboru.

Exportovaný soubor otevřete v SQLite prohlížeči dřív, než ho otevřete ve Sparxu. Spočítejte řádky v t_object a porovnejte s počtem prvků, které jste čekali. Soubor, kterému chybí prvky, je tam zřejmý za pět sekund a v modelovacím nástroji si ho všimnete za půl hodiny.

Strukturu balíčků nechte na cestě ven mělkou. Hluboké vnoření je místo, kde se skrývají chyby v cizích klíčích, a plochá množina balíčků, kterou si potom přeuspořádáte přímo v Enterprise Architectu, je rychlejší než ladění hierarchie, která dorazila napůl připojená.

Nečekejte, že soubor ponese proces. Baseline, revizní komentáře, sledovatelnost požadavků a projektové řízení jsou skutečné části repozitáře Enterprise Architectu a ani jedna neexistuje v modelu, který vznikl jinde. Vygenerovaná .qea vám dá model; proces začíná znovu.