Quelques règles d’hygiène, essentiellement du bon sens, règles qui comme souvent seront plus utiles si vous êtes plusieurs à travailler sur des modèles communs. Ces règles sont indiquées pour Archi mais je ne doute pas que les autres logiciels proposent quelque chose d’équivalent.

Nommage

Les vues doivent être nommées en respectant un formalisme, selon vos besoins. A titre d’exemple, j’ai utilisé [code de la vue]-[Application concernée ou domaine concerné]-[nom de la vue]

Le [code de la vue] est à entendre comme une notion essentiellement technique, parlante plutôt pour un public d’architectes. Au contraire le “nom de la vue” s’adresse plutôt au “grand public”.

Ex : “Vc07 - MaSuperAppli- vue fonctionnelle”

Propriétés des vues

Comme tous les concepts Archimate (enfin en tout cas dans Archi mais j’imagine que c’est similaire dans les autres outils), les vues peuvent avoir des propriétés. Là encore, j’ai eu l’occasion d’utiliser :

• le code de la vue (on répète donc l’information du titre)
• l’application/solution sur laquelle la vue est centrée, cad la solution qui est le personnage principal de la vue.
• l’attribut _hide_from_export_ qui permet de cacher une vue dans les exports
• un attribut permettant d’identifier les vues qui auraient été générées de manière automatique (par un script, un outil, la commande “Generate View For.. (Ctrl+G)” dans Archi )

Ici je répète des informations déjà précisées dans le titre. Par principe, je fuis comme la peste la répétition des informations mais ici l’usage des propriétés est utile pour les traitements automatisés par scripts : il est plus fiable de s’appuyer sur ces données que de parser le titre de la vue.

Cartouche

Ajoutez un cartouche sur chaque schéma avec, a minima, titre, auteur date. Si ce n’est pas forcément utile pour les architectes, c’est une information toujours très intéressante pour le public qui consultera les schémas en dehors du contexte de l’outil dans un site web, un PowerPoint, etc.

Lisibilité globale

Efforcez-vous de garder un schéma lisible sans avoir à zoomer/dézoomer en permanence. Adaptez la mise en page (paysage ou portrait) au support final le plus probable (site web, word, PPT, etc..)

Mise en forme

• Alignez les éléments les un par rapport aux autres,
• Homogénéisez les écarts entre les éléments et la taille des différents concepts
• Limitez les croisement de relations.
• N’abusez pas des “junctions” elles peuvent alléger la charge visuelle du schéma mais gêner la compréhension : une bonne pratique est d’éviter les junctions de type “plusieurs entrées/plusieurs sorties” et se limiter à “plusieurs entrées/ 1 sortie” ou “1 entrée/plusieurs sorties”.
  

  

Apparence visuelle des concepts

• Respectez les couleurs par défaut définies par votre outil. Cependant, vous pouvez jouer sur la saturation de la couleur pour réduire/accroitre la visibilité d’un élément.

  

• Définissez une feuille de style que tous les architectes partageront (Dans Archi, Menu Preferences > Appearance > Colours > Import Scheme). Les goûts et les couleurs… personnellement j’utilise celle-ci : V3

• Définissez quelles représentations par défaut vous utilisez pour chaque concept : dans Archi c’est au niveau du menu “Preferences > diagram > Default figures”

  

• Définissez des visuels pour mettre en évidence les spécialisations de vos concepts : les utilisateurs verront le plus souvent vos schémas sous forme d’images, une icone permet de facilement leur indiquer cette information sémantiquement importante. Exemple :

  

Viewpoint

Je n’ai jamais trop utilisé les viewpoints Archimate (a priori je ne suis pas le seul), laisser l’outil restreindre les concepts utilisables par schémas ne me semble pas très pertinent.

Paragraphe extrait d’Archimate 101

Is it useful to have a tool that forces you to use only a very restricted set of concepts? No because in some cases you might need a concept which was not planned when defining the viewpoint but makes sense in some very specific cases.

Je vois 2 cas où les viewpoints peuvent présenter un intérêt :

• pour des présentations, en utilisant ce principe pour masquer/mettre en évidence des éléments couche par couche.
• comme information exploitées par des outils de vérification automatique des schémas afin de contraindre plus fermement ce que doit contenir la vue et éviter ainsi que des écarts fassent planter l’outil.

Eléments “nested”

La superposition visuelle d’un concept dans un autre sans création d’une relation est toujours un peu risquée, d’ailleurs le valideur de modèle d’Archi vous signalera ce genre d’incohérences.

Attention, placer des concepts de technology layer dansun concept de l’application layer ne crée pas de liens automatiquement. Vous pouvez néanmoins paramétrer Archi pour qu’il vous propose de créer une association via les préférences. Cochez la case “association relation” dans la première zone du menu Connections > ARM. Exemple :

Vues dans des vues

Il est possible de glisser déposer une vue existante dans une autre vue afin de faciliter la navigation entre le schémas. 2 cas d’usage que je trouve intéressants :

• faire une vue de type “Sommaire” facilitant la navigation,permettant d’accéder aux autres vues d’un modèle. Vous éviterez ainsi à vos lecteurs d’avoir à se demander par où ils doivent commencer.
• faire des “zooms” : partir d’une vue globale peu détaillée et offrir ensuite la possibilité d’accéder aux détails internes d’un concept. En pratique, c’est vite assez délicat à gérer au niveau des relations avec les concepts extérieurs à l’élément “zoomé”.

Exemple de sommaire :

Exemple de zoom :

---