Ce que garde chaque import

Pour chaque type de fichier qu’iyedy importe, ce qui devient éléments, relations et vues, ce qu’iyedy doit interpréter, et ce qu’il laisse de côté. Le rapport d’import de chaque fichier liste les mêmes groupes pour ce fichier : Repris, Approchés, Laissés de côté et À vérifier.

draw.io

Repris. Les formes C4, les acteurs UML, les cylindres (bases de données) et les formes AWS, Azure, Google Cloud et Kubernetes deviennent des éléments du type correspondant. Les lignes entre deux formes deviennent des relations. Un fichier draw.io exporté par iyedy garde ses types. Les positions sont gardées.

Approchés. Un type deviné d’après l’aspect d’une forme ; une flèche devinée d’après un style de ligne (une ligne en tirets lue comme asynchrone) ; les lignes à deux pointes et les lignes sans pointe ; les formes simples lues comme des éléments parce qu’une ligne les touche ; un seul élément fait de la même forme dessinée sur plusieurs pages ; une icône d’hôte séparée en un hôte et ce qui tourne dessus ; les groupes cloud (compte, région, VPC, sous-réseau) qui font de leur page un environnement de déploiement au lieu de cadres ; les styles.

Laissés de côté. Les formes décoratives sans libellé ; les groupes invisibles et les cadres de zone, aplatis ; les lignes qui ne relient pas deux formes ; les lignes d’une forme vers elle-même ; les formes BPMN dessinées dans draw.io.

Gardés comme notes. Les formes avec un libellé qu’aucune ligne ne touche.

Visio

Repris. Chaque page de premier plan devient une vue, avec les positions de ses formes. Les formes issues de masques dont le sens est certain deviennent des éléments de ce type : acteurs et utilisateurs en personnes, bases de données, serveurs et machines virtuelles en hôtes, pare-feu et répartiteurs de charge en infrastructure, icônes AWS, Azure et Google Cloud avec leur fournisseur. Les connecteurs collés à deux formes, ou dont les extrémités les touchent, deviennent des relations ; les pointes de flèche donnent le sens.

Approchés. Les types déduits des icônes cloud ; les flèches déduites du style des lignes (tirets lus comme asynchrones) ; les connecteurs à deux pointes ; les groupes aplatis ; les cadres avec un libellé autour de formes gardés en systèmes ou en groupes ; les formes réunies en un seul élément sur plusieurs pages ; les connecteurs dessinés sur plusieurs pages gardés une fois ; les icônes d’hôte séparées en un hôte et sa charge ; les groupes cloud qui font d’une page un environnement de déploiement.

Laissés de côté. Les pages d’arrière-plan ; les images et objets incorporés ; les formes décoratives sans libellé ; les connecteurs qui ne relient pas deux formes, qui partent d’une forme vers elle-même, ou qui vont vers des personnes sur une page de déploiement.

Gardés comme notes. Les autres formes et masques avec un libellé.

Non lus. L’ancien format binaire .vsd (Visio 2003 à 2010) et les dessins protégés par mot de passe.

Mermaid

Repris. Les flowcharts, avec leurs sous-graphes ; les séquences, en scénario avec sa vue Séquence ; les vues C4 de Mermaid (contexte, conteneurs, composants, dynamique, déploiement), avec leurs types. iyedy met les vues en page lui-même : les fichiers Mermaid ne portent pas de positions.

Laissés de côté. Les autres types Mermaid, les blocs vides. Un fichier Markdown peut contenir plusieurs blocs Mermaid : ils sont lus ensemble, et un bloc illisible est listé et laissé de côté.

SVG et PNG d’iyedy

Repris. Tout : un SVG ou un PNG exporté d’iyedy porte son modèle, l’import rend donc le schéma, ses vues et leur disposition.

Non lus. Toute autre image. iyedy ne fabrique pas un modèle à partir des pixels d’un dessin ; l’import dit qu’aucun modèle iyedy n’a été trouvé.