Les relations ArchiMate

ArchiMate a un ensemble fermé de relations et aucun mécanisme pour en inventer d'autres. Cette contrainte est la source de l'essentiel de sa valeur : deux personnes lisant le même modèle lisent les mêmes onze significations, et un outil peut raisonner dessus.

Quatre paires expliquent presque tous les traits erronés d'un modèle réel. Chacune a un test qui la tranche en une question.

Les relations sont formellement ordonnées de la plus forte à la plus faible, et cet ordre n'est pas une anecdote : c'est ce qui fait fonctionner la dérivation.

composition > aggregation > assignment > realization > serving > access > influence > association

"Plus forte" veut dire "affirme davantage". La composition dit que la partie est à l'intérieur du tout et ne peut être partagée ; l'association ne dit presque rien. Les relations structurelles (les quatre premières) sont plus fortes que les relations de dépendance (service rendu, accès, influence), elles-mêmes plus fortes que la simple association.

La règle en une phrase : une chaîne de relations entre deux éléments dérive une unique relation du type le plus faible de la chaîne. Composition, puis réalisation, puis service rendu dérive un service rendu, parce que c'est le plus faible des trois.

C'est le mécanisme qui fait qu'un modèle ArchiMate répond aux questions. Vous dessinez la chaîne détaillée une fois - le noeud héberge l'artefact, l'artefact réalise le composant, le composant réalise le service, le service sert le processus, le processus réalise le service métier - et l'outil peut alors vous dire que le noeud sert le service métier, ce qui est la réponse à "que perd le client si cette boîte meurt". Personne n'a tracé ce trait.

La même règle explique pourquoi un modèle sur-associé est inutile. L'association est la relation la plus faible, donc toute chaîne qui en contient une ne dérive qu'une association - "ces choses sont reliées d'une façon ou d'une autre". Un seul trait paresseux empoisonne tous les chemins qui le traversent.

ArchiMate vous laisse dessiner une relation en mettant un élément dans un autre plutôt qu'en traçant un trait. C'est compact et c'est légal, et c'est aussi la façon la plus courante dont une vue devient ambiguë : l'imbrication peut tenir lieu de composition, d'agrégation, d'affectation, de réalisation ou de spécialisation selon la nature des éléments.

Une habitude sûre : imbriquer pour la composition et l'agrégation, tracer un trait pour tout le reste. Cela coûte un peu de place et supprime toute une classe de mauvaises lectures.

Toutes les paires d'éléments ne peuvent pas être reliées par toutes les relations, et il vaut la peine de connaître ces contraintes parce que votre outil les appliquera et qu'il est plus simple d'acquiescer que de se battre :

1. L'affectation part d'une structure active. Un rôle, un acteur, un composant, un noeud. Un processus ne peut être affecté à rien.
2. L'accès aboutit à une structure passive. Objet métier, objet de données, artefact, contrat, matériau. Un comportement ne peut pas accéder à un autre comportement.
3. L'influence aboutit à un élément de motivation. Vous ne pouvez pas influencer un serveur.
4. La spécialisation exige des types identiques aux deux bouts. Un composant applicatif spécialise un composant applicatif, jamais un noeud.
5. Déclenchement et flux relient comportement à comportement - ou structure active à structure active, quand vous dessinez qui parle à qui plutôt que ce qui arrive dans quel ordre.

Si l'outil refuse un trait, la cause habituelle est qu'une extrémité est du mauvais aspect : vous pensiez au composant et avez dessiné le service, ou vous pensiez au processus et avez dessiné le rôle. Vérifiez l'aspect avant de supposer que la règle a tort.