Archyno
ExportsPratique de la modélisation

L'aller-retour Sparx .qea

Ce qu'est vraiment un fichier .qea, ce qui survit au trajet d'un outil vers Enterprise Architect, et les parties qui n'arrivent jamais.

6 min de lectureXMI 2.5.12 sur 3

La réponse courte

  • Un fichier .qea est une base SQLite portant le schéma de dépôt d'Enterprise Architect - d'où le fait qu'il s'ouvre sur macOS et Linux, ce que .eap n'a jamais fait.
  • .eap et .qea diffèrent par le contenant, pas le contenu. Les deux portent le même schéma, et la conversion laisse le modèle inchangé.
  • Contrairement à XMI, un aller-retour .qea conserve la mise en page, car les coordonnées vivent dans la même base que les éléments, non dans une extension optionnelle.

01Une base de données, pas un document#

Le fait le plus utile à propos d'un fichier .qea est que c'est une base de données SQLite. Pas un zip de XML, pas un blob binaire propriétaire : un fichier que l'on ouvre avec n'importe quel client SQLite et que l'on peut interroger. À l'intérieur se trouve le schéma de dépôt d'Enterprise Architect, le même que Sparx utilise quand une équipe met son dépôt sur un SQL Server partagé plutôt que dans un fichier.

C'est pour cela que le format existe. Les anciens fichiers .eap et .eapx étaient des bases Jet et Access, ce qui liait tout l'outil à Windows et à un moteur de base de données dont Microsoft s'est désintéressé. SQLite tourne partout, et c'est ce qui permet à un outil dans le navigateur d'écrire un fichier qu'Enterprise Architect ouvrira.

02Ce qu'un aller-retour préserve#

ÉlémentNotationCe que cela signifie
ÉlémentsPréservéNom, type, stéréotype, notes et placement dans le paquet, dans t_object.
RelationsPréservéLes deux extrémités, le type de relation, le rôle et la cardinalité de chaque côté.
Mise en page du diagrammePréservéLa raison de préférer .qea à XMI : les coordonnées sont des lignes de plein droit et non une extension.
GUIDPréservéChaque élément conserve son identifiant, et c'est ce qui permet à un réimport ultérieur de mettre à jour au lieu de dupliquer.
Références et historique de versionsPerduUn fichier généré est une première version. Rien en dehors de l'outil ne peut reconstruire un historique qu'il n'a jamais eu.

La ligne des GUID mérite qu'on s'y arrête. Comme les identifiants d'éléments survivent, un véritable aller-retour est possible en principe : exporter, modifier ailleurs, réimporter - et l'outil peut apparier les éléments entrants à ceux qu'il a déjà au lieu de créer une seconde copie de tout. Qu'il le fasse relève de l'outil importateur, pas du fichier.

03Le faire sans y perdre un vendredi#

Ouvrez le fichier exporté dans un navigateur SQLite avant de l'ouvrir dans Sparx. Comptez les lignes de t_object et comparez au nombre d'éléments attendu. Un fichier auquel il manque des éléments saute aux yeux en cinq secondes là, et met une demi-heure à se faire remarquer dans un outil de modélisation.

Gardez une structure de paquets plate à la sortie. L'imbrication profonde est l'endroit où se cachent les erreurs de clé étrangère, et un ensemble plat de paquets que vous réorganisez ensuite dans Enterprise Architect va plus vite que déboguer une hiérarchie arrivée à moitié rattachée.

N'attendez pas du fichier qu'il porte un processus. Références, remarques de revue, traçabilité des exigences et données de gestion de projet sont de vraies parties d'un dépôt Enterprise Architect, et aucune n'existe dans un modèle construit ailleurs. Un .qea généré vous donne le modèle ; le processus repart de zéro.

En une ligne chacun

  1. 01Un fichier .qea est une base SQLite contenant le schéma de dépôt d'Enterprise Architect.
  2. 02Il a remplacé .eap et .eapx pour échapper à Access, et c'est pourquoi des outils non-Windows peuvent l'écrire.
  3. 03La mise en page est préservée parce que les coordonnées sont des lignes du schéma, pas une extension optionnelle.
  4. 04Les GUID survivent, ce qui rend possible un vrai aller-retour plutôt qu'un import en double.
  5. 05Références, revues et liens d'exigences relèvent du processus du dépôt, et aucun fichier généré ne les a.

04Questions fréquentes#

Qu'est-ce qu'un fichier .qea ?

Une base SQLite portant le schéma de dépôt d'Enterprise Architect. Elle a remplacé les fichiers .eap et .eapx fondés sur Access comme format local par défaut de Sparx, d'où le fait qu'elle s'ouvre avec des outils macOS et Linux.

Quelle différence entre .eap et .qea ?

Le contenant, pas le contenu. Les deux portent le même schéma de dépôt ; .eap et .eapx sont des bases Jet ou Access liées à Windows, tandis que .qea est du SQLite et portable. Sparx sait convertir entre les deux, et le modèle à l'intérieur ne change pas.

Un aller-retour .qea préserve-t-il la mise en page ?

Oui, contrairement à XMI, parce que la mise en page fait partie du schéma et non d'une extension optionnelle. Les objets de diagramme portent leurs coordonnées dans la même base que les éléments qu'ils montrent : un fichier correctement écrit s'ouvre avec ses vues intactes.

Dans cette série
  1. 01UML vers XMI
  2. 02Aller-retour Sparx .qea
  3. 03UML vers Mermaid

À lire aussi

Tous les articles